The "How would you spend £1000" prioritisation exercise

We did a 3-hour session the other day to come up with requirements for a open tender procurement, with a large group of stakeholders from around the organisation. Each stakeholder was coming from a very different angle on the problem, and the challenge was how to arrive at a set of commonly agreed requirements in priority order, with some idea of how they would be scored in the tender process.

The exercise we ended up doing was actually pretty fun and a good way to lighten up a long session.

Here's what we did:

1. Before the session, collect some play money (either from a board game or create your own) in a number of denominations
2. Once all of the requirements are written on index cards, lay the cards on the table
3. Give each participant their "budget" (in this case, our budget was £1000, divided into £200, £100, £50 and £20 notes)
4. Get everyone to "spend" their money on the requirements, piling their money on top of the index cards
5. Send the group on a coffee break and tally up the piles of money on each card
6. Arrange cards in descending order of money spent on them.

By the end, we arrived at a linear priority list of requirements. Some were surprised by which requirements floated to the top, which generated useful discussion and thoughts on how we can expand the sub-criteria for those categories.

How do you do your priorisation exercises in a large group workshop?

Measuring team happiness

At this sprint's upcoming retrospective, I plan to try a new exercise, involving measuring the happiness of the team.

We've attempted this in the past, with everyone drawing a graph of their mood throughout the sprint. This proved fairly useful in identifying factors (often external to the team) which brought down morale during the sprint.

The massive drop in morale was when our application failed load test which blocked the live release.

We tried this method for 6-7 sprints, but eventually the graphs fell out of favour because nobody felt it was giving us that much value in terms of concrete actions to resolve issues and improve morale.

So, this time round, I want to try a slightly different tack, the Happiness Metric.

I'll ask the team 4 questions, and get them to write their responses on sticky notes:

1. How happy are you with your team?
2. What feels best right now?
3. What feels worst right now?
4. What would increase your happiness?

I'm actually considering making a little Survey Monkey mid-sprint to gauge the team's happiness, and have something to compare it with at the end of the sprint, but I'm not sure how valuable that will be.

The Kanban Coffee Shop

The principles of a Kanban, as defined in David Anderson’s Kanban, are:

• Visualise work
• Limit work in process
• Measure and manage flow
• Make process policies explicit
• Use models to recognise improvement opportunities

Kanban barristas

A couple of weeks ago, our team found out how similar a Kanban software team can be to a coffee shop. The guys from Agility in Mind did a great exercise with us where we were suddenly morphed from a development team into a group of (comically terrible) barristas.
 
They set up stations around the room for:

• Customer orders
• Coffee shots
• Milk/foam

With a few constraints in place, we were then set to work on creating a flow for customer orders. Feedback from our coaches was that it was an incredibly painful thing to watch.  

In the first round, orders came in very fast, which rapidly overwhelmed the coffee shot station, creating a backlog. By the time the orders got to the "customer", 75% of them were wrong!

Rather than listening to the customer (who was literally standing in the corner calling out "Hellllooo??"), we instead gathered together to see how we could improve.

We added Quality Assurance as the final step in the process, and we flowed a bit more smoothly the second time around. Again, we ignored the customer's entreaties.

Finally, we gathered together and proposed a radical change: rather than handing the coffee cup from station to station, we would travel with the cup until it was complete. With this change, people went from specialists to very confused generalists, which resulted in the longest round of drinks with very poor quality for the customer. Epic fail!

Comparison of barrista work to software development

In the end, we learned a bit more about creating an efficient flow, as well as the major lesson of listening to our customer.

Ash Moran at Patchspace explains it well...

What happens from the coffee shop’s point of view is this:

• You, the customer, arrive at the customer queue, and you do so randomly (at this point, you wait)
• A barista takes your order, a list of random drinks – that is a batch of work to be done, of variable size, complexity and value
• Your order goes in a queue (at this point, not only are you waiting, but so are the drinks)
• One or more baristas make your drinks, that is, the batch of work gets processed (you’re still waiting)
• A barista hands you your order, that is, the completed batch of work

Before we go on, just reflect how similar this is to software:

• The client / business turns up with a “new idea”
• The client describes some work they want you to do (which will be of variable size, complexity and value)
• You put the request in your backlog
• At some point, one or more developers become free and turn the request into working code (which will take a variable amount of time)
• You deploy the software/deliver the code, etc

So if you can accept that an index card describing the new feature “View product listings by category” is more or less the same as an empty coffee cup waiting for a drink, the two processes become coherent.

What are your experiences with a shift from scrum to Kanban? Any ideas on how to create a more efficient flow of work?

Improvement Experiments Kanban

The team are very keen to always improve their agile practices, with many suggestions coming out of each sprint retrospective. Some of these get implemented, stick, and become part of the new way of doing things. Others fall by the wayside and are forgotten.

Improvements can be things like:

• Implement pre-dev checks to explain the work that will be done
• Rotate the scrum master role around the team to keep it fresh and ensure everyone is involved
• Create a Readiness Board to ensure stories are prepared enough to go into a sprint

We had a few excellent sessions with Matt Wynne and his colleague Rob last week, where they helped us to focus our improvements.

The Kanban board is courtesy of Agility in Mind, and was re-purposed to become an Improvement Experiments board for the team.

The idea behind the Improvements Experiments is that, rather than just a collection of "good things we should be doing", some structure gets added to the process improvement.

Here's the process in a nutshell from Matt & co:



We've already started tracking items on the board, and so far have proven 3 experiments. So it seems that we're onto something here!

Have you had any success with methods of tracking the improvements your Agile team suggests during the sprint retrospective? Please comment and share your experience.

Impediment Removal Team: Scrum on an Enterprise scale

With a view towards improving our agile implementation on an enterprise level, I recently formed an Impediment Removal team within my department, with the goal of resolving any blockers which can’t otherwise be removed by our teams on their own. The scope is any impediment which the scrum master or scrum-of-scrums has tried to resolve on their own, but is getting no traction. 

The group is the next layer up from the scrum-of-scrums held in each product team and acts as a funnel for issues into and out of the senior management team. 

Our department is made up of 8 product areas which can easily operate in silos if we don't take extra care to communicate and find commonalities in our practices.


The idea here is to resolve any impediments caused by intra-team communications or process difficulties, escalate any impediments we’re unable to resolve, and share any systemic/org-wide impediments with our colleagues in other parts of the organisation, so that we can find a common solution. The group gives scrum masters and project managers a point of escalation in the delivery chain and (hopefully) prevents long moaning sessions where the same topics keep coming up but never gain ownership or traction.


Ground Rules for an Impediment Removal Team

• Keep it short, sharp, and focused, like a team standup.
• A fortnightly meeting, time-boxed to 30 min. if possible.
• Each representative brings the top 3 impediments – they should be showstoppers and apply to more than one team
• Actions to be agreed, each item has an owner
• Long discussions to be held offline, items time-boxed to 4 minutes each
• An initial kick-off session to set the context, agree a communications plan
• Each fortnight, the prioritised list is published to the department

FURTHER READING
http://agileconsortium.blogspot.co.uk/2011/01/impediments-management-2.html
http://agileconsortium.blogspot.co.uk/2011/10/scrum-team-in-waterfall-land-what-to-do.html
http://agilecoachingforteams.blogspot.co.uk/2012/03/impediment-removal-team-part-i.html

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. 

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.