Much is said and written about the Agile Manifesto that if I were to write about it, I’m sure it wouldn’t be anything that hasn’t been said before. There is less material out there around the 12 agile principles that go along with the manifesto though, so I’d thought I’d put out there my own thoughts around these 12 sentences that help us understand how to apply the agile manifesto in our daily work.
Over the next few blog posts I’m going to break down the agile principles in batches of 3 at a time. This is part one, the first three agile principles.
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
There is a reason that this is the first principle, it’s fundamentally describing why we should be agile. Satisfying the customer is our highest priority, its what we care about most, and how do we do that? By delivering valuable software as soon as possible, and then inspecting and adapting based on feedback to continue to deliver valuable software.
It sounds so simple, yet is fairly difficult to do, especially if you are a team that is used to working from long Business Requirement Documents that have the detail of everything that the stakeholders could ever wish for written in a nice long list. Fortunately over the years there have been many tools, tricks and techniques developed in order to figure out what we should deliver first that is actually valuable to the customer.
My favourite tool of choice for breaking down a large idea into smaller deliverables is Jeff Pattons User Story Mapping. With this practice you map out a user journey and break it down so that you can understand how to deliver a valuable slice of a product to the customer without having to develop all those nice to have bells and whistles that slow a release to production down.
- “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
This is the one that all the Product Owners and people coming up with ideas love the most. Its great, this gives them permission to change their mind whenever they want and the team delivering just has to suck it up and do it!
Well, maybe not so much. Whilst we want to encourage any change of direction that will make the product better for it, there is always a cost involved. Usually when we change a requirement that the team has already discussed and refined there is an amount of waste generated.
A better way would be to try and change requirements early in development by collaborating on the plans early with the team. The more people you have looking at a solution, the better the solution will normally be.
Changing requirements late should not be the default, but the exception.
- “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Some teams that are advanced in their agile practices will laugh at this now, as they deliver a lot more often than once every couple of weeks! However if you think about it, those teams are not who this particular principle is aimed at.
Most teams starting on their journey will not have CI/CD pipelines, or even automated testing in place for them to be able to release on demand. Many teams are still having to abide by a quarterly release plan that has to go through some kind of Change Management process in order for another team to move their code through the phases into production for them. These are the teams that should pay particular attention to this principle.
It can almost seem impossible to be able to deliver software every couple of weeks, so start by just reducing it a little. How do you go from your current quarterly releases to once a month? Maybe at first you cant go to production once a month, but can get to integration phase once a month. Then figure out how to make the releases a little easier, is there something you can automate a little bit? one small step at a time, and over a period of several releases you will make gradual baby steps to reducing the amount you release at any one point. The aim is to release in smaller and smaller batches, more and more often.
The smaller releases the easier they are, the less risk is involved, and generally the smoother the process. It takes concentrated effort and focus on the release process in order to make a difference.
So thats it for now, I would love to hear your comments below around how you have applied these first 3 agile principles in your teams.
[/et_pb_text][/et_pb_column] [/et_pb_row] [/et_pb_section]