Everyone loves a roadmap

In agile programmes people prefer to talk about roadmaps rather than plans. This post is about the reasons behind this and the benefits of using a roadmap rather than a gantt chart to manage pure agile, or mixed methodology programmes.

Peoples' Front of Judea

Plans can be a cultural battleground between the traditionalist and agilistas. They needn’t be. Both camps need an artefact to guide them towards a longed for future and a roadmap provides something for everyone to cling to.

Managers and stakeholders often ask when something will be ‘done’; What are the milestones? Are we on track? What are the dependencies? What is the critical path? These are natural questions to want to ask. Waterfall and agile methodologies answer them in different ways with very different artefacts.

The Waterfall-istas reach for MS Project or equivalent gantt tool to make sense of the world. The agilistas use a backlog, prioritisation, continuous delivery and feedback loops to make sense of theirs.

Agilistas will say “we love planning… just not plans”. They hate gantt charts because they offer only false certainty and often do not sufficiently accommodate change. In the wrong hands they will stifle learning and continuous improvement, as teams switch the focus from delivering outcomes to keeping to ‘the plan’.

Continuous, adaptive planning is an awesome part of agile. Good, informed prioritisation, that factors in the cost of delay, risk, business value and dependencies is perfect for wholly agile teams, but it’s not for everyone.

Not everything is software or agile

My particular experience is in the delivery of digital public services for government. Mostly these programmes of work are not just about digital. They may include a change to an organisation’s operating model, training, buildings, telephony… Often the (least lean) bits of service delivery that many agile teams sometimes consider as “the business-y bit” – bywords for “waterfall” and “dealing with the non-converted”.

Traditionalists charged with managing these types of programmes see no alternative but to add agile sprints to the large MS project plan. In the past, for example, I’ve been asked to provide themes by way of labels for six months of two week sprints and this is not good — for anyone.

They get frustrated with agile's lack of plan and I understand their concerns. I’ve seen agile planning ceremonies used as a smoke screen for short-term planning only. That’s being über agile, right? Yes it is, but sticking with that mindset can alienate stakeholders and co-deliverers who demand a better picture of the future.

A roadmap is the droid you are looking for...

A roadmap bridges the gap between worlds.

• Something for everyone - it is an artefact that traditionalists recognise enough as a 'plan' and agilists recognise as 'not a gantt chart'.

• Focuses on outcomes not deliverables -it promotes the right sort of strategic conversations within teams and with stakeholders.

• Provides stability but evolves - it sets a clear, stable sense of direction but I find teams and stakeholders feel more comfortable discussing change resulting from iterative delivery and learning.

• Promotes buy-in -good people will feel out of control and disengaged when deliverables are dictated up-front and/or from above. Self organising, multi-disciplinary teams love to own and be empowered to meet outcomes in creative ways.

• More coherent - it allows you to knit all aspects of your programme together (e.g. software, infrastructure, ops, policy, security, estates, human resources, procurement) without freaking out any horses or doing up front requirements specs or giving false certainty.

• Better performance metrics -outcome based planning allows programmes to more easily measure the evolution of a service through early stage delivery into full blown operation and iteration. Some metrics will be a constant throughout, others will only have relevance in later stages. This approach keeps you iterative and chasing incremental improvement. It also makes for joyful dashboards.

• Better governance -roadmaps work well with time-boxed or target-based governance gates -- you choose.

There's something for everyone to like about a roadmap.

In my next post I'll talk how to put one together and how language can be used to find common ground.

Crowdsourcing Christmas

I left my present buying to the last minute again.  Usually we share Christmas wish lists but this year we didn't. I was stuck for present ideas and the prospect of browsing around the shops for inspiration was filling me with dread.  So this year I crowdsourced ideas for presents from my team mates.

As a bit of fun at our last stand up meeting of the year, I said I was blocked on present ideas; today I was running a Christmas workshop and all fellow hopelessly organised people could join to get some ideas together.  Phil whacked on the Christmas tunes, Sarah got the coffee pot and off we went to a white wall.

People with presents still to buy put the name of their gift-less recipient, age, relationship, a budget and a list of  'likes' on a big yellow post-it and stuck them on the wall.  It was great fun and you learn loads of funny stories about your team mates' families.

