In the last couple of episodes I've introduced the concepts of Minimum Viable Product and Lean Software Development. In this episode I want to introduce Agile. Along with Minimum Viable Product & Lean Software Development - Agile - along with Cloud & DevOps which I'll pick up in the coming weeks - provides a great introduction on how to get the Better Return from your Software Development Investment.
Or listen at:
Published: Wed, 11 Sep 2019 15:24:23 GMT
Links
Transcript
Of all the terms I'm introducing in this series, Agile is by far and away the most abused.
So much so that the American Department of Defence felt it appropriate to release a paper entitled "Detecting Agile BS" - I'll include a link in the show notes.
I'll come back to that paper later in this episode as it actually offers some great of examples of what Agile isn't (as the name indicates).
Ok so what is Agile?
From Wikipedia:
“Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.”
Ok.
While technically correct, that description is a bit abstract.
For me, the best way to understand Agile is to review the Agile Manifest.
The Agile Manifest was created in 2001 by some of software development's leading figures. A group that wanted to document underlying values they believed should be used in software development.
I'll provide a link in the show notes, but the manifest states:
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
Ok, so lets take unpack that.
I'm sure you've heard the phrase “standing on the shoulders of giants”.
This relatively simple, yet hugely powerful, statement was the work of some very clever individuals – masters of their field – software development.
While generally overlooked, the first paragraph resonates strongly with a key message from this series to date:
"We are uncovering better ways of developing
software by doing it and helping others do it."
It makes clear that they are still learning – but their combined experiences lead them to the rest of the statement.
This speaks to the maturity and continual discover within Software Development that I commented on previously.
These experts have come to this statement by having lived the industry and learnt through trial and error.
Yes they are saying they are learning; but this manifesto has been at the core of the Agile movement for over 18 years now. It remains a solid foundation.
The heart of the manifesto is the simply declarations that they value one thing over another - they aren't dismissing the less valuable, rather putting forwards what they believe to provide greater value.
So take for example the "Individuals and interactions over processes and tools";
They aren't saying there is anything wrong with processes and tools. They are definitely better than a complete absence. They are generally found in what we would consider traditional software development - they are things I've grown up with in my career.
I've never found them perfect, and we’ll touch on some of the shortfalls in this episode, but good solid projects can be delivered using them.
Nowhere does the Agile Manifest say that the old ways can’t work. They can – we’ve all seen experiences of that. In general however, these industry leaders feel they get better, more consistent, more cost effective results from the alternative.
Ok, so lets talk about "Individuals and interactions over processes and tools"
This is recognition that while there is value in process and tools, there can also be a fair amount of waste.
If you've listened to the last episode on Lean Software Development, you will be familiar with waste and how we should minimise that to increase value.
With traditional software development processes you will find they have built up around the central value of communication between 2 parties – the party requesting something and the party delivering something. Over time rules have been codified and levels of bureaucracy created – normally with the best of intentions – that can actual obscure the communication.
So in the past we've introduced Business Analysis, Project Managers, etc to frame the communication. And this can be useful – but it also means that the communication is going through multiple interpretations. This is not only time consuming (as well as people intensive) but also a source of mistakes and misinterpretation.
The closer the interaction between the requester and the deliverer – the higher the chance of getting the correct thing in an efficient manner – lowering the cost of that delivery.
Within Lean Software Development, you would want to be reducing the Handoff waste as describe by the book by Mary & Tom Poppendieck.
The Minimum Viable Product encourages us to get everyone you need for the experiment involved. Get them face-to-face. Get them focused on the experiment. Keep the hand offs to a minimum - ideally remove completely.
Now lets talk about "Working software over comprehensive documentation"
This is in recognition that the whole point of software development is to deliver working valuable software.
Documentation is purely a by-product of producing that software. Thus you have to consider if it is actually adding any value.
This quickly links back to interactions over processes.
If your development process involved multiple levels with little direct interaction then there is likely to be huge reliant on documentation.
I've certainly seem Project Managers report a project as being "successfully on track" when 6 months in all that has occurred is documents having been generated and passed from one team to another. Yes its on track with the plan .... But it hasn't produced anything for the customer to use.
The working software should be what you are measuring your software developers against – not the quality of their documentation.
Good, direct interaction however outweighs the need for comprehensive documentation.
Some documentation is useful – but certainly not the 100’s page specifications that I've seen previously. In most cases a few paragraphs setting out the high level intention is more than enough to act as a place holder until there is direct communication to fill in the gaps.
Again, both Lean Software Development and Minimum Viable Product encourage getting software out and in front of the customer.
Only by putting that software in front of the customer will get value from your investment.
Let's move on to "Customer collaboration over contract negotiation"
Doesn't Customer Collaboration sound so much more fun and positive than Contract Negotiation?
The reason we spend so much time over Contract Negotiation is that we are trying to ensure that the balance of the scales are in our favour – we are getting more from it than the other party.
This is such a negative place to start from. We start in conflict.
Collaboration however is inherently a much better place to be in a relationship. If you have problems, you are working together to resolve it – much better than retiring to separate corners to pore over a contract for who is correct.
Investing time and effort in delivery is always going to be a better ROI than ploughing it into defensive actions.
There will of course be times when you do need to have contracts in place. Just keep in mind that good relationships management is much better than having to rely on contracts. From experience, if you reach a situation where the contract is being cited then the relationships is likely already beyond repair.
Again, both Lean and MVP promote that direct collaboration.
And finally "Responding to change over following a plan"
If there has ever been a truism within software development, it is that everything changes.
For years projects have failed because of an arrogance to believe that the plan was all important.
The plan is purely a method of getting from A to B. If B changes to C then the plan needs to change.
But with so much time and effort put into building plans and documentation, there has always been a reluctant to accept that change.
Look at the language – it’s gets called a “Change Request”.
We have to request that change is accepted into the plan.
In fairness; there was good reason for this in most cases. Any change have had many knock on impacts – which, if nothing else, needed to be communicated up the management tree.
The world however keeps spinning, opportunities change, more is discovered about how to exploit an opportunity – there are just so many good reasons for change.
“The only thing that is constant is change” Heraclitus
So while having a plan is great – being able to respond to that change is essential. Too many software project have suffered from an over emphasis on the plan – only to deliver the wrong thing.
“No battle plan survives contact with the enemy” Helmuth von Moltke
I believe we all know that plans are, at best, transient. Thus you have to question why we try to slavishly expect our subordinates to deliver them as originally drawn up.
Even our language looks for the team to justify why they are not to the plan – we start with a negative assumption that the team have failed and they have to justify why.
If we ignore the huge impact on morale – why spend the time (and cost) explaining something we already know is likely to change?
MVP actively encourages us to focus on small changes - it is inherently expecting change to be part of the work we are doing. We are proactively going to the customer to get feedback on our experiment and asking "what next?".
Lean Software Development tells us to "Decide as late as possible" - it doesn't ask us to plan everything up front. It acknowledges that we want to keep our options open as late as possible to allow us to react to those changes.
In addition to the manifest statement, the same group also provided 12 principals. I'll probably revisit those principals in a future podcast. I'll include a link in the show notes to an article where I've written about them previously.
As promised;
I'll now look at that Department Of Defence document to highlight some signs that something isn't Agile.
Hopefully this will help to solidify what Agile is.
The document lists 6 keys flags that a project is not really agile. The first five are hopefully recognisable themes now that you have been introduced to Minimum Viable Product, Lean and Agile;
"Nobody on the software development team is talking with and observing the user of the software in action; we mean the actual users of the actual code"
"Continuous feedback from users to the development team (bug reports, users assessments) is not available. Talking once at the beginning of a program to verify requirements doesn’t count!"
"Meeting requirements is treated as more important than getting something useful into the field as quickly as possible."
"Stakeholders (development, test, ops, security, contracting, contractors, end-users, etc.) are acting more-or-less autonomously (e.g. ‘it’s not my job.’)"
"End users of the software are missing-in-action throughout development; at a minimum they should be present during Release Planning and User Acceptance Testing."
The sixth & final will likely be new to you at this stage, and something that I go into when I introduce DevOps;
"DevSecOps culture is lacking if manual processes are tolerated when such processes can and should be automated (e.g. automated testing, continuous integration, continuous delivery)."
Hopefully this episode has provide a good understanding of Agile and how there is considerable cross over with both Minimum Viable Product and Lean Software Development.