Agile can be a powerful tool, but it has grown into such a complicated industry that people often lose sight of the underlying principles that drive it. This leads businesses to fail to unlock its full potential and puts them at a disadvantage to their more agile competition.
I've been involved in software and technology development — off and on — for the better part of 25 years, as both an engineer and a product manager. Over the course of my career, I’ve experienced all manner of paradigm and process for developing products, including waterfall, agile, and all manner of amalgamations in-between. One thing I’ve consistently noticed is a trend of smart, capable, accomplished leaders and practitioners who claim to be doing agile, but in failing to understand what agile truly is — and isn’t — , consistently fail to reap its full benefits.
What Agile Is Not
- A set of rigid processes. Process is at best an uneasy ally of agile, a necessary evil to allow an agile mindset to function in a complex operating business. Some agile processes skew more pure, some skew towards borrowing agile concepts. But no matter what process you implement, no matter how pure or blessed by certifications or trendy, the mere act of implementing an agile process will not make you agile. Agile is a mindset, not a costume. Process is form, agile is function.
- A magic talisman. Attaching the word “agile” to PowerPoint slides, processes, and certification programs won’t magically unlock the benefits of agile. Let’s face it: Agile is trendy. Everyone wants to be agile. Every executive thinks it will unlock hidden value in their company. Boards want to know that the company is doing “agile.” Be skeptical of anything that tries to use agile as a brand and instead focus on the underlying principles.
- A magic bullet. Agile is a powerful tool, if you are a product-focused company with small, self-directed teams that must innovate in the face of uncertainty. If that doesn’t describe your company, YMMV. Agile is a powerful tool, not the only tool, and it’s not always the best tool for every company in every situation. But if your company does match this description, agile can be the unfair advantage that lets you compete above your weight class.
- A lack of strategy and planning. Agile does not mean that we operate with chaos, that we don’t have clear objectives we are trying to accomplish, or that we blindly say “yes” to every customer request or every opportunity for revenue. It is also doesn’t mistake the freedom to change plans with not having any plan at all. Agile is about learning continuously and validating assumptions so that we can quickly and cheaply make adjustments to stay on course, not about operating without any destination in mind.
- Only for delivery. Waterfall product planning coupled with agile delivery (or more often, just using “sprints” to deliver) unlocks at most 1/2 the value of agile. If you’re not also doing agile product discovery, and if your company isn’t operating with an agile mindset, you’re leaving a whole heap of value on the table.
- Perfect. Agile is about giving up one set of valuable things for another set of valuable things, in the belief that doing so is the right strategic trade-off to build better products, gain a competitive advantage, and deliver superior outcomes. It will be uncomfortable at first, and you will have to give up a few things that you rightly place value on in order to gain these advantages. Don’t fall into traps that promise to deliver the benefits without any sacrifice; there is no such thing.
Agile Starts With a Manifesto
Agile didn’t come from nowhere. It was a response to existing software development practices, and started with a manifesto in 2001:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Take a moment to pause and reflect, especially on that last line. It recognizes that there is often a tension between the things that tend to produce desired outcomes on the left, and more traditional artifacts that help to operate a business on the right. The agile manifesto is ultimately about placing greater value on outcomes than operations, about giving up emotional comfort and some measure of predictability in an effort to deliver outsized value.
It’s important to consider that agile didn’t emerge from a vacuum; it emerged in response the shortcomings and disappointments of traditional software development, now often referred to as “waterfall.” In waterfall development, we typically have long development cycles where we:
- Gather requirements and/or sign contracts with customers.
- Spend significant time and resources planning products and features to fulfill the requirements and contracts.
- Spend significant time developing and testing the next major release, which includes all the new features and updates we’ve planned.
- Plan and launch our release.
- Measure outcomes (finally!) which often fail to live up to our expectations.
The fundamental flaw in this approach is the amount of time it takes, versus how rapidly things change or how frequently we learn. In waterfall, if we learn something along the way that impacts a previous step, we have to wait until after the release is launched to do anything about it. And even if we manage to learn everything possible at each step before moving on, it is often the case that the customer needs, or market conditions, have changed by the time we finally release.
Agile then is nothing more than an acknowledgment that learning needs to be constant, opportunities to course-correct need to be frequent, and we must move at least as fast as the world around us to succeed, even if that means de-prioritizing things that might otherwise be valuable to operating a business.
Of course, the original agile manifesto was written by and for software developers. Since then disciplines like product management and principles like Lean have widened the scope of what it means to be agile. However, it’s worth revisiting the original principles around agile development:
12 Principles Behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Unlocking the Full Power of Agile
Agile works best when the whole company adopts an agile (and Lean) mindset. This is especially true for the disciplines that make up product teams and stakeholders — product managers, product owners, product designers, product marketers, project managers/scrum masters, tech leads, developers, and testing/QA, as well as customer success, marketing, and sales.
How to Avoid 10 Common Mistakes I’ve Seen
Mistake #1: Creating objectives based on outputs.
Instead: Have clear, measurable objectives in the form of desired outcomes.
These should not change frequently, and will be the goalposts that your product teams will continually work towards. Focus on outcomes, not output, and make sure these outcomes are true drivers of business success.
Mistake #2: Focusing too heavily on process and frameworks.
Instead: Start with a process that seems reasonable and evolve it over time.
None of them are perfect. Choosing one over the other will not make or break your products. Pick one you think will work for you, perhaps biasing towards a simple and straight-forward approach, and don’t overcomplicate the decision — you can always evolve your process (being agile about agile).
And keep in mind who you are: A team of 3 testing a business idea probably needs nothing more than Lean, while a massive corporation with 10s of 1000s of employees and no history with agile might opt for a more “agile-like” compromise like SAFe. Most teams should probably just focus on combining agile product discovery (see: Marty Cagan, Steve Blank) with something like Kanban or Scrum for agile product delivery.
Mistake #3: Handing customer requirements to your product teams.
Instead: Let your product teams talk to customers directly.
Good product teams know how to talk to customers and unlock deep understanding of their work, problems, and opportunities. This is one of the most powerful things your teams can do to gain insights that lead to great products. Customers know their problems better than anyone, but rarely do they even know what solutions are possible. Give your product teams an opportunity to delight and amaze your customers.
Product teams should be talking to sales, customer success, and marketing often, but don’t hide your customers away from your product team; non-product people are rarely trained in how to get the information that product teams need. Plus you miss the opportunity to let product teams co-create with your most enthusiastic customers.
Mistake #4: Micromanaging your products and product teams.
Instead: Give product teams autonomy.
Allow them to be missionaries, not mercenaries. Let them focus ruthlessly and methodically on delivering value to customers and outcomes to the business. Organize around products, not projects. Measure teams on business results, not schedules and plans. Do not make promises on behalf of teams without their consent. Focus teams on objectives and hold them to agreed upon outcomes, but empower them to make their own decisions on how best to achieve those outcomes. They’ll surprise you with what they come up with.
Mistake #5: Working in silos organized by function.
Instead: Make sure product teams are cross-functional and long-lived.
A good product team at a minimum includes product managers and designers, tech leads, and developers. They should form a long-term team that works closely together, but that does not report to each other. Avoid silos and throwing things over the wall. Make sure your product teams have shared knowledge by learning together. Make sure members of your teams have shared responsibility for outcomes, and that all members of a product team can communicate frequently and easily with stakeholders.
Mistake #6: Focusing on knowing the right answer.
Instead: Focus on learning and (in)validation.
Product ideas are hypotheses, and most are not going to work, no matter how smart the person who came up with them or how educated their opinion. This is true even for visionary product leaders and CEOs. Be humble. Focus on cheaply and quickly learning and sorting the good ideas from the bad using empirical means. Validated learning, done quickly and cheaply, even when a hypothesis is proven wrong, is just as valuable as lucking into the right answer on the first try, and you’ll exponentially reduce the cost of your bad ideas.
Mistake #7: Waiting until release to measure (or not measuring at all).
Instead: Measure early and often.
Do not wait until something is released to measure its outcome. Agile delivery is only half the battle. By the time we commit to building something to production quality, we should already have a good idea of the likely outcome and be confident in our solution. We achieve this by pairing agile product discovery with agile product delivery.
Mistake #8: Focusing on adherence to roadmaps and project plans.
Instead: Build-in frequent opportunities to course-correct.
Learning is pointless if we don’t take appropriate action in response. Roadmaps, project plans, and customer promises, while valuable for operating a business, often cause teams to be afraid to veer “off-course.” No matter how experienced the team, and how much management promises to “keep things agile,” there is a very real tendency to subconsciously supplant our outcome-based goalposts with output-based ones from our roadmaps and project plans. Avoid these tools if you can, or if you cannot, take proactive and frequent steps to minimize the chance of losing the forest for the trees.
Mistake #9: Delivering big releases with lots of changes.
Instead: Deliver in small, frequent releases.
100% of customers would rather have usable and valuable software today than tomorrow, and learning and validation don’t end once we release. Not to mention that lots of small, frequent changes are less disruptive to users than a large changes all at once. Be ruthless in breaking up delivery into minimum viable increments that deliver user value, and obsessively measure outcomes to incorporate feedback and learning back into the product discovery process.
Mistake #10: Believing that agile doesn’t require sacrifice.
Instead: Prepare for discomfort and consider carefully.
In order to unlock the value of agile, you’re going to have to make some sacrifices. Prepare yourself for that. You might be able to unlock some value by adopting bits and pieces, but ultimately your competitors who fully embrace agile will have an unfair advantage. If you’re on the fence, experiment with a single team and let them fully embrace agile without being forced to fit it into existing processes. You might be surprised by the results.