Since, for the most part, you know where you are, and having decided where you need to be, the next step is to plot a route to get there. And then get there.
Having decided that you want your organisation to be agile (see Agile Target Operating Model?) – which in a sense is the easy bit – you then need to work out how to achieve it. You need a plan. A route. Goals. Targets. Critical Success Factors. You need to know what success looks like (let’s play cliché bingo).
You’ll need to know when you have arrived, when your goals have been met, when you can see the sea, when the kids can start shouting “are we agile yet?”
And, of course, you’ll need someone to map read. Someone to make sure you’re still on target, you’re going the right way, you’ll get there in time for tea.
After all, you’re changing the way in which the organisation behaves. It’s a change initiative.
It’s what we do.
But this time, we’ll be changing the way we do things, while we do them. We’ll be trying to ride the bicycle while we’re still building it.
And since it’s a common or garden, run of the mill change initiative, we should treat it as such.
Because we want to practice what we preach, and because we believe there are wonderful benefits to behold over the rainbow in Agile-by-Sea, and because we’ve been rabbiting on about going agile for so long that we’re only going to get one shot at it, and because the leadership team is bought in, and because it’s the right thing to do, and because.
Setting out for Agile-by-Sea will have all the elements of a major change initiative:
- Cultural change
- Organisational change
- Process change
- Behavioural change
- Responsibility change
- Business change
… and all that goes with these usual change management challenges.
The good news is that there is usually a good feeling about going agile.
The leadership team usually likes the promise of being able to react more quickly to changing market conditions, getting their products to market quicker, reducing the gap between perceived requirements and actual requirements, and therefore fewer “that’s not what we asked for” defects.
The development teams usually love the idea of transitioning to agile, because it’s agile. Of course they do.
But, like any change initiative, we should expect challenges along the way. And so we should look out for them before hand. After all, it’s all been done before.
In my experience, there are several “traditional” areas which warrant close attention.
Areas where we might expect delays. Areas where we might expect stakeholders to struggle with the adoption of changes and new behaviours – either through lack of knowledge, lack of understanding, lack of engagement, a miss held belief that none of this would actually affect me.
These are what Accelerated Implementation Methodology (AIM) calls Roadblocks. We might call them risks which need mitigating.
Whatever we call them, there are some known knowns which we can start addressing early on in our trip.
Top 5 list of Agile transition Roadblocks
- Funding projects
- Cross-functional Scrum teams
- Product ownership
- User Story writing
Honourable mentions: feature writing, estimating, release management, continuous integration, QA.
1. Funding Projects
This is a big one. Traditionally, when Change is required, a Mandate of some sort is produced which describes high level costs, timescales, benefits, risks, etc. This is presented to the Change Board (or equivalent), who decide whether to proceed.
If they approve, a Project is spun up, Project Managers allocated, other resources allocated, and off we go. The project has a start, middle and end. It is a “temporary” piece of work, with a team specially assembled to deliver it. Once it has been implemented, the project is disbanded, and the resources float off to their respective resource pools to await further work.
Leadership get this approach, because it’s the “traditional” way of doing things. And because we are specifically allocating resources to it, we can do the maths and work out the resource cost. Something the leadership team likes to do, even though – by and large – the resource cost is based on a blended rate, and includes the Business and Contractors at the same rate, and we’ll never be able to reconcile it to invoices, and real costs, yada yada yada.
I once asked a senior leader, who was a member of the Executive Committee, Project Sponsor, and all round Top Charlie Banana:
Me: “Do you really want to see the cost of this project, measured as Hours x Blended rate?”
He: “Yes, of course.”
He: “Because we want to know if there’s a positive cost benefit for it.”
Me: “But you’re already paying for them. They’re permanent staff, regardless of whether they work on this project or not.”
He: “Good point. Actually, we only want to see the cost so that we can compare a project’s scale with the other projects in the portfolio.”
So really, the discussion should be about Capacity, not cost. Of course, contract staff cost real money, but ideally contract resources are best used for staff augmentation, to flatten the peaks and troughs of capacity.
In agile, the idea is that you bring the work to the people, rather than bring the people to the work (i.e a “project”), and so you stand up a scrum team, and ensure that they have a continuous flow of work (I’ll cover this off in another blog). The concept of a “project”, a “temporary piece of work”, disappears.
And so, therefore, does “project cost”. It becomes a conversation of capacity – “Do we have enough work for our scrum teams?”
Even moving to a continuous flow of change model, where we deal in Features, Value Streams and Epic backlogs – a continually growing list of “good things to do” being prioritised and fed to scrum teams, the Leadership Teams still tends to think “Project”. And hence, CBA, and hence Cost.
Moving to agile therefore requires a paradigm shift. And not just by the delivery side of things, but also from the Leadership side.
Of all the roadblocks to agile success – this is one of the toughest, and most important, to negotiate.
2. Cross-Functional Scrum Teams
One of the central tenets of Scrum is the self-organising, autonomous team. A self-contained team which can – for want of a better phrase – crack on.
At the start of each sprint, the backlog will have been prioritised, user story estimates made and sprint goals set. The scrum team is making a joint commitment, a team commitment, to the Product Owner – and to itself – that this work will be completed within the upcoming sprint.
The Product Owner also commits to this, and also to not changing the work priorities mid-sprint. Once the sprint is agreed, it doesn’t change.
As the scrum team gets better at estimating work, their team velocity will begin to solidify, helping them to make better estimates during the next sprint. Without knowing their velocity, a team’s initial estimates tend to be wildly out.
Because they’ve never done it before. Estimates – based on User Story Points – are a complete unknown to start with, and so tend to end up as SWAGs (“Silly Wild-Arse Guesses”).
But that’s ok, that’s why we need a solid, self-organising, stable and autonomous team to grow together, get better at understanding their capacity and know how many story points they can deliver in each sprint (that’s the velocity).
You can only do that if you have every discipline represented in the team. You can’t make estimates about cutting code if you don’t have any code-cutters on the team. Just as you can’t make estimates of how long it will take to build a house, if you don’t have brick layers on the team.
And that’s why you need cross-functional teams. Teams that have all the skills required to deliver the sprint. Programmers, business analysts, testers, business representatives, architects, plumbers, electricians and brick layers.
If you don’t have cross-functional teams, you can’t be autonomous. If you’re not autonomous you can’t make good estimates, and if you can’t make good estimates you can’t commit to a sprint, and if you can’t do that – well, you may as well draw stumps and head back to the pavilion.
Why is this a challenge?
Because typically, each role family in a change organisation tends to report up through different silos in the organisation, based on each discipline. Project managers tend to be managed in a pool of project managers by a senior project manager. Business analysts tend to to be managed in a pool of business analysts by a senior business analyst.
This is not a bad way of doing things if your organisation is project focussed. Remember, a project is a temporary piece of work, with a beginning and an end, to which resources are allocated – usually from a pool – on a temporary basis. People are taken to the work. Someone does the planning, others do the execution.
But we’re not dealing with projects, we’re dealing with continuous flow value-streams, static teams. We want to bring the work to the people. We want a self-organising, autonomous team of cross-functional experts, where the people who do the doing, do the planning.
And the transition from the one to the other is difficult. From project to value-stream. From discipline-based resource pools to cross-functional teams. It’s a new way of thinking.
Especially as the resources allocated to a scrum team need to be 100% dedicated to their role within that – and only that – scrum team. Not like a project-based organisation where people may be working on several projects at the same time.
“Self-organising” and “Autonomous” are also challenging concepts for Leadership teams who are used to top-down control.
Cross-functional teams are essential, but difficult to achieve in transition.
3. Product Ownership
The role of Product Owner is critical. And misunderstood. And difficult to get right.
Product in this sense is the term used to describe the “produce” from the scrum team. The output. The code. The working, tested, code – which has been written to satisfy the requirements as stated in each user story.
So who tests the code?
Mid-sprint, it is the responsibility of the whole scrum team to ensure that the code satisfies the requirements. That it does what it says on the tin.
There are various methods available to help test code:
– Test-Driven Development is a technique where requirements are turned into micro-specific test cases, written up in the user story, and the code is developed using a small lifecycle to pass the new tests.
– Pair Programme is a technique in which two programmers share the same workstation. One is the Driver who writes the code, and the other is the Navigator or Observer who reviews the code as it is written. The programmers swap roles regularly.
– In-sprint QA is a technique where a member of the scrum team watches the Completed status of user stories, and walks the code with the programmer reviewing it against the requirements written up in the user story.
So that all happens during the sprint.
The scrum team had committed to completing x story points during the sprint planning, which means n user stories have now been completed by the end of the sprint. They have all been tested, to the satisfaction of the scrum team. Sprint closed. Doughnuts bought. Coffee on. Well done everyone.
So who is going to approve the work that has been completed?
Who is going to check that the “working, tested code” actually works in line with user expectations? That it does what it says on the tin – according to those who are going to use it.
The Product Owner. That’s who.
The product owner has the final say. “Yes, it does what is required.” Or “No, it doesn’t do what is required.”
Remember, the Product Owner is not interested in the actual written requirements that have been picked up by the programmers, interpreted and translated into code – per se. The Product Owner is interested in whether the code being presented does what it needs to do. That it meets the expectations of the users.
The rest of the scrum team wants the Product Owner to be happy with the functionality of the code that has been presented, and that the label on the tin matches the contents.
What if the Product Owner does not approve the code?
If there are issues with the code and the Product Owner feels that it misses the mark, then the associated user stories are put back on the backlog. At the next sprint planning session, the backlog is prioritised, each user story is estimated and the scrum team pulls user stories into the sprint plan until the total number of user story points aligns with the team’s velocity.
Who prioritises the backlog?
The Product Owner. That’s who. And who agrees the sprint plan? The Product Owner.
But here’s the thing – and this is the bit that organisations find difficult to implement – the Product Owner is part of the scrum team. 100%.
A member of the Business community working alongside programmers, business analysts, testers, business representatives, architects, plumbers, electricians and brick layers – on the same team. Together. Every day.
And there’s the problem.
4. User Story Writing
The user story represents a “bucket of business value”. If the user story is implemented, the Business will reap the benefits of the value it offers.
So long, that is, that the programmer’s code actually achieves what is represented by the user story, and what the user wants. In other words, if the programmer writes code that will satisfy the business requirements, then good times.
So where are the business requirements written?
In waterfall, they are written up in wopsy-big documents called Business Requirements Documents (BRD). But in agile, since the user story represents the “business value”, the requirement and hence “a good thing that the business wants to be able to do”, the best place to specify the business requirements is the user story itself.
And that’s what we do.
There are lots of guidelines about how to write user stories, but the best way is to think about the “actor” who will be using the functionality represented by the user story and the benefit it will give them.
As an iPhone user, I want to be able to change the time zone manually, so that I can work to Indian Standard Time (IST) while in London.
Is that enough detail?
Well, that depends. Can you build it? Can you test it?
We want to do just enough work, to ensure quality and good delivery. We want to reduce defects, because they just end up being prioritised along with everything else on the backlog in the next sprint.
So we want to write this user story in the most effective, efficient, economic and accurate way possible – so long as it meets the business requirements.
Do we need to specify in the requirements, the list of time zones that the user can chose from? Do we need to specify the need for a “confirm” button? Maybe, maybe not.
Luckily on the scrum team is a member of the business – The Product Owner – and some Business Analysts who are familiar with that particular area of the business, plus a QA expert and – of course – a programmer. So together, writing the user story should be a doddle.
Remember, the agile manifesto states as one of its four values:
Working software over Comprehensive documentation
So as long as we’ve got enough information to build, test and demonstrate to the Business, then we’re good to go.
This is quite a simple example though. Imagine a more complex example where we’re providing a screen to validate new car insurance policy details. A simple statement like the one above simply won’t hack it.
As a policy administrator, I want to be able to validate the current policy and highlight any errors so that I can work with the user to correct them and proceed the application to the next stage.
All very dandy, but let’s ask the same questions as we did before:
Can you build it? Can you test it?
Well, no you can’t do either. We don’t know what to code. We don’t know what the validatation rules are. So in this case, economic though it is, it doesn’t actually help us at all, other than to summarise a requirement.
We need to specify the validation rules, which can be included within the userstory – either in text, or as separate tasks – depending on the house style.
Writing user stories is a new way of thinking. Often, when teams transition to agile, the quality of user story writing is one of the main stumbling blocks for success. Not enough detail, too much detail, hidden context are the usual suspects.
One of the great misapprehensions in modern-day business change and IT organisations, is the idea that with agile there is no documentation. No governance. No leader. No discipline required. It’s a method were you can just crack on. Get stuff done. Ditch it if it doesn’t work and try again. Oh, and we don’t have to do a wopsy big requirements document. Whoopy doo.
Well – Yes, you do.
No, you can’t just crack on. No, you can’t just ditch it and start again. Yes, discipline is required. Yes, there’s governance. Yes, there’s documentation. Yes, there’s a leader.
In fact, in many ways, more discipline is required to run agile effectively.
- Because everything is condensed into two or three week sprints. Plan, analysis, design, build, test, integrate.
- We have to bite off enough work from the backlog to keep us gainfully employed during the sprint, but not too much, and not too little – and we need to work at getting better at estimating what this looks like – so we can get better next time.
- We need to work as a team, a cross-functional team, sharing goals and objectives, taking joint ownership, responsibility, accountability.
- We need to get better at how we work as a team – how we write user stories, how we test them during the sprint, how we get better at understanding the strengths and foibles of everyone on the team, so we can fill the gaps, strengthen the foundations, distribute knowledge.
- We need to get better at delivering working, tested, code the first time round – to reduce the number of defects which will just end up on our backlog another time.
- We need to get better at getting better. Kaizen, the Japanese word for “improvement”, has been adopted by the agile world to represent not just improvement, but continuous improvement. Or as I like to call it relentless improvement. Getting better is part of agile. It is ubiquitous. Or at least, it should be. A team should always be looking at ways in which it can get better at getting better.