Last month I wrote about a couple of blog posts on LinkedIn about the death of Agile. Though the author admitted he was speaking tongue in cheek (and clearly hyping the topic by using an image of a nuclear explosion), he raised some good points about why some people wish Agile were dead. In this post, I look at the areas where I agree with the author, as well as where I think he is wrong.
Why I Agree that Agile Should be Dead
I sometimes wish Agile in its current form was dead. And I have to agree with the author that the hype around being “Agile” is not helpful; it is actually counterproductive. Everyone seems to have jumped on the Agile bandwagon. It’s the popular thing to do and has led to a lot of unintended results.
One such result is that many organizations are A.I.N.O. (Agile in Name Only). Practicing A.I.N.O. has probably done more to hurt the progress of Agile and Agile Methodologies than anything else.
This could be as simple as relabeling what you are currently doing with agile or scrum terms. It could also be implementing one part of a framework and calling it Agile.
I was with a client recently and an IT manager referred to a new daily status meeting that he had implemented as a “Daily Scrum”. Stop it. If you are going to use Scrum, use it in its entirety as described in the Scrum Guide.
I also agree with the author that there are some consultants who have benefited greatly from selling Agile to organizations that don’t understand it, use it properly or get any benefit from it.
It’s been treated as Cargo Cult – blind adherence to a set of rituals that mean nothing. It’s no wonder that even some of the original proponents of the Agile movement have come out against it.
Before we throw out Agile altogether and bring back CMMI or some other process-laden approach, let’s be clear about what we are trying to solve. Today’s technology teams are being asked to do more with less, to respond quickly to change, and to work on what is often the bleeding edge of technology.
There is a great deal of pressure to deliver and there is uncertainty about technology and business requirements. It is in this context that Agile can help the most.
And for the record let me state that I’ve been a traditional project and program manager for over 20 years. I actually specialized for a number of years in recovering troubled projects where I saw first-hand the problems with changing or poorly defined requirements, lack of teamwork and communications, and the lack of business engagement and collaboration.
So I was a huge fan of the short cycles of Agile, the ongoing planning, and the continuous feedback and collaboration with the business.
Unfortunately, my version of Agile may not match anyone else’s. The term has become so overhyped and applied in so many ways that everyone says they are agile no matter what approaches or methods they are using. We need to be more specific about what we mean when we say Agile. So I recommend a common definition of Agile.
We Need A Common Definition of Agile
Actually, we already have a common definition of Agile. The Agile Manifesto spells out 4 values and most people know those quite well. There are also 12 lesser known principles behind the manifesto. Even though they are now 15 years old, they still represent a great definition of what it means to be Agile.
I’ve paraphrased the 12 principles below. Let’s look at each of these in turn.
- Satisfy the customer with frequent deliveries of valuable software – There are two parts to this – satisfying the customer and delivering valuable software. Is there any question that these aren’t important principles? Does your current process focus on this?
- Welcome change – Given the amount of competitive pressures and the need for cycle change, this one also seems pretty important. Plus the idea of change as representing team learning needs to be incorporated. We cannot think of everything in advance no matter how much time we invest in planning. So we should be open to the idea of incorporating change into our plans.
- Deliver in short cycles – Earlier in my career, I was involved with projects and programs that spanned multiple years with the delivery not coming until the end. That type of investment and long payback is risky. Shorter cycles allow us to get feedback earlier, reduce our risks, and provide value to the business faster.
- Build projects around motivated individuals; empower and trust them – There are 3 ideas here. The first is getting the right people on the team (and by corollary, getting the wrong people off). Second, we want to empower the people closest to the work to make decisions about how it gets done. This comes from Lean thinking. Finally, trust that people will get it done. We want to provide the context for people to do their best work and trust that they will do that.
- Business and technology must work together daily – The intent of this principle is collaboration and shared accountability for the results. In many organizations, there is a long history of contention between the business and technology teams. Rather than collaborating throughout a project, the business may have limited their involvement to the planning or analysis phase. Then when the solution was delivered and it didn’t meet the business needs or wasn’t delivered on time, there was plenty of blame.
- Face to face communications – Traditionally, communications between stakeholders and teams and even within a team were focused on document handoffs. We all know how handoffs and documents can fall short and result in misunderstandings. The idea behind face to face communications is that having these high-bandwidth communications will lead to a shared understanding.
- Working software is the best measure of progress – Progress reporting was traditionally done based on a % complete approach for each phase, which frequently led to missed deliveries. People are notoriously bad at predicting how long complex activities will take. This principle shifts the focus to solutions that are done and working – eliminating the reliance on % complete.
- Work at a sustainable pace – Nothing is worse for the morale of team members than being required to give up their nights and weekends to meet a deadline that they did not set. It’s much more effective to let the team set the pace for their work, and let them work at that pace. It doesn’t mean that the team cannot choose to work overtime or stretch to meet a sprint goal.
- Strive for technical excellence to improve agility – We‘ve all seen the situation where teams are forced to cut quality in order to meet a fixed scope and fixed timeline. This leads to a downward spiral as quality issues result in technical debt which reduces the team’s productivity and leads to more deadline pressures. The better approach is to write clean code from the beginning and refuse to cut corners under deadline pressure.
- Self-Organizing teams – This principle relates closely to #4. There is the idea that those closest to the work will best figure out how to get it done. There is also an ownership issue. If we have someone who is directing the work of the team and telling everyone what to do, the team won’t take ownership of the results. Today’s knowledge workers don’t need someone else telling them what to do. It is better to set up the conditions where teams are working closely together and then there is little need for someone outside the team to dictate how the work gets done.
- Simplicity is essential – Keep things as simple as possible and avoid doing any work that is not adding value to the customer.
- Retrospect and continually improve – This is one of my favorite parts of Agile – the focus on continuous improvement. Taking time to periodically pause and reflect on what the team is doing has great benefits. I’ve written about what a waste it is to do lessons learned at the end of a traditional project. Retrospectives are different. They are done throughout, with a focus on teams running experiments to make the team process more effective and enjoyable.
Rather than kill off Agile, I think we need to use the term properly and focus on the 12 principles behind the Agile Manifesto. If our approach is not consistent with those 12 principles, then I don’t think we should call it Agile.
What are your thoughts? I’d love to hear your comments.