Next, everyone had 5 mins to jot down ideas for other peoples' gift-less friends and family and stick them on the wall.  Within minutes we had loads of great ideas that we'd individually not thought about. Like, BRILLIANT STUFF!

Next year I will try and do it sooner than the last Friday before Christmas. And I'm banking on Dad not reading this before Christmas or else it will ruin the the surprise of his Dad Rock inspired present.

GOV.UK wins Design of the Year

GOV.UK won the Design Museum's Design of the Year. This is brilliant news. The judges recognised that the simplicity of the visual, information and content design could have a positive impact on many peoples' lives when interacting with the complexity of government. Exactly what we set out to achieve back in February 2011.

My cousin was quick to point out that I was the project manager and therefore this had nothing to do with me. Whilst the design team rightly feel chuffed by this award, it was a coming together of a talented, multidisciplinary team that made this possible. As the second member to join the team that built the alpha I recognise the evolution of the design rules into the product today. Tom gives a good summary of the journey and some of the artefacts that went into GOV.UK.

Related

• Storify of press and coverages

What I've learnt about scaling agile to programmes

This was first published on the Cabinet Office website. Well, we did it! We delivered GOV.UK. It was big and hairy and we did it by being agile.  The benefits are clear:

• We were more productive: By focussing on delivering small chunks of working product in short time-boxes (typically 1 week development sprints) we always had visible deadlines and a view of actual progress. This is powerful stuff to motivate a team.

• We created a better quality product: We used test driven development; browser and accessibility testing were baked into each sprint and we had dozens of ways of testing with real people as we went along to inform the design and functionality of the product.

• We were faster: By continually delivering we were able to show real users and our stakeholders working code very early on and get their feedback. What you see now on GOV.UK was there in February, albeit in a less fully featured and polished way. Lifting the lid on it did not seem like a big reveal; it felt like an orderly transition.

These characteristics are true of all our projects, but I wanted to talk about agile at scale with 140 people and 14 teams and what I've learnt. In so far as I know this is a relatively new area and there is not a consensus view of how to do it.

Be agile with agile

The foundation of this success was people that were agile with agile. Props to people like Richard Pope who helped set the tone of our culture at GDS, which is one where people are open to learning, improving and workspace hacks without the dogma of big 'A' agile. It’s all about that. If you don’t have this embedded in your teams then what I write below doesn’t matter.

Lesson:  a working culture that values its people and embraces experimentation is essential to success.

Growing fast is hard

We grew from a cross-functional team of 12 for the Alpha version of GOV.UK, to a programme of work involving 140 people over 14 teams. There was a period from April to June where we grew 300% in three months, which was crazy but felt necessary due to the scope of work.

Our expansion was organic and less controlled than our original plans had suggested. Had we focussed on fewer things from the outset, the overhead of getting people up to speed and the additional communication needed to manage this would have been far less and our momentum would have increased.

Lesson: We should have committed to doing less like the books, blog posts and experts say.

Don’t mess with agile team structures

Clearly defined roles within teams as Meri has said are vitally important. Our teams emerged rather than beginning the project formed with the core roles in place. The consequence of this compromise was a blurring of roles which meant that certain people took on too much. In these teams people faced huge obstacles around communication, skills gaps, confused prioritisation and decision making and ultimately productivity suffered.

Lesson: This experience reinforced the importance of agile team structures. Don’t mess. The team is the unit of delivery!

Stand-ups work for programmes

When you have a team of 10 people conversations can happen across a desk or during stand ups. As we expanded rapidly communication became increasingly strained. There were fewer opportunities for ad-hoc conversation and talking between teams was harder. We solved this with a programme level ‘stand-up of stand-ups’ attended by delivery managers from each team.

We had up to 14 people and we nearly always managed to run it within 15 mins. We held ours twice a week which gave us good visibility and opportunities to help each other. People willingly came along, which I take as a good sign the meeting was valuable.

Lesson: In the future we’ll probably split this into another level of stand-ups so we have one for teams, one for working groups of teams (or sub-programmes) and one for cross-GDS programmes.

Monitor with verifiable data

We organised the programme into working groups which had one or more teams. Most teams used a scrum methodology and split their work into releases (or milestones), epics and user stories.

By tracking these we generated verifiable data about progress, scope completeness and forecasts of delivery dates. By aggregating this data we created a programme dashboard for teams and senior management.

