Agile is what you learned at school but probably forgot about
When I talk about teams in this post I mean any group of people such as a team, a project, a programme, a department or a company.
The questions asked at school perfectly sum up the agile mindset, a mindset we possess naturally, develop in primary school but tend to forget as we move into the workplace:
- How do we know that…
- What can we do to find out…?
- How could you test to see if that was true?
Thinking differently
In asking these questions, a lot, an agile team sets itself apart from the mentality of the “order taker”, who serves up solutions to an agreed set of requirements within a contractual relationship. The agile team is curious, questioning and sceptical, always looking to validate requirements and assumptions.
The consequence of this mentality is a different approach to creating value and solving problems. “How do we know that…?” and “How could you test to see if that was true?” means that accepting documented requirements at the start of a long delivery process as “the truth” is out of the question. Rather, we want to validate them as quickly and cheaply as possible, we want to know we are building the right thing and, if not, how we can steer the delivery towards the right thing.
What does this mean, practically?
It means we are going to follow the scientific method (something else you learned at school) where, until we have empirically validated an assertion, we won’t trust it to be true. We make assertions (let’s call these requirements), we describe what we expect to happen, what we hope to learn and then we build something. The thing we build is the “experiment”, the real-world test of what we expect to happen or to be true. This approach is very fashionable now in the Lean Startup movement.
Every time we go through this process of stating an assumption, building something and validating it in the real-world, we are creating a feedback loop. Every time we complete a feedback loop we should know more than we did before (even if that is the knowledge of what *not* to do). What we learn from this feedback loop can be used to refine what we do next, to help us steer towards the best outcome given our constraints.
This can sometimes mean that what we thought we were going to do isn’t what we end up doing. A great example of this is Starbucks. The winning formula we see now is not at all what it started out with; instead, there was an Italian cafe feel with endlessly piped opera music and barristas wearing bow ties. With a trial and error approach (also something we learned at school) Starbucks was able to refine its pitch until it worked out what people *actually* wanted and needed from a coffee shop.
So, one way we can look at agile is in terms of these feedback loops, where the length of time it takes to get through one and the number of loops we execute becomes an indicator of agility. In this approach, to be very agile is to have lots of these validation feedback loops, happening as fast as we can manage without compromising quality and the morale of the people working in our teams.
Most importantly, they have to be credible feedback loops where we really learn something. In chemistry class, at school, we didn’t experiment by reading about experiments or simulating them, we experimented by really mixing powders together (and wafting them over bunsen burners in the hope of something loud and spectacular). In business, this means we test our ideas out by really doing it, just like Starbucks did.
Of course, there will always be circumstances where this real-world trial and error approach is not possible. In HM Government this is particularly true where policy and legislation prevents an early release of the business and IT service. In these cases, the learning feedback loop is still very important but we have to be more nuanced in applying it, for example, by starting with visualization techniques to hone the planning process and moving on creating a working replica of the live service, running dress rehearsals with real working software, business processes and procedures.
Additional Insights
The importance of owning your transformation
Are you set up to successfully compete with experiences?
The power of setting clear expectations
