This is the fourth and final part of the blog series were we discuss the 12 Agile Principles. In this post we will focus on principles 10-12.
10. “Simplicity–the art of maximizing the amount of work not done–is essential.“
When I was an Analyst back in the day before I discovered Scrum, or even knew what agile was, I would write down the findings of my analysis in a document called a Business Requirements Specification. This was often a fairly chunky piece of work that usually took many weeks, depending on the size of project at hand obviously.
When I think back to those days, and talking to the people from business who wanted ‘the thing’ then I would do my best to wring out of them every possible wish and desire they had. The more I knew, the easier it would be to satisfy them, at least that was my thinking.
The problem with that approach is that we end up listing every single wish and desire that we can think up. All the bells and whistles, nice to haves, call them what you will, without really understanding if they give value to the customer for the time spent in development. We try to make all the decisions up front when we know the least about what we are trying to achieve.
Using methods relating to an agile way of work we can easily see that the backlog should be emergent, not fixed up front. Gather enough information to get going, and then start. As we develop the product we gain feedback and the backlog is regularly refined and adjusted as we learn.
If we commit to doing everything up front, by signing off on an analysis document early, then we will likely ask the team to develop a lot of features that don’t really add much value. By trusting in the process and letting the requirements emerge as you develop, you will start to maximise the amount of work not done, and will have a simpler more effective product because of that.
11. “The best architectures, requirements, and designs emerge from self-organizing teams.”
Building on the previous principle, we can see that gathering all the requirements up front can cause problems with what we are trying to accomplish, especially when its left to a single poor lonely analyst to pull everything together.
The more brains and eyes you have on something, the better the quality for it. Well I guess you could get all philosophic about that, as for sure there is a problem in making all decisions by committee also, but the basic premise I think is fairly true. If we involve our teams in figuring out what we are going to build, then not only will the team have valuable input into the direction, but they will also likely be more invested into the product and care about it more. If you have a team that cares about what they are building, the quality of the product will definitely be better than if they are just doing a day job to pay the wages.
In a large corporate environment its generally not feasible to have an architect in every team. If that is the case then see if you can find ways to change the role of the architect away from the command and control tick box culture to a way of work where they can mentor teams to make architectural decisions themselves. Give the teams some guidelines and boundaries within which they have to work, and then help them be as self sufficient as possible. The team can then start calling on the architects for advice and guidance at regular intervals to ensure they are delivering a quality solution.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
If you only take one thing away from the agile values and principles, it should be this one statement. Inspect and adapt. Its at the heart of everything we are trying to accomplish. There is little benefit to doing a lessons learnt, a post mortem, at the end of a project when its too late to change anything. We should be aiming to introduce feedback loops as often as possible where it makes sense.
Scrum is built upon empiricism. Kanban encourages the idea of inspect and adapt. For both you need to be gathering data and then working on improvements based upon what you are measuring. As Deming once said “without data you’re just another person with an opinion”
So on that note, I’d like to leave you with a thought for introspection. What are you measuring? For your team, your organisation, maybe even in your personal life? Deming also said, “In God we trust; all others bring data.”, and then ensure that you tune and adjust your behaviour according to what the data is presenting.
Thank you for staying with us for this 4 part series based on the 12 Agile Principles. If you would like us to run a workshop with your teams to see if they understand the principles and how they can be applied in your organisation, then feel free to reach out to us by emailing info@growingagile.co