Thursday 14 June 2012

Translating roadmap items to actual stories


We have found that sprint planning sessions go a whole lot quicker when we know the details of the stories ahead of time, including having architecture discussions and working out any dependencies on other teams well in advance. I can't tell you how many sprint planning sessions have been side-tracked by lengthy discussions about architecture, coding approaches or why the piece of work is more complex than anyone originally thought. Our sprint planning sessions could take 4 hours in the bad old days, even when we tried to timebox our discussions.


Planning ahead without the team

Here's how our process used to work:
  1. “Next Sprint Goals and Roadmap”
    Who: Product Manager and Project Manager
    What: Establish the next sprint goal, list the epics in priority order and plan the epics for 3 iterations in the future (headlines only, no detail in the epics)
  2. “Pre-sprint Backlog Pruning”
    Who: Product Manager, Project Manager, Lead Developer & Senior SE
    What:

    • Review next sprint goals
    • Review epics in priority order with a view to breaking them down in advance of sprint planning
    • Take a realistic look at what’s achievable in the sprint.   
  3. “Sprint planning”
    Who: Entire team
    What:

    • Features are explained by Product Manager
    • Team commits to a number of points based on the velocity of the previous sprint, plus any upcoming training/absences.
    • Tickets are pre-prepared using templates to include Definition of Done, NFRs, Tests, etc.
    • Priority of tasks is reviewed again with Product Mgr.
    • Tasks are pointed and anything over the threshold is moved to the top of the Backlog
    • Release tickets and load testing tickets are raised.
    • Cards are printed out for the wall.   

What's missing?
 
In the weekly "Next Sprint Goals and Roadmap" session, the Product Owner and Project Manager worked out a roadmap detailing several month's worth of planned work and put it all up on a board in plain sight of the team. The thinking was that they could get on with the forward planning without having to take the team away from their work and that the team could then see the headlines that came out of the session. It felt pretty comprehensive and efficient. However, funnily enough....

 
It turns out that visibility on the wall doesn't translate to a team understanding of the upcoming work.


The team were at a loss as to how we could manage to get "on the front foot" and close the gap between high-level roadmap items and actual, broken-down-and-estimated stories.



What's missing is the team!

One of the major themes of our Sprint Retrospectives was Teamwork, and how we could achieve visibility of upcoming work. How better to do this than to involve the team earlier in the planning activities?

We gave it a try, expanding the invite to the "Pre-sprint Backlog Pruning" sessions to the entire team.
It worked a treat! Instead of the team first hearing about upcoming work as an email of headlines before sprint planning, and only getting a full explanation at the start of the actual planning session, they began to hear about the stories several days ahead and could have time to prepare tickets and think about their approach.

Now, we're working on ways to increase visibility of upcoming work even further and have introduced a Readiness Board as an experiment. 

Thursday 7 June 2012

Using scrum of scrums for Portfolio Management

In departments where there are several teams working to a single portfolio or programme of work, it is possible to create an Agile org structure which maintains focus, communication and transparency while managing dependencies and risks.


Using scrum to manage the portfolio


For an enterprise-scale department or a small firm that manages a wide range of products, the best way for them to be properly tracked is by establishing a portfolio. Although the term "Portfolio Management" can often smack of old-school, traditional "Waterfall" project governance, it is absolutely possible to eschew portfolio management in the traditional way, and instead to adopt Agile portfolio management using scrum.

Begin by developing a scrum backlog which covers all of the product workstreams and operates in a portfolio scrum team, similar to the normal scrum team, but with a Portfolio Owner (akin to Product Owner) and a Portfolio Master (akin to Scrum Master) to ensure scrum is used to manage the portfolio backlog, following all the standard scrum rituals but on a programme level.

There are a number of benefits to this setup. Once a Product Vision is established which encompasses the entire programme of work, an org structure like this is a way of ensuring focus on that vision and that the right products are being prioritised across the entire portfolio. Having a sprint retrospective for the portfolio team means that progress of each sprint is reviewed across teams, allowing you to assess how the teams are doing, and ensure priorities and customer commitments are being met. Once a velocity for the entire portfolio can be established, it becomes possible to estimate deliveries across multiple teams and flex resources between teams in accordance with demand.



Each scrum team has a Product Owner and a Project Manager and/or Scrum Master. Each scrum team holds its own scrum activities, and then reports to the Portfolio scrum-of-scrums to join the dots between the workstreams.


In addition to participation in the portfolio scrum team, the PMs should be responsible for:

- Short, medium and long term plans for the entire programme of work
- Resource allocation of scrum teams
- Working with Product Managers to funnel projects and work items to teams
- Ensuring projects are vertically sliced in a way that resource can be assigned/withdrawn in an agile manner


Stakeholder focus


Drawing it all together means you can have unified reporting, metrics and demos for presentation to senior stakeholders and you'll be able to consult one place to get info on all products in the portfolio rather than chasing individuals in different teams or across multiple locations.


Team organisation


This approach allows a large pool of resource to be structured into small, fluid (but colocated) scrum teams working in a scrum-of-scrums environment across the entire portfolio of the department's projects.

Colocation is a strong success factor in this kind of setup. If you are joining remote teams into the portfolio, they should be colocated rather than splitting teams with members in different locations.

Teams in a portfolio scrum-of-scrums should have:

- Combined monthly sprint demos where every team in the program presents
- Quarterly release plans defined for each team, as well as the department as a whole
- Shared sprint cycles across teams

A structure like this allows for mobility between teams as well as career progression for individuals, as several individuals can take on Scrum Master roles and teams can become more cross-functional and be exposed to a variety of products within the portfolio.