The image above shows the GOV.UK programme dashboard. This view of the programme was created using data generated by the teams doing their day-to-day work using tools like Pivotal Tracker and was not based on subjective reporting by a project or programme manager. The callout shows two milestones for two different teams. One was completed, the other is shown to be 90% complete with an estimated delivery date a month later than our target date. This was verifiable data based on the number of stories and points left to deliver the milestone with historical data on a team’s speed to build, test and deploy the remaining scope.

This was the bit that made me most happy and made tracking and managing the programme much, much easier than gantts.

Lesson: Use independently verifiable data from your agile teams to track your programme

Use Kanban to manage your portfolio

We used a system of coloured index cards to map out the components of the programme. This captured key milestones, major release points and feature epics and because it was visible, it encouraged shared ownership of the plan and adaptive planning throughout the delivery.

We gathered Product Managers, Delivery Managers, the Head of Design and the Head of User Testing around this wall every two weeks to manage our portfolio of projects and products. The process forced us to flag dependencies, show blockers and compromises.

Lesson: This approach was successful up to a point but in hindsight I wish we had adopted a Kanban system across the programme from the outset. It would have provided additional mechanisms for tracking dependencies, limited work in progress and increase focus on throughput. I would also formalise a Portfolio Management team to help manage this.

Everything you’ve learnt as a project or programme manager is still useful

When I started using agile, someone said me, “when things get tough and you want to go back to old ways, go more agile, not less”. This has stuck in my mind.

When I was designing the shape of the programme and working out how we would run things I wanted to embed agile culture and techniques at its heart. For example, we used a plain English week note format to share what happened, what was blocking us sprint to sprint rather than a traditional Word or Excel status report.

In tech we always say we’ll use the right tool for the job and in programme management the same is true. In the same vein I opted to use a gantt chart as a way of translating milestones and timings to stakeholders but internally we never referred to it and were not slaves to it.

Risk and issue management is an important aspect of any programme. The usual agile approach of managing risks on walls scaled less well into the programme. Typically in smaller teams you might write risks, issues and blockers on a wall and have collective responsibility for managing them. We scaled this approach to our stand up of stand ups and this worked well for the participants: it was visible, part of our day to day process, we could point at them and plan around mitigation.

But there was a moment when the management team asked for a list of risks and issues and pointing them at a wall was not the best answer so we set up a weekly risks and issues meeting (aka the RAIDs shelter) and recorded them digitally. This forum discussed which risks, issues, assumptions and dependencies were escalated. By the book it fits least well with the agile meeting rhythm but it gave us a focal point to discuss concerns, plan mitigation and fostered a blitz spirit.

We have some way to go to make it perfect but we have learned that within GDS agile can work at scale. We’ve embraced it culturally and organisationally and we’ve learnt an awful lot on the journey. Some of the lessons we've learnt have already been incorporated into how we’re working now and I look forward to sharing more about this in the future.

1969 MGB GT for sale - £3500 - [UPDATE: THIS IS NOW SOLD]

I'm selling my much loved MGB GT.  It's served me well, but I've got to the stage where I'm hardly using it and it deserves a new home.

It costs £0 in road tax and about £130 a year in insurance; Passers-by smile at you and kids go 'look daddy!' - all of which makes this a great car to own.

There are photos of the car over on Flickr.

Quick advert

Extensive history dating back to purchase date and provenance. 53k miles from refurb. It’s a very practical and cost effective classic British car.

I have the full history of the car and much of the documentation dating back to 1970.   Since I’ve owned it, it’s been serviced properly and expertly by  classic car specialists G Grace & Son in Tring.  I have fitted a wooden steering wheel, an electric fan (more fuel efficient and keeps it cool when not moving in traffic), an electronic distributor (runs smoother and better at starting in the winter) and I have replaced the 2x 6v batteries with a modern 12v battery.  It has been Wax-Oiled and has plastic wheel arch protectors.

Provenance

This car was owned by Geraldine, the daughter 1958 Formula One team owner Tony Vandervell. Tony owned Vanwall which was Stirling Moss and Tony Brooks’s team. This little MG was a 21st birthday present for her and fitting of her dad’s wealth it had every significant extra fitted (overdrive, webasto sunroof, wire wheels, laminated windscreen)

If you're interested then contact me via Twitter or at hello[at]jamiearnold.com.