What Happened When We Made the Whole Business Agile. Tip: It’s not a Substitute for Knowing Where You’re Going
It’s easy to see why businesses are experimenting with Agile methodologies outside the IT team. The promise: no more lumbering, over-running projects.
And if it works in IT, why shouldn’t it work elsewhere?
Agile is not a substitute for knowing where you are going, and having a plan to get there.
But as the idea has escaped from the IT team, it has become more misunderstood by management. So, first of all, let’s recap what Agile is.
In the IT world, Agile doesn’t mean just “moving quickly”.
Rather, Agile is a methodology for project management, in which the outcomes are broken down, prioritised and delivered incrementally, rather than altogether at the end.
Because outcomes are prioritised, and delivered throughout the project, there is greater visibility, and scope can be changed without endangering the most important outcomes.
Agile has been developed by IT and it works well for them. But Agile needs tweaking to make it work for the business as a whole.
Understanding why means understanding how the IT team has changed.
Agile leads to a different way of working
The most noticeable change that Agile brings is transparency. Because deliverables occur throughout the project, it is easy to see whether the team is on track. That transparency leads to a more open way of working, and, in a good team, better collaboration. If the team is getting behind, everyone can pitch in and help out in the problem area.
Partly because of this, and because Agile is iterative, roles blur. It doesn’t make as much sense to have separate roles for development, testing, deployment and so on. DevOps is a natural extension of that. This way of working leads to many benefits, such as bugs being picked up more quickly as the same person who is writing code is testing.
Because the same people are covering many roles, there are fewer hand offs, which often means less delay. It also encourages automated testing and deployment, which in turn speeds up deployment and progress overall.
Because the team is deploying code weekly or fortnightly, and demonstrating new changes to the business, there is more reliance on the working relationship with the rest of the business. The business can, and should, have input into subsequent development and suggest changes.
And, finally, these changes can be incorporated into the process without derailing the whole project.
Translating that to the Business
It’s natural that the rest of the business should see these benefits and want to take advantage of them. In addition, having IT move closer to continuous deployment, while the rest of the business is using waterfall approaches inevitably leads to tension: different teams moving at different speeds is frustrating and can be difficult to manage.
As with all successful business initiatives, the idea only represents 5% of success. The other 95% is execution, and Agile is not a substitute for knowing where you are going, and having a plan to get there. So what does the business need to do to make Agile work?
These are some of the things we learned at Naked Bus as we started to apply Agile to Marketing, Operations and CX.
Start with the Vision and Customer Pain Points
IT has historically been a supplier to the business, and has assumed that the business knows what it wants. Thus, Agile starts with customer stories. But when customer stories are being developed, there is a temptation to throw the kitchen sink in.
And what if the business hasn’t articulated a vision, or doesn’t know what is possible? If you don’t know where you are going, any road will take you there.
One risk is marginal changes that, at best, make small improvements and at worst just automate, inefficient existing process.
Unless there is a vision, and top customer pain points (those things that separate vision from reality) have been identified, you can end up with a mish-mash of a wish list. “Nice to haves” will crowd out initiatives that move the needle.
List Outcomes that overcome the Pain Points
By starting with a vision, and clearly setting out the gap between that vision and reality (pain points) you will quickly surface the important initiatives. But be clear that you have specified a clear outcome that matters to your customers.
Once a list of outcomes has been scoped they need to be prioritised. Here again, the rest of the business plays a vital role, testing against the vision.
By determining how an outcome gets the business closer to the vision, a set of changes need to be articulated.
Agile is not anti-planning. While software is the ultimately flexible asset, always being capable of change and improvement, lack of planning leads to all sorts of problems such as technical debt, hard to find bugs and expensive rework.
Planning becomes even more important when you are dealing with parts of the business that are less flexible – when a physical asset is being created for example.
Dependencies and Resource Conflict
As soon as you expand Agile to beyond the IT team the number of moving parts increases exponentially. Each team member has one or more customers (internal or external) who are expecting deliverables by certain due dates. All of a sudden, a whole new layer of project demands must be met.
To make this work, every team member needs to identify how much time they expect to spend on “business as usual” tasks, and therefore how much time they will have left for agile project work. This can be interesting in itself, as it forces a level of transparency to which team members may be unaccustomed.
This is complicated by the fact that in teams such as marketing, dependencies may be greater. In other words task 1 (performed by person A) has to be completed before task 2 (performed by person B). While this is the nuts and bolts of traditional project planning, the combination of business as usual, and short sprints can be overwhelming.
At least in the early stages, it will probably be necessary for someone to keep in regular touch with all team members, check on workload, and adjust deliverables to ensure that constraints are not overloaded.
That person probably has a good understanding of the overall business, the projects and outcomes, and the team members’ workloads and capabilities.
As Agile becomes embedded, team members should get better at managing their own workloads and identifying conflicts in the planning stage.
These are some of the things we learned, and some of the processes we put in place to help us move more quickly towards the vision. I’d be interested to hear what others have found!
- Have I challenged the Vision?
- Have I got a set of desired outcomes that take me closer to the vision?
- Have I broken the deliverables down into smaller, yet still meaningful, outcomes?
- Have I prioritised the outcomes against the vision?
- Has each team member identified the business as usual workload?
- Does each team member know what is expected?
- Does each team member have the time to complete their tasks?
- Is there adequate communication between team members to manage dependencies?
Hamish Nuttall launched nakedbus.com, a low cost, internet-based long distance bus company in 2006. Hamish integrated marketing, IT, Ops and customer experience, harnessing Agile, Theory of Constraints, and Lean Startup methodologies to deliver rapid growth.
Naked Bus achieved 40% market share, carrying 700,000 passengers per year, 25-40% year on year growth and a Net Promoter Score of +65.
Following its sale in early 2015, he now works with organisations to help them in their digital transformation.
Contact Hamish at firstname.lastname@example.org.