Agile has clearly made a significant impact on the software development industry, changing the way millions of people work to a more flexible, engaging and adaptive approach, delivering products that better meet the changing needs of the market. Agile thrives in under complexity and uncertainty – elements intrinsically inherent in business. So can agile be used for implementing a business strategy? In this post I will outline some basic principles and concepts for this.
For those of you with experience applying agile techniques, you will know agile is built upon a mind-set, some values and some principles. Trying to adopt agile without understanding this often results in a “hollow” agile implementation, often referred to as “cargo cult agile”; going through the motions without understanding the philosophy. This applies for adopting agile anywhere, whether this is in software or not. It is important than any approach remain true to the original intent.
A strategy is essentially a hypothesis. It is typically filled with assumptions, most of which carry risk. Will our customers like this new direction? How will our competitors respond? Is this going to be profitable for us? What happens if we are wrong? A traditional business plan bakes this risk into the plan, underpinned with the belief that risk can be removed with sufficient upfront analysis. Sadly, this is seldom the case.
Imagine playing the old Battleships Game. You are using a traditional business strategy, which means you have to select all your moves up front and then sit back and wait to see if you won. I am using an agile business strategy, which means I can make a move, see what happens, learn from this and adapt. Guess who is more likely to win?
An agile plan is based upon The Scientific Method – we have a hypothesis about a business idea, which we test via a series of planned experiments. We check the results to evaluate our original hypothesis. Refine and repeat or stop. This approach accepts that we can’t answer everything questions up front and the best way to reduce risk is to execute iteratively, checking results as we go. In essence, this is Demming’s Plan Do Check Act cycle.
So what does this actually look like?
There are three key parts – the hypothesis, the experiment(s) and the evaluation.
Typically, I am executing this with an executive team. They steps are:
- A group of people come up with a strategy to deliver the vision. My suggestion is that you keep it lightweight and simple – something easily understood and clear. It doesn’t have to be tens of pages nor does it need to be beautifully presented. The concepts and content is what matters.
- Develop a set of key metrics to measure the success of the strategy. There has been plenty written on metrics, and my suggestion is to keep it simple and balanced. Perhaps a metric to represent customer satisfaction, staff satisfaction, revenue, profit, plus whatever else is meaningful for you.
- Analyse the assumptions and risks in this strategy and then make then make them transparent. How will we know if this assumption is valid? What triggers could indicate a risk is becoming more likely? What possible mitigations exist for treating this risk?
- Looking at the above three areas as inputs, write the key initiatives on simple systems cards. Include things that can be done to reduce risk or validate assumptions. On the back of each card, write out how you would know if these were completed. Keep it simple.
- Based on the estimated capacity of your organisation, put the highest priority items into what you feel could be achieved in the first quarter. Be ruthless – not everything can be one in a quarter. Select the next highest priority items for the next quarter and put these in the next column, the next in the third quarter and so on. This is your high level Implementation Roadmap. It will change as we progress. Get comfortable with that.
- Only you will know how to prioritise. Perhaps based on return on investment, perhaps on risk, perhaps on compliance, perhaps on brand value – or perhaps on all of these.
The output of this is an Implementation Roadmap.
The above process will likely take you some time. This typically isn’t something you develop in one sitting. It will probably take a sustained effort from a diverse group of people, with time between planning workshops for ideas to marinate. The art here is balance – be patient, but don’t be perfect. Remember you don’t know everything up front so Implementation Roadmap will likely change as you deliver. Accept this and move on.
So you now have a common artefact that shows what the general themes are for the year. If you haven’t already then share it! Show others what we are aiming to achieve. Get their feedback and suggestions. Who knows, maybe they have better ideas than you?
Once you’re a comfortable with your roadmap, and again, I suggest you don’t dwell on it for too long, it is time to start implementing as this is where the real value comes from.
The first item(s) from the Implementation Roadmap are now broken out into an Implementation Backlog. In traditional Scrum we would call this the Product Backlog. It is characterised as:
- Being transparent – meaning accessible to everyone involved, easy to understand and clear.
- Being ordered – typically items at the top of the backlog have more value than items at the bottom.
- Lower value work, typically items at the bottom of the backlog, are purposely left non-specific. Higher value items are typically broken down into well-defined and ready to be picked up by a team and delivered. We do this as we know the backlog will likely change and there is little point in investing effort in breaking out the lower value items; we might never implement them.
We have three roles:
- The Strategy Owner – this is the person who has accountability for the implementation backlog and the ability to make decisions. Typically, in this situation, it is the CEO.
- The Implementation Team – the people at the highest possible level accountable for implementing the strategy – typically the senior executives.
- The Coach – the person who helps facilitate the process, guide the Strategy Owner and the Implementation Team.
We work in iterations (called Sprints), typically no longer than one month in duration. The shorter the Sprint, the more regularly we obtain feedback and get to learn.
Sprints start with a Sprint Planning meeting, during which all three roles get together and select the work they believe they can achieve in the upcoming iteration and develop a plan for how they are going to deliver this. The plan could be simply a set of sticky notes organised on a Scrum board, or it could be done on a whiteboard or even be a document. A key consideration is that the Implementation Team may be selecting work that their teams (subordinates) will likely be delivering. For example, say we have an Implementation Team made up of the heads of marketing, sales, HR, legal, finance, commercial, operations and product development. The Implementation Team would select items they believe are achievable, then collaborate on a plan to deliver these. To deliver the item, there might be some HR tasks, some legal tasks, and some operations tasks. The tasks are likely to be delivered by people working for the HR, Legal and Operations executives. This means that these executives need to understand the capacity of their people prior to the planning meeting! The outcome of this meeting is goal and a plan for the Sprint. We call this Sprint Backlog as it is the backlog of work for the Sprint.
Now that we have a plan (the Sprint Backlog) we start delivering it. A key event to help with this is the Weekly Scrum meeting. In traditional Scrum this meeting is no more than 15 minutes long and occurs at least once every 24 hours. The objective of the meeting is for us to inspect and adapt the Sprint Backlog. That is, based on what is now done, what is the best use of our time today? The outcome is a plan for the day.
We apply the exact same principles here. The only thing I tend to change is the frequency of the meeting. While it would be ideal to meet daily, the reality of getting an executive team together every 24 hours is low. Pragmatism has taught me that twice a week is great, once a week is realistic. Obviously the more frequently the better, but use your common sense. Don’t forget the objective of the meeting – it is a planning meeting not a status meeting and the outcome should always be a plan for what we are doing before the next stand up meeting.
The outcome of the iteration is an increment of change – pieces of the strategy delivered. As per traditional Scrum, it is vital that the increment is transparent. The reason for this is that all those involved (especially the Strategy Owner) needs to be able to clearly understand what is done and what isn’t done in order to understand what we should be aiming for in the next iteration. In traditional Scrum, we typically use a Definition of Done to achieve this. In this situation a DoD might not be the right approach, so adapt to your needs but don’t forget the principle – transparency allows us to inspect and adapt. Find a way to make your increment as transparent as you possible can.
The Sprint Review is a wonderful opportunity for all stakeholders to participate in this process. The Strategy Owner presents what has been achieved and what hasn’t and the Implementation Team will discuss the challenges they faced during the iteration and what they did about it. The Strategy Owner then discusses what she would like to have done next iteration, based on the reality of progress to date. Stakeholders work with the other roles. The outcome is an updated Implementation Roadmap and/or Backlog.
The final meeting in the process is the Sprint Retrospective, which is a continuous improvement meeting for the Implementation Owner, Implementation Team and the Coach. We seek tangible improvements we can try next Sprint.
The results of the Sprint are then checked against the Vision, Strategy, Measure and Assumptions/Risks. Based on our tangible actual result, we can
- Ask ourselves what we have learned from our last Sprint.
- Check our strategy. Is it realistic? Does it need to change based on what we have learned?
- Validate assumptions – were our assumptions correct? If not, what did we get wrong and what needs to change?
- Mitigate risks – check how the work we have just done impacts our risks.
- Adapt the Implementation Roadmap and Backlog.
Running this process allows for small frequent iterations of value to be realised, and more importantly, for regular inspection and adaption of the strategy itself based on empircal evidence.
Darwin is often quoted as saying “it is not the strongest of the species that survives but the most adaptable“, hence my question previously posted – is strategy dead? Personally, I don’t think so, but a heavy up front strategy will always be beaten by a fast adaptive one. What are your thoughts?