This blog is about how to create an agile roadmap, or, to put it another way, how to define a plan without committing to pointless deadlines
One of the many complaints I hear about Agile working is that it can be seen as an excuse for development teams (by development team I mean any team actually doing the work – whether they are engineers, marketing types, journalists or llamas) to avoid meeting deadlines. Stakeholders find this unmanageable – how can the company plan as a whole when one element appears to be refusing to commit to anything?
Avoid meaningless deadlines
Management try enforcing deadlines (‘you will have the website completed by June’) and the development team pushes back (‘don’t you oppress me’). Frequently this situation leads to one of two outcomes:
- Management set a deadline regardless of what the development team says – leading to a resentful development team and reverting back to a waterfall approach. The team now needs to plan how they are going to meet that deadline.
- No deadline is set – leading to resentful management. Stakeholders feel that they can’t plan the related business activities properly (‘how can we plan a marketing launch when we don’t know when the actual thing will be ready?’). As time goes by inevitably there is a move back towards waterfall and a deadline is set.
In both instances the result is that a deadline appears on the horizon and the development team need to aim for that. You can use all the Agile words you like, but it doesn’t matter how many stand ups you do or how well you feel your sprints are planned – you are masking a waterfall approach with Agile jargon.
“Either do waterfall or do Agile. Do not confuse the two”
This is like the seventh level of hell. Don’t do this. Either do waterfall or do Agile. Do not confuse the two because they do different things. By saying you do Agile and actually doing waterfall you will achieve the worst of both approaches – meaningless deadlines and a vague plan.
What is waterfall?
The difference between a waterfall and an Agile approach is subtle but simple.
With waterfall you plan to create things and then you implement the plan to build those things.
For example – we are going to build a website in [insert platform of choice] and it will have a user sign up form capturing 10 pieces of data and it will launch on 1 March.
The development team now needs to work out how best to deliver that scope by 1 March.
You might want to break it down into short bursts of work so that you can keep tabs on progress and you might even call them sprints. But using the word ‘sprint’ does not make this an Agile process.
What is Agile?
With Agile instead you focus on results and then you work in small chunks of time to deliver those results. For example – we need to start capturing user data by 1 March. You then break down that objective into user stories such as ‘as an end user I want to be able to sign up for email updates’.
The differences here are:
- The person briefing the work (frequently a non-technical product manager) is not specifying technology choices at the start of the project. This enables the development team to be creative and to think up the best solution rather than trying to, for example, work out how they can make WordPress behave like a bespoke content management system (CMS).
- By providing a user story, you are focusing on the end result (that the user can sign up for email updates) instead of the details of how this will be implemented (that the submit button has rounded corners).
- Aiming for results rather than things means you are able to be more reactive to changes in the market. There is less risk that the massive thing you are building is going to be obsolete before you have finished building it. The team only commit to completing the current sprint’s worth of work – this means you can change what the next sprint will be.
Therefore if there is a big change such as a new competitor entering your space or a new technology, you can be very flexible (agile even) and change your roadmap to cater for that:
- The team set the rate of work (remember the comparison or ‘push’ and ‘pull’ in the last article?), you are not forcing a project on to a team when they can’t be sure they can actually deliver it. You are asking a team to achieve certain results and they work at a pace they feel comfortable with.
A results-based roadmap
Your roadmap then is less of a list of technical things you want building (1. Gallery. 2. Sign-up form. 3. Carousel.) and instead is results based (in this quarter we want to increase page views by 5% and grow our user database to 200k).
How you achieve these results is up to the team you have in place.
As managers you set the strategy – where does the business need to be in the short to medium term? The development team then works out how to get you there.
“I like to work by quarter – what would be stupid for us not to do in the next 90 days”
Personally I like to work by quarter – what would be stupid for us not to do in the next 90 days?
Set that as the goal and let the teams work in sprints towards that goal. You can read sprint reports along the way and look at the relevant metrics to see what benefit the changes being made are having. But really you step off and let the team do their magic.
If you can’t trust the team to deliver without you telling them how to do it then you either don’t have good enough people in place or you need to work on your trust issues.
See more on Agile working:
- Blog: How do you transition an entire business to Agile without losing momentum?
- Blog: What is Agile? Or how not to waste your money through poor process
