Much has been said about agile, and much is continued being said. Agile deployments of software fail, and agile deployments of software succeed... And every so often an article pops up which contributes to the common misconceptions that create the weak foundations to build your agile deployment. Let's explore them here.
Misconception 1 - Agile is a project
A project has a defined start, a defined end, and a defined transformation delivered in between of the start and end. Agile has a defined start with the start of the first sprint, but technically, no defined end (you can add sprints or decide to scrap a few), nor does it have a defined end state. The whole purpose of agile is to get features onto the "product" (product is the delivered item or service at the end of each sprint) - with each sprint successful if it delivers an MVP (minimum viable product) or MVI (minimum viable increment or improvement). There is no guarantee what is delivered at the end of the sprint other than the aim to have it as a minimum viable (usable) product. Therefore agile fails the "is this a project" test - and we should not treat it as a project - or you invite yourself to failure.
Misconception 2 - Agile must have a scope
Scope is to put a fence around the requirements of the project - what is included, and what is excluded. If it is not in the scope, it is governed via a change control process, or chalked up as "scope creep" (usually at the time the project is running out of budget). Using agile for your deployment, you focus on features, which are assigned to sprints in such manner that at the end of the sprint it is very likely that a minimum viable product is delivered, even if not all features of that sprint made it to the product. Through the method of points estimating (usually using the Fibonacci sequence), adding a feature of x estimation points needs to be traded with removing a feature or features totaling at least the same number of points.
Misconception 3 - Agile must have documented requirements
The term "requirement" in itself is mutually exclusive with agile - if something is required, it means that without it, the delivery has failed. Documenting "requirements" in an agile delivery means that everything that is documented is a non-negotiable - it is required for the product to be functional. If you apply the "iron triangle" of project management to this, it means that you fix all three sides - scope, budget, and time - as in Agile you fix the resources and duration during the sprint, you must keep the "scope" flexible.
We do not speak of "requirements" in agile. We deal with features. Some are required to establish MVP or MVI - in other words - these features are MUST HAVE. Other features are exceptionally valuable. And then there is a list of features that are just nice. By filling each sprint with 65% of effort estimation points with Must Have features, 25% with the valuable Should Have features, and the remaining 10% of the estimation points with the Could have features that are just nice to have, you maximise your odds for delivering a full MVP/MVI during the sprint.
Misconception 4 - You must estimate accurately
We'd like to estimate with the highest accuracy as possible, but the undeniable fact is, we (all of us) suck at estimating. We don't know how to estimate. Do I hear some murmering in the back of the room? Do I hear someone say: "our estimates are always accurate?". If your implementation partner says that, and it turns out that what they have estimated is indeed what is billed, you should ask: "what is more likely - my IT vendor has found a way to accurately estimate my custom deployment project even though they do not yet have a full picture of the end product and our internal complexities, or, my IT vendor has padded all estimates to cater for the eventual occurrence of at this moment unforeseen risk?" - my money is on the second explanation. Estimates are like storage space in your house: it doesn't matter how much you have, you'll always fill it. No, we cannot estimate.
What we can do, is relative estimation. We may not be able to tell if A is 10 or 20 hours in effort, we can tell if A is relatively more or less than B. This is where the Fibonacci sequence comes in - we assign estimation points based on complexity - 1, 2, 3, 5, 8, 13, 21, etc. So if A is more complex than B, and B is less Complex than C - we can start assigning numbers. B is the least complex feature in the list - the next question is: how much more complex is A regarding to B? Is A twice as complex? Then B = 1 means A = 2. How complex is C in relation to A? We know that both A and C are more complex than B. If A and C are equally complex, then we assign the value of 2 to C as well. If C is less complex than A - we need to reassign the numbers. A could be 5, B could be 2, and then C could be 3. Note that the Fibonacci estimation method does not translate any of these numbers into time. It is just relative estimation.
An experienced team will have a rough understanding of how many estimation points they can deliver in any given time, but a good method of testing is a "Sprint 0" with a representative loading of estimation points.
Misconception 5 - if I follow all principles of the agile delivery as described above, the delivery cannot fail
Nonsense - In anything worth doing, there is always risk of failure. If your agile delivery is based on the above misconceptions, it is all but guaranteed to fail, unless you actually manage it as a regular project - in which case the chance of success drops to 30% (yes, still approx. 70% of all IT projects fail). Here are some pitfalls outside of the previous addressed points:
- The product owner does not have sufficient knowledge/experience to define an MVP/MVI
- Insufficient time and effort is spent on testing against the MVP/MVI requirements
- The delivery team is insufficiently experienced in the delivery of a certain technology, and this has not been reflected in the estimating
- The estimation points are assigned by people other than the ones delivering the product
- The product owner does not accept that not all features will be delivered
- There is no understanding in the team of value of each feature, and the fact that 80% of the value is within 20% of the features
- The product owner is "hands off" during the delivery process.
Key takeaways
- Agile is not for every company, nor is it for every delivery. But when you do go agile, do not conflate the delivery methods with traditional project management
- Agile does not make you deliver the same features faster. It makes you deliver more value faster by prioritising value first
- Agile does not mean "no documentation". It means limiting the documentation to those documents that are essential in delivery or use/maintenance of the product
- Agile is not magic, but the results can be