When I talk with folks learning about Agile, I often play the game Presto Manifesto (http://tastycupcakes.org/2009/06/presto-manifesto/) where the room talks about what it means to have a successful project and then breaks up into groups and based on their experiences come up with a list of critical elements that they’ve noticed on successful projects. This exercise is meant to bring people to the concepts of what makes up the Agile Manifesto.
The fascinating thing is that in many cases we discover that we’re programmed to believe that failures of projects relate to not knowing everything upfront. I almost always hear, “complete, thorough, and approved requirements” as an element of successful projects. This programming aligns well with the formula of success I learned during a short stint at an ERP consultancy firm:
SUCCESS = RESULTS - EXPECTATIONS
This formula leads us to make sure we set clear expectations so that we can meet and hopefully exceed them; thus, leading to success. However, as we know and learn in Agile (and really any process) – thinking the users/customers know everything about a project (a.k.a. need) six-to-nine months before they get their hands on it is simply a fallacy.
Sure we can make the customers agree to the expectations ahead of time, but doesn’t that negate the ability to ensure that value and ROI is actually achieved on the project? What generally happens is that the customer/user defines the requirements and agrees to them, then sometimes about a month before the project is delivered — they get their hands on some working capabilities and then say, “this doesn’t work as I expected, can you add a screen that does this and we’ll need a report that gets generated daily; if we don’t get these, we really can’t use this.” The response of the team is first, “but you signed the requirements document,” or “those are great ideas, we’ll need to do that in the next phase” or “that will need to go through the change control process, we’ll need to escalate this.”
Ultimately, the team is not happy because they don’t get to experience SUCCESS because the RESULTS fall short of EXPECTATIONS. On-top-of-this, the customer is not happy either.
Ways to Improve Success
By using an Agile approach, we can improve our SUCCESS rate by applying these very basic ideas:
- The customer (a.k.a. the Product Owner) stays engaged with the team delivering throughout the project lifecycle. In fact, they are part of the team. At no point in the process should they disengage; thus, decisions and expectations are set near the time the need is built and subsequently delivered – requirements evolve. And since the customer stays engaged, changes should not be surprises to either the delivery team or the customer.
- Needs are delivered in small valuable bites. This means that the delivery team and customer work together to understand the smallest piece of value that should be delivered first and they deliver just that. This approach helps both the customer and delivery team by narrowing focus which results in faster delivery and a focus on getting the high-value need right (with quality). If the delivery team falls short of expectations for some reason, it should not be a surprise to anyone. Small bites, result in small fails.
- At regular intervals, the delivery team (including the Product Owner) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demonstration provides a checkpoint for measuring success as well as it provides a way that expectations can be continuously molded and refined.
- Conversations are constant within the delivery team between the customer and the stakeholders. Instead of having formal meetings dubbed “Status Meetings” — we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, they grab the key team members and product owner and discuss real-time. This results in clear understanding and a lack of hand-off breakdowns (where information is translated as it passes from one person to another).
There are many more things we do with agile delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best practices, and an ephemeral drive to get better). But if you start with the above ideas, I can assure you that the team and the customers will start getting that feeling of SUCCESS.
