Agile methodologies have completed the voyage from buzzword to mainstream. CEOs now routinely brag to customers and boards about their companies’ Agile transformations.
While Agile got its footing in the startup and web applications space as a software development methodology, it has now spread to enterprises of all sizes. Companies that have not yet made the transition to Agile methodologies feel increasing pressure to make the move.
Ten years after our CTO nudged us towards Agile/Scrum at Xprove, and almost eight years in product management leadership at a much larger company, I’ve learned three things about Agile.
- Agile transformations limited to the R&D and IT functions will fail and slow time to market.
- Agile is not for every development effort, but most exceptions can be managed.
- Agile cannot become excuse for loss of strategic focus.
Agile is an organizational methodology
A couple of months ago on the IT Pro Portal Jurriaan Kamer published a really nice article on Agile adoption from the CIO perspective. He illuminated the most common mistake organizations make – limiting Agile adoption to the IT (or R&D) functions.
[Agile/Scrum] is just a piece of the puzzle — a good first step on a longer journey. Scrum only works as it’s intended when it’s functioning within a fully agile environment — otherwise, any efficiency gained from scrum is lost when it inevitably encounters other departments using more traditional productivity methods.
What we often see is a company having the IT or R&D function make the transition to Agile/Scrum while continuing to go to market with product lifecycle management processes that are aligned with legacy Waterfall development methodology. Excuses abound for this type of behavior, and are perfectly logical within the narrow contexts they are presented. Some justifications for maintaining Waterfall-style program management include:
- Sales and marketing need to know when specific products and capabilities are coming to market. Collateral, campaigns, and sales training take time to develop.
- Finance and executive leadership need accurate release dates in order to project revenue and set budgets.
- Large customers and professional services need accurate dates to plan implementations.
These reasonable concerns pressure the development organization to deliver specific functionality set on a specific date. But it sounds like Waterfall, doesn’t it? A common mistake is to begin the development cycle with “scoping sprints.” Accurate scoping depends upon complete product requirements documents. And down the slippery slope and into the currents of Waterfall we slide. One product management executive who has slid down this path describes his company’s development methodology as “Waterfall with the additional overhead of stand ups and Jira.”
So your organization has not embraced Agile cross functionally, what to do? Rather than succumb to the pressure to maintain fundamentally incompatible legacy PLM processes, wouldn’t it be great to kick off the next project with an exercise that will garner Agile buy-in across the highest levels of the organization and promote more agile behavior? Enter the design sprint.
…a framework for teams of any size to solve and test design problems in 2-5 days. The idea of sprints originates with the Agile framework. The idea of design thinking was developed at IDEO and the d.school at Stanford.
Made popular by Google, these one week (or less) exercises’ value extends beyond solving the initial design challenges of a project. A successful design sprint garners stakeholder support. But don’t stop there. The design sprint is great at sparking initial enthusiasm with a prototype, but it’s important to maintain that momentum. In keeping with the spirit of the design sprint and Agile, keep everyone updated throughout the deverlopment process. Customer and stakeholder attendance at sprint demos can be spotty. Record you sprint demos, distribute them, and tirelessly solicit feedback. Make it clear that it’s easier on everyone to give feedback than to continue blowing you off.
It won’t take too long before the organization is moving in a truly Agile direction. Stakeholders will abandon Waterfall’s front loaded, opaque, less successful, and less gratifying ways.
I love Agile, and I’ve never come across a group that has made the transformation to Agile eager to return to Waterfall. That said, there a certain programs are simply not well suited for Agile. Sometimes it is inevitable that fixed functionality needs to be delivered on a fixed date. Legacy scoping and resource allocation tools are better suited for those efforts. Hybrid Waterfall-Agile solutions might be in order. Take the tenets of Agile that work for nearly every project – the daily stand ups that foster better communication and transparency, and the Scrum of Scrums to manage cross-team dependencies.
An example of a project least suited for “Agilefall” is one requiring a significant hardware component. Hardware prototypes take time and money to develop and cannot be iterated in one or two week intervals. Waterfall mitigates financial risk in these situations. Cloud storage vendor Backblaze has published a succinct white paper with suggestions for incorporating the best of Agile/Scrum when building hardware.
The challenges of applying Scrum to hardware are considered insurmountable by some, but many teams have found ways to adapt Scrum to hardware development. When considering using Scrum, it’s crucial to acknowledge that, for some teams and for some projects, Agile methodologies are simply not possible. However, in most cases, Scrum can be adapted to fit hardware development projects.
One of the most useful solutions that Scrum teams have found in working with hardware is adjusting the frequent release principle. Instead of delivering a functional, physical product to the customer at the end of each sprint, teams have opted to deliver virtual simulations of the result of the sprint.
Agile is all the rage. Every organization aspires to be agile. Consultants (like me) make good money helping companies make the necessary transformations. Who doesn’t want their company to be seen as that sleek roadster handling the hairpin curves and avoiding every hazard along the growth roadway? In How CEOs Get Strategy Wrong, And How They Can Get It Right, Cesare Mainardi of the Kellogg School of Management warns of the trap of agility at all costs mentality.
Agility is overrated. It has unfortunately become code for throwing out strategy and chasing any opportunity one thinks might work. The best way to own the future is to be the one to shape it.
Mainardi’s advice isn’t just for those with the key to the executive washroom. Product Owners often lose site of project goals when responding to the latest market data or customer feedback, and are too eager to pivot to meet these recently discovered needs. If teams are making major directional shifts frequently it’s a signal that the upfront work of clearly defining the customer needs and the personas the product or feature is intended to address is incomplete. (Another reason to embark on a design sprint.) Unmet needs don’t change every month. They evolve over time. Here are some simple checks to determine if the initiative is well enough defined for developer hands hit the keyboard.
- Can the Product Owner give a two-minute pitch that covers what unmet need(s) will be met, what the product or feature does, and who it serves?
- Are epics that cover the scope of the two-minute pitch complete?
- What are the risks that the market will change significantly before development is complete?
- Are all stake holders on board? Customers, executives, customers, sales, customers, finance, customers, architects, and customers should validate the effort.
- Has a financial model been built? Roughly how much will this cost and how much will it make?
Change is difficult. It takes time to turn the organizational battleship, but knowing the challenges ahead and having a plan for addressing them should make the voyage easier.