As a product engineer, you want to create high-quality software that solves real problems for your users. But you also need to deliver fast and adapt to changing requirements and feedback. How can you balance engineering excellence with speed and agility? In this article, we'll explore some tips and best practices to help you achieve both goals.
Before you start coding, you need to have a clear vision of what you want to achieve and how you'll measure your success. This will help you prioritize your tasks, avoid unnecessary features, and align your work with the business objectives and user needs. You can use frameworks like OKRs (Objectives and Key Results) or SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) goals to define your outcomes and track your progress.
Everything we do in product engineering must be mapped to SMART goals. Break each work item into small and measurable items such that any changes can be also easily incorporated. Start gathering feedback early as the earlier it is the more time we will have. Address both minor and major items equally; in an agile setting, consistent attention to details enhances both speed and agility.
(1) For Prioritize and Plan - Use techniques like Moscow (Must-haves, Should-haves, Could-haves, Won’t-haves) (2) Technical Debt - Keep track of technical debt and allocate time to address it regularly. (3) Feedback loops (4) Regular Sprint Retrospectives (5) Encourage a culture of ownership and accountability among engineers. (6) Set up CI/CD pipelines to automate the code changes (7) Periodic Code Reviews (8) Automated Testing (9) Implement Agile practices
In addition to SMART, I will get users involved and understand the use cases before any planning and design sessions. Each feature is tied to a use case. So each feature directly impacts user’s workflow and is not a nice-to-have.
1Deliver value incrementally and get fast feedback to speed the delivery process .. 2.A well defined product Vision along with a roadmap is essential to know what are the milestones and the impact of the value delivered ..OKRs 3. Tools and Technology...that support speedy delivery 4. Highly motivated team 5. Agile leadership
Following ways could help - Try breaking down tasks in smaller sub tasks that is easy to solve and measure. - Identify what features would qualify for mvp and get it out. - Based on mvp feedback build on top of it.
Agile methodologies are designed to help you deliver software faster and more efficiently, while responding to changing needs and feedback. You can use agile practices like Scrum, Kanban, or XP (Extreme Programming) to organize your workflow, collaborate with your team, and iterate on your product. Agile methodologies also encourage you to adopt principles like test-driven development, continuous integration, and continuous delivery, which can improve your code quality and reliability.
Adopt classes of services (CoS) in your pull-based work process (e.g., Kanban or Scrum). CoS define SLAs based on the incoming work type. For example, you may have 3 different classes of service: Expedite for urgent work items (stop everything and work on this now), Product (for new features and/or change requests), and Maintenance (bug fixes, cost optimization, and other technical work). Then, determine the ratio of effort assigned to each CoS. For example, you may have 50% of the time assigned for product-related work and 30% for Maintenance. The 20% remaining may be a buffer. When planning the next iteration, prioritize the work respecting the defined ratios. CoS and effective backlog management help to keep the software healthy.
The framing of the original question feels counter to the ideas of Agile itself. Engineering excellence is fundamentally part of agile, not something that has to be balanced against it. The Agile Manifestor (agilemanifesto.org) says it directly: "Continuous attention to technical excellence and good design enhances agility." A team that is empowered, supported and fully trusted will be able to make the right decisions rapidly, speeding the product to market while consistently making the best engineering decisions warranted at that time. Figuring out which frameworks, approaches and tools are right is somethign the team does as it learns more about the problem and product, but also what this group of people need in the here and now.
Agile methodologies are not necessarily going to help you deliver software faster. You can move faster in the build phase of a waterfall project. There is less bureaucracy in the build phase. You can go fast, but what you are building is usually the wrong thing. After you build the wrong item then it will need to be reworked (and that's just waste). If you limit WIP you can deliver faster. Agile methodologies do take an approach to limit WIP (WIP limits or timeboxing work). Agile methodologies do help you deliver the right software by incorporating shorter feedback loops. The ability to inspect and adapt your plan is the key to delivering the right (valuable) software your users want.
Agile doesn't mean agile frameworks or more process. Agile is fine but learning how to break work down to it's smallest unit of value is more important. Don't spend time on agile frameworks if your process and technology working together can't deliver a single code change to production every day. Once you have that capability, layering in process may or may not hurt delivery and engineering effectiveness.
Agile methodologies like Scrum and Kanban provide the flexibility needed to adapt to changing requirements while maintaining speed and quality. They encourage continuous improvement through short sprints, feedback loops, and retrospectives. Releasing code frequently as part of agile processes creates a culture of quick wins, allowing engineers to see the direct outcomes of their work. This not only motivates the team but also improves team collaboration and problem-solving abilities, fostering an environment where success is celebrated often.
Engineering excellence is not only about writing good code, but also about following standards and best practices that ensure your code is readable, maintainable, and scalable. You can use tools like code reviews, code linters, code formatters, and code analyzers to enforce consistent coding styles, detect errors, and refactor your code. You can also use design patterns, architecture principles, and documentation guidelines to structure your code and make it easier to understand and modify.
TOGAF framework is one of the best for asynchronous architecture-based solutions. It is very challenging to follow ISO standards compliance being the lean team but adopting baby steps and automating these processes through tools available makes the difference.
You cannot add quality at the end! Quality software is not created at the end of the process, by backfilling tests, refactoring brittle code, or writing documentation. It needs to be reinforced at every step, with processes to measure, evaluate and improve the product along the way. Measure quality across the following dimensions: Aesthetics – Is the code well written from the standpoint of logical organization, coherence, visual cohesion, and efficient use of language? Completeness – Does the code solve the stated problem? Performance – Does the code perform against known benchmarks? Effort – What are the costs to write, test, document, maintain, and deploy this code? Durability – How reliable, scalable and long-lived is this code?
Applying consistent engineering standards and best practices ensures code quality, scalability, and maintainability. Tools like code reviews, CI/CD pipelines, and automated testing ensure that every release is of high quality. Regular, smaller releases make it easier to adhere to these standards, as it becomes less overwhelming to maintain high-quality code. The process of continuously delivering well-engineered code also energizes the team, reinforcing a sense of pride in craftsmanship while reducing technical debt over time. I also love easy roll-backs when, in those rare occasions, perfect engineers, make a mistake :)
Developing in small packages can help improve the written code. A routine that we will have to use several times we can transfer to production while not all the software components have been developed and after it has already worked in production
Yes, tools can help here. But more important is to create a team culture and approach based on that concept. This doesn't mean everyone has the same opinion, but that there is a discussion and team perspective on these matters that is well understood, and revisited. Once the team is in the habit of thinking about standards and best practices, choosing and adopting the various tools will make it easier and easier to rapidly develop solutions and receive feedback. Just be sure to revisit those decisions with some regularity, and be on the lookout for when something you decided previously doesn't make sense anymore.
One of the benefits of delivering software fast and frequently is that you can get feedback and data from your users and stakeholders sooner. This can help you validate your assumptions, identify problems, and discover opportunities to improve your product. You can use methods like user testing, surveys, interviews, or analytics to collect feedback and data, and use them to inform your decisions and actions. You can also use tools like A/B testing, feature flags, or canary releases to experiment with different versions of your product and measure their impact.
Prototyping and failing fast can save lot of time if something is not going to work. Prototyping can identify architectural limitations and also can bring up technical debt. Its better to repay debt sooner than later!
Frequent and small releases provide more opportunities to gather customer feedback and analyze data on product performance. They also are easier to deploy with less risk. This iterative approach allows for faster course corrections, giving engineers a sense of ownership over the product’s direction. As we incorporate feedback early and often, the engineering team remains motivated by their ability to make a meaningful impact on the user experience. Quick iterations keep the product aligned with real customer needs and reinforce the value of collaboration between the product and engineering teams. Exploring an A/B testing feature strategy increases the feedback data by seeing side-by-side what customers like and don’t like.
Feedback from end users can be very beneficial. For example, the numbers on the side of my keyboard turn off every time I restart my computer. As an end user I wondered why it was designed/programmed that way; what was the thinking behind this? Gathering feedback from end users can help to discover unexpected or unplanned functionality of the product.
Are we improving on something that has to be solid and reliable (i.e. a core process), or are we being asked to take big leaps in trying something new (Innovation)? Regardless of where on this scale the work is, there are opportunities to try things rapidly and solicit feedback. Core processes require far more QA up front. They also have to be ready to "roll back" if the unintended consequences are too impactful so that additional development can be done. Innovations meanwhile can survive in production for longer even when the blast radious is bigger. Just expect to be actively assessing and addressing those production issues immediately and aggressively. You learn more, but need to stay focused on user satisfaction.
Engineering excellence is not a static state, but a dynamic process that requires constant learning and improvement. You can use various sources and methods to learn new skills, technologies, and best practices, such as books, blogs, podcasts, courses, workshops, or mentors. You can also use retrospectives, post-mortems, or peer reviews to reflect on your performance, celebrate your achievements, and identify areas for improvement. You can also use feedback loops, kaizen, or PDCA (Plan-Do-Check-Act) cycles to implement changes and monitor their results.
A great way to reach engineering excellence is creating a culture of knowledge sharing. In this way, engineers can build a tech community by sharing best practices, standards and ways of working instead of reinventing the wheel. In addition to that, a certification program related to the tech stack of the company will leverage the expertise and overall knowledge, considering that once someone gets certified, he will have a deep knowledge regarding the fundamentals of a specific domain.
At the end of each sprint we review our work. How many tasks we planned to do and how many we actually finished. If the planning exceeds the execution, we examine what hindered us along the way and try to improve the planning of our next sprints, taking into account the findings.
Fostering a culture of innovation ensures teams stay up on the latest technologies, discover new revenue opportunities, and grow in their roles. Introducing quarterly innovation sprints or sponsoring hackathon events provide ways to explore ideas, which the company can plan for and align with strategic goals. Agile retrospectives and post-mortems help teams reflect on what did and didn't work, turning every sprint into a learning opportunity that is baked into how you should be releasing products. As engineers see their newly acquired skills lead to faster, more reliable deployments, they feel a stronger sense of accomplishment, fueling personal growth and team success.
Finally, balancing engineering excellence with speed and agility is not about finding a perfect solution, but about making informed trade-offs and managing risks. You need to consider factors like time, cost, quality, scope, and value when deciding what to do and how to do it. You also need to assess the potential risks and benefits of your choices, and mitigate or accept them accordingly. You can use tools like risk matrices, decision trees, or cost-benefit analysis to help you weigh your options and make rational decisions.
Balancing trade-offs between speed, quality, and innovation is an exciting challenge. Prioritizing which features or fixes are worth releasing early versus those that need more refinement requires careful risk assessment. By releasing features in smaller increments, we mitigate risks while maintaining momentum. When teams can deploy new features without fear of breaking things, it boosts confidence and encourages more innovation. A motivated team, free from the burden of excessive risk, can focus on delivering exceptional results.
Foster a Collaborative Environment with Cross Functional Teams: Create cross-functional teams with client stake-holders and members with diverse skills (operations, development, design, QA, etc.). Encourage open communication and collaboration among team members. Foster a culture of trust, where team members can voice concerns and suggest improvements without fear of reprisal. Encourage team members to learn from each other and collaborate across disciplines.
Solving hard problems under tight deadlines means there is a risk in failure. While failure is a possible outcome it should not surprise anyone if it occurs. The key is to fail together: Externalize & Enumerate Risks – At regular intervals enumerate the risks to success. Rank and size the risks as well as determine the potential upsides, downsides and long-term ramifications. Trust Through Transparency – Measuring velocity, having retrospectives, and providing stakeholder feedback is all in service of being as transparent as possible about the state of the product at any given time.
Technical debt is fundamentally misunderstood in the product development community. Technical debt like stakeholder investments is a means to fund software development. Unlike external capital sources, technical debt is an instant (albeit finite) funding stream the development team controls. When used correctly, technical debt allows software teams to borrow from their future productivity to fund aspects of the product. Good technical debt is self-liquidating, meaning it creates value greater than the initial investment and overhead (e.g. interest) incurred to fund the loan. Teams run into trouble when they take on technical debt in secret to hide poor planning, misunderstandings, or wasted effort.
This depends on the size, situation, and maturity of the company that you're working with. You need to tailor your approach accordingly. In general, make sure you measure team efficiency, product quality, and common velocity metrics. Start a common language around scoring user pain. If its important, measure it and set a goal against improving it. You'll be amazing how rapidly you find your balance then.
How can you balance engineering excellence with speed and agility? “You can’t manage what you can’t measure”. So start by measuring your team’s performance on the DORA metrics and improve on them - Lead Time for Changes (LT) - Deployment Frequency (DF) - Change Failure Rate (CFR) - Mean Time to Recovery (MTTR) Simply put, you want to help your team to increase speed and agility without sacrificing the quality of the product. You also don’t want to make things too slow and miss on key opportunities for the sake of high quality, and sometimes aiming for too much perfection. The DORA metrics are great guardrails into achieving this balance. LT and DF represent speed and agility. CFR and MTTR (to an extent) reflect quality.
For a mature engineering team, engineering excellence and speed are not mutually exclusive. By fostering a culture of continuous learning and improvement, teams can enhance both the quality and speed of their deliverables. Mentorship plays a key role in nurturing this culture, helping to ensure that engineering excellence becomes a driver of agility rather than a hindrance.
Adopting platform engineering in the organization also helps lower the maintenance burden on product engineers. Alongside practices like TDD and approaches like DDD, product teams can create high-quality software that clearly expresses their business domain. At N26 Brasil, we achieved the DevOps high-performance grade in part due to our early adoption of platform engineering practices. The majority of our projects have clear domain layers with business rules tested without any dependency from the infrastructure layer.