agile

Governance - there is a better way

in

Teams using lean and agile ways of working often rub up against traditional modes of governance which can slow them down or demoralise them.  Governance can become a blocker.  I drew this picture describing how that can feel..

Hierarchies and imposed structures, designed to simplify and streamline management become process overhead that disempower teams.  The forums used to make decisions become distant, far removed from the reality of delivery.  Teams often feel the pressure of delivering to please their sponsors rather than their users. Governance becomes an industry and the currency of success becomes dates, deliverables and documents.

Instead, organisations wishing to embrace lean and agile ways of working should promote governance structures and behaviours that:

  • Focus on outcomes, not deliverables - because truly understanding and driving towards an outcome (e.g. something starting/stopping/continuing, people feeling different, changes of behaviour) is much more valuable than focusing on the delivery of a thing (an artefact, a feature, a system) that might, you guess, produce an outcome.  Focus on the change you desire, not on delivery of the bet you’ve placed. Unlearn the muscle-memory of caring most about dates and deliverables.

  • Measure what matters - agree how you’ll measure an outcome but also recognise that there’s a context for what’s meaningful to measure at any given time.  That a new product can successfully meet the core needs of 10 users is very meaningful in the beginning and that should be an organisation’s initial focus; be patient before you pile on the pressure to measure % uplift in sales or efficiency.  Be careful what you pick to measure and when to avoid unintended behaviours.

  • Ensure teams are the units of delivery - trust in multidisciplinary teams and let them get on with it.  Build a team, not a big up front plan. If you’ve communicated the right problem to solve to a team that are invested in solving it, with the right support around them, you will all have a higher chance of succeeding.  Good teams, with the right mix of skills and experience, figure it out.  Good teams fail when you give them a solution, a date, the name for the thing… and tell them how to do it.  People over process.

  • Establish networks of teams not hierarchies - because as soon as an organisation pre-determines a structure to deliver a thing they've exercised an upfront bias towards a particular solution.  Over engineered programme-level hierarchies produce noise; noise slows down self-organising, motivated teams.  By all means design and promote the glue between teams but do it organically, with teams not to them. Think about designing a supportive network, not inflicting unnecessary hierarchy and decision makers or forums.

  • Make quality everyone’s responsibility - because everyone involved needs to understand what good looks like and is responsible for delivering that. Don’t make quality assurance a ‘gate’, title or a role. Make it part of what a teams does every day.  Bake it into the way a team works and thinks.

  • Assure as you go - because using iterative ways of working and effective feedback loops gives an organisation regular opportunities to check that the right work is being done in the right way.  Try to avoid making assurance activity scary, lumpy or as a bolt on.

  • Remember that behaviours matter more than documents - because by regularly observing team behaviours (e.g. how they collaborate, communicate, validate their assumptions, seek feedback, measure impact, deliver, learn — is way more valuable than warm-fuzzies and false certainty of documented proof.  Go see delivery.  Witness running code and listen to feedback from actual users.

Fieldnote:

When I share this list with senior people their normal response is “it makes sense; it’s kinda what we do anyway”.  That’s always good to hear but I’ve learned that’s rarely the case.  For example, when I hear these things I know there’s a whiff:

“When’s the  x delivered?”

“This team sits in the x programme in the y work stream”

“We need to get Programme/Strategy/Ops/Security/Data board to sign it off”

etc.

In and of themselves each of these are innocent enough but they can add up to something significant.  They are the tells of how an organisation thinks about agility, risk, org structure (read: silos) and team empowerment. Maybe there’s another blog post in that.

*thank you to Ella and Amy who helped me structure my thoughts in the original, longer version of this post on Co-op’s blog.  I didn’t say that in that post so it worth saying here. 🙏

Seven questions to build a roadmap

in , ,

In my last post I wrote about why roadmaps are for everyone. This post is about techniques for building one and how the use of language can help align your pure agile or mixed methodology programmes.

In government service delivery programmes there's always a mix of methodologies between agile and waterfall. Some of this is cultural, some of this is for practical reasons. The techniques I describe below fit within this context.

header images for blog posts.001.jpeg

The prerequisites

The prerequisites for a good roadmap are good leaders and clearly articulated goals. If your future is driven from above by preconceived thinking or your teams don't emotionally buy-into the programme's goals it's not a happy place.

Good leaders set and articulate goals that inspire you.  They allow teams to challenge the seemingly sacred.  They empower them to come up with creative approaches to achieving strategic goals.  If you don't have these then your roadmap could end up as an exercise in group-think.

Ask 7 simple questions

Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask yourselves these questions*:

  1. What are we trying to learn or prove?

  2. Who are the users?

  3. What are we operating?

  4. What are we saying?

  5. What are our assumptions?

  6. What are our dependencies?

  7. What capabilities do we need?

A timeline is not dirty

The Waterfall methodologists feel comfortable with long timelines.  They typically work 'right-to-left' from a desired delivery date;  the agilists prefer to work iteratively, 'left-to-right' as much as, and where possible.  Whatever your preference, timelines are important and an inescapable part of delivering.  A timeline is not a dirty concept.

I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate "deadline" in everyone's head and to get them to think strategically.

Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don't become the only focus of conversation.

You get better roadmaps by asking questions

The language you use is important. Asking everyone to answer questions is good for finding common ground and helps get better inputs. Asking "What are we trying to prove or learn?" for each time interval helps people think about the evolution of your service and grounds it in iterative delivery.

The agilists are used to thinking about learning and value-based incremental delivery. They feels comfortable with it.  The waterfall methodologists typically think more about deliverables. That's OK, you can easily ask what are the outcomes they want from it? What will it prove when we deliver it? What will we learn from delivering it?

Ask how we measure stuff and set some sensible targets. These be your performance indicators (KPIs) and a step towards an awesome dashboard for your programme.

Who are the users? Everyone wants to deliver for users so no controversy.  No one is itching yet.

"What are we operating?" gets people thinking about the service as a whole and how it will work and evolve over time.  Talking about it with everyone helps. It gives teams focussed on digital a feel for challenges of the Operations folks (e.g. in the job centre, in warehouses, on the service desk) and Operations get to say how they want to rollout and operate it.

Capture assumptions and dependencies whenever they come up in conversation.  That always helps bonding.

A roadmap can write your comms plan for you. By asking "what are we saying?" (to your organisation, your users, the press) for each time interval you are telling the story of your evolving service.  The Comms folks are now itching but I think it is excitement not concern.

Capabilities are to do lists for everyone

Finally, "What capabilities do we need?" (to operate the service). I find everyone gets the word capability after a gentle nudge (e.g. pay, inbound-telephony, search, dispatch, training). Add a description and an owner to each one if you can. Describing them and giving them a label is hard but both the agile and waterfall camps understand the word and can come up with a sensible list of them.

The agilists, especially the architects, can begin to see the beginnings of their systems, the epics and minimum-viable features within their backlogs. The waterfall folks can imagine their gantt charts and what needs doing by when.

Show it off. Get people talking about it

These techniques give you a holistic view of the service from a near standing start. This exercise does not answer everyones' questions. There's still uncertainty and no one feels 100% comfortable with the unknowns, but you have the backbone of a strategic approach. One that is grounded in user centred, iterative delivery and provable outcomes.

Everyone can take something away with them and use it to inform their own planning activities - whatever they are. Turn it into an illustration if you like. Present it to important people. Keep pointing at it, talking about it and improving it.

This is your roadmap.

* I want to credit Richard Pope who came up with some of these questions on the hoof when I did this for the first time. I've run with them and tweaked.

What I've learnt about scaling agile to programmes

in ,

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.