What’s in a name? We all love clever names because they tell us all about something without having to ask further questions. Just imagine the software industry’s collective joy at a process that embraces business agility and is named accordingly!
I will argue that it’s the worst name given to a product development process in history. (I will focus mainly on development and not operations, although Agile really helps there too.)
Another way to put it is that it’s terribly misunderstood. The term is misused by both advocates and adversaries. Here are some (paraphrased) quotes that I’ve actually heard or read over the past year:
“We need something much more agile than Agile”…
“What’s so agile about 2 week sprints?”…
“If we can’t make adjustments on the fly, we’re not being agile”…
(names and other specifics withheld to protect the guilty)
In each case, the term is both misunderstood and misused. The first person was responding to having to provide requirements in order to see results from Agile Development. In her mind, she thought developers would just imagine and invent products on their own, and then she would get to see if they passed muster. This person was unfortunately miscast into a technical product management role with very little product experience in her operations-centric career. She was given the responsibility of bringing a product to market, but lacked the experience in both the business and technical side of product development she needed to be successful in that role.
The second person was arguing that Agile Development is too rigid for dynamic organizations to use. Having to plan and assess in 2 week iterations – the horror! Much better would be to just decide on a daily basis what will be delivered, and then realize 6 months down the road that nothing works and nothing meets requirements? Or simply try to react to all conditions in real time rather than set up proactive process to anticipate them and execute? If 1-4 week sprints are too rigid for a product development organization, then the preferred process is called “Chaos”, and it’s probably the most widely used out there – just look at some of the junk emerging (or not even seeing the light of day) from startups today as they take the inevitable ride down to failure. In no way do 2 week sprints mean that you cannot support customers in real-time, they simply mean that you cannot create new functionality without some sane window of time to execute within, and a reasonable process to plan with. If you simply react to each customer request without proper product-level triage (including alignment with business strategy and prior commitments), you are a custom development shop, not a product development shop. Remember, products scale because they meet broad requirements in target markets, not because they solve every esoteric problem every single current customer has. This is why investors generally value product companies higher than services companies, but the truth is if these organizations don’t deliver on expectations, the funding stops. Maintaining product discipline is a critical element to ensure current and future revenue growth.
The third person was questioning why he could not simply shuffle his work during a sprint, based on his interpretation of business requirements. This is a narrow view of what product development actually is. In some ways, it’s a symphony, where the conductor (Product Management and Product Owner) have to keep cadence for the orchestra that agreed to play a specific piece. There are so many moving parts. There is business strategy, current and future customer commitments, resource constraints, support responsibilities, and most importantly, resource pooling to achieve a common goal. A team cannot execute on a single product if individual members decide to change their assignments randomly during iterations. The single most important part of an Agile Development process, in my opinion, is commitment to team. Team members must trust that other members will deliver on their commitments, so that when it’s time to integrate, the product will actually work. The fact integration is often continuous in modern development shops makes this even more critical. Just think of an orchestra playing Mozart’s Die Zauberflöte while a single violin switches to Beethoven’s 9th Symphony. It doesn’t matter that it’s only 1 violin, it still derails the entire piece!
The real agility is in between iterations, where planning and assessment take place. This is where all the stakeholders, not just developers, realize and adjust to business realities of the product they are building. A regular cadence ensures a positive rippling effect throughout an organization, where everyone knows what to expect and prepares accordingly. It’s all about trust – developers trust each other to deliver the units making up the whole, product owners trust developers to build the code, product managers trust product owners to deliver on business requirements and strategy, and the rest of the organization trusts that the product is robust enough to sell and operate. Given that transparent change is possible between iterations, this allows a business to adjust in dynamic climates without having to wait months for “change requests”… but this cannot be done without process at every level.
While I’m being tongue-in-cheek when I say Agile Development is a terrible process name, it’s very important that both critics and supporters understand what it really means. Reading the Agile Manifesto is nice, but process advocates within organizations need to position this in terms that apply to each organization’s unique business challenges personnel make-up.
