In this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.

Come and play with us!

This will be two days of engaging discussions around Agile in General. Don’t expect polished presentations, it’s all about sharing ideas and interaction.

To learn more about the Open Spaces concept, check out the description.

This Agile-fest is kindly hosted again by IBBT.

In this edition, we would like to support learning/exploring ‘Agile’ by experience and call upon your imagination to come up with agile simulations, games. Of course plain old discussions are fine too!

Register now.

See you there

to inspire each other and

to learn how using serious games can help us achieve our goals

I’ll attend the Play 4 Agile open space conference in Frankfurt, Germany from February 18th to 21st. I expect to learn more about creating and facilitating learning experiences. And have fun too, of course!

Follow @play4agile or #p4a11 to see what new games come out of the conference.

Juan Gutiérrez Plaza has contributed a Spanish translation of the Business Value Game. Thanks also to Leo Antolí and Thomas Wallet for reviewing this translation. Muchas Gracias!

You can download the Business Value Game in English, French and Spanish from the Belgian XP site.

When we first start to improve processes, the situation is daunting: we can see so much that can be improved. Where do we start? What will have the biggest effect? And when we’ve done that, what do we do next?

The “Theory of Constraints” gives us a simple and powerful framework to guide our process improvement: “The Five Focusing Steps”.

Step 0: What is the goal?

The first and most difficult step is to determine (and agree on) the goal of the “System”.

Before we can do that we must determine what the System is. As a rule of thumb the System equals the “Sphere of Influence” of our Client: everything that our Client has the authority change.

To determine the goal of the System, we must ask ourselves “Who uses the results the output of the System and what do they value?”. We try to find metrics that measure the amount of valuable output we produce. The Theory of Constraints calls this the “Throughput” of the System.

On the “B” project, our goal was to release valuable features that were actively used by our users. Our measurement was the “Business Value” estimate that our onsite customer put on each User Story.

What is your system? What is its goal?

Step 1: Where is the bottleneck?

The fundamental insight of the Theory of Constraints is this: “the output of any system is determined by one bottleneck.” A chain is as strong as its weakest link. If we want to make the chain stronger, we need to work on the weakest link.

At the start of an improvement process, the bottleneck is easy to spot. A bottleneck resource is:

• Always busy. But busyness isn’t the only (or even a good) criterion by which to recognise bottlenecks. Many systems are mistakenly optimised to get high utilisation (or rather busyness) out of all resources.
• Work piles up in front of them.
• Downstream resources are regularly idle.

The development team was the bottleneck. We had a list of features that was piling up in front of us. It would take us several releases to implement our backlog. Users were getting impatient for features to be implemented and deployed.

Where is your bottleneck?

Step 2: Exploit the bottleneck

If the output of the system is constrained by the output of the bottleneck, we must first try to increase the output of the bottleneck. Any idle time of the bottleneck reduces output of the system. What can we do?

• Remove any non-value adding work.
• Remove or limit interruptions. Remove impediments.
• Let the bottleneck resource work at a steady pace.
• Provide high quality tools and materials.
• Carefully prioritise the bottleneck’s work so that they always work on the most important tasks.
• Ensure that there’s always enough work to do for the team (the backlog), so that they don’t become idle through lack of input.

As team lead, I received and prioritised all incoming requests and questions. As I could deal with most of them, the team wasn’t interrupted.

Production issues needed to be handled quickly. All issues were handled by me and one developer. The bugfixer role rotated after every bug. This provided a nice balance between keeping the team focused on developing the current iteration and ‘feeling the pain’ of production issues.

I made sure that everyone worked at a sustainable pace. No more overtime!

Warning: don’t shield the team from useful information like input from the customer, production issues, installations and feedback from users.

We start by fully exploiting the bottleneck because this type of improvement is relatively easy:

• It requires no extra cost or investment.
• Only one resource is involved.

How can you exploit your bottleneck?

Step 3: Subordinate every other decision to the bottleneck

When we’ve fully exploited the bottleneck, we must subordinate every other decision to our decision to exploit the bottleneck. All the resources that aren’t bottlenecks have, by definition, some slack. Use that slack to support the bottleneck. We can subordinate by:

• Letting the non-bottlenecks help the bottleneck or take over some required but low value adding work.
• Everybody works at the pace of the bottleneck, no faster no slower, to avoid overloading the bottleneck with work in progress.
• Those in front of the bottleneck ensure that the buffer of work for the bottleneck is always filled, but not too much.
• Those after the bottleneck ensure that they have some slack to deal with variations in output of the bottleneck.
• Non-bottlenecks ensure that only high quality work in progress handed to the bottleneck.

As team lead, I subordinated all my work to the team: whenever there was a request for the team, a production issue or an impediment, I dropped all my work and supported the team. I quickly learned that I shouldn’t commit to delivering stories. My contribution to the team was less in contributing to its throughput and more in protecting the throughput of the rest of the team.

The onsite customer performed acceptance testing on completed stories every week, so that the developers got rapid feedback on the quality and fit of their development.

The onsite customer and I prepared stories for the next iteration and release, so that the team always had something to work on.

Subordinating is still relatively easy:

• It requires no extra cost or investment.
• Only a few resources, typically those that interact directly with the bottleneck, are involved.

However, there is one aspect of subordinating that won’t be accepted easily: whereas the bottleneck resources should be fully loaded, non-bottleneck resources must have slack time to be able to support the bottleneck and deal with variations. Most managers are evaluated on the efficiency and not the effectiveness of their people. Deliberately making people work below their capacity goes against their goals. We can solve this problem by fully loading the non-bottlenecks but ensuring that a part of their work is ‘discardable’, “nice if it gets done, but not essential or time-critical”. Whenever the non-bottlenecks need to support the bottleneck, they can drop the non-essential work to free up time.

Which decisions do you need to subordinate to the bottleneck?

Step 4: Elevate the bottleneck

This is the step most people will intuitively apply first: add more people, more machines, more training, more tools, more of everything. We only take this step when all the ‘free’ improvements have been performed. We can elevate by:

• Adding more people or machines
• Training and mentoring
• Better tools, faster machines
• Switching to a different technology

My manager asked me about every week if I wanted some more developers, if I “wanted to elevate my team by adding more people”. I declined, because we had plenty of room for improvement left with exploit and subordinate improvements. I asked if we could get faster computers instead. He told me we couldn’t because the hardware budget was exhausted. But there was budget for extra developers if I needed any…

Elevation improvements are more difficult because they require an investment. Elevation improvements are dangerous because most of these improvements take some time to produce results. Results might even worsen until the improvements start to have a positive effect. For example, when we add people to a team we lower the team’s velocity and accept less work while the team members help the newcomer get up to speed.

Don’t elevate yet. I know you can apply so many more exploit and subordinate improvements.

Step 5: And again!

When we’ve applied one improvement and have seen a positive effect, we go back to the beginning:

• Is our goal still valid? Is our measurement of throughput still correct?
• Where’s the bottleneck? After some improvements we may have solved our worst problem. As there’s always a bottleneck, our second-worst problem gets a promotion. We now need to focus our attention on the new bottleneck.

And the result was…

The team got better and better by repeatedly going through the five focusing steps. After a while, they started to develop stories faster than customers could write them. That’s when we needed to apply focusing steps six and seven.

I want to know more

Read the Goldratt books about the Theory of Constraints.

Download and play the “I’m not a Bottleneck! I’m a free man!” simulation from http://www.agilecoach.net

Read more about the Theory of Constraints on this blog.

Portia, Vera and I have published a new version of the Agile Coach website. There you’ll find coaching tools we use like games, tutorials and presentations. Topics range from introductions to Agile (the XP Game, the Business Value Game, XP Loops, First Five Steps to Become Really Agile), Theory of Constraints, Real Options, Toyota Way, Interviewing techniques to Agile Fairytales.

More materials and translations will be added. All of these games are licensed “Creative Commons“, so that you can use and reuse them. If you want to help translate or improve the games, let us know.

We run retrospectives after each session so that we can improve. You can read the results of the retrospectives on the Past Events page. This transparency allows you to verify if we really take the feedback into account.

Come and play at XP Days

If you want to play the “Business Value Game” or “Mirror, Mirror on the Wall… Why Me?” come and see us at the Mini XP Day Benelux in Mechelen, Belgium (May 11th) or XP Days France in Paris, France (May 25-26th). Or invite us to come and play in your company or usergroup. Or better yet, download the games and play them yourself.

What I liked

• Running the conference as a non-residential conference in the heart of London. Staying in a hotel literally around the corner. Morning running along the Thames.
• Interactive sessions like “Pitching Agile” and “Pairing: Beyond Programming” which challenge us to put our ideas to the test. Both sessions gave good opportunities to work in teams and reflect on what we value. And, of course, lots of Post-its were used to brainstorm, plan and explain
• Meeting old and new acquaintances inside and outside of the conference.
• Running the Business Value Game including a workshop with Vera and Portia. The game was designed to help our customers think about how they prioritise the project. The game doesn’t give answers, it raises questions. More about the workshop and its results later.
• Preparing and running a tryout of “The First Five Steps to Become Really agile“. A big thank you for the 7 intrepid players who gave us plenty of feedback to improve the session.
• The conference closing with concrete actions to follow up on the conference. I’ll have to write about cost and value estimation and about incremental funding and real options.

To make it perfect, I would

• Like to have a bit more room in the sessions and during lunches and breaks. The size of the venue was ok for the number of participants, but only just.
• Put some shorter sessions into the program. Two sessions a day (+ a keynote or BoF) doesn’t give much variety.
• Let presenters and organisers work together to improve their proposals collaboratively, like we do it for XP Days Benelux. The quality of the sessions and proposals improve a lot, even those from experienced presenters.
• Give session (and BoF?) presenters some time to pitch their session to help us to select the session with the most (business) value.
• Improve the Business Value Game presentation, so that the game is clearer from the start.
• Ask more concrete questions, set more detailed goals for the follow up workshop.

Vera, Portia, Laurent and I will improve the Business Value Game with the feedback from the participants. Next games: Mini XP Day Benelux (in English) XP Days France (in French).

This week, Portia and I hosted two runs in London of the “Business Value Game” that Vera and I developed. As usual, we had a lot of fun hosting the session and got good feedback from the participants.

Brain Train

Portia started the Brain Train sessions as a way for friends and colleagues to get together to experiment with new sessions and games. Earlier this year, we presented the “Real Options Space Game” at a Brain Train session in the Royal Festival Hall.

Last Monday we were back in the friendly lobby of Royal Festival Hall. As players started trickling in we grabbed a few tables and chairs to set up the game. Portia and I each coached one team through the six iterations of the game.

Each team used different strategies. For example, one team lost an unhappy customer because they concentrated on the other more lucrative customers, while the other team ensured that each customer stayed happy. In the end, Portia’s team won, even though they lost a customer.

After the game, we held a retrospective to see the good, the bad and the puzzling. The participants learned (or confirmed) some lessons about customer interaction, iteration planning, release planning, communication and teamwork. We’ll publish the results of the retrospective.

Thank you Eamon, Roshni, Jenni, Mark, Ioana, Al, Mohan, Daniel, Dot, Tamas, Eben, Ashutosh, Archie and Maria for playing and giving feedback.

Agile Business Conference day 1

The next day, I attended the first day of the Agile Business Conference. The highlight of the program was a funny and energetic keynote talk by Rob Thomsett on Agile Project Management.

One of his learnings is that when we borrowed engineering and construction project management models we also inherited their prevailing culture. The relationship between “IT experts” and “Users” (a denigrating term) has always been adversarial.

Agile Project Management is about true collaboration and is based on a set of values:

• Open: full participation and ownership by stakeholders.
• Trust: team members and stakeholders are professionals who can be trusted to be committed to the project and the organisation.
• Honesty: all people impacted or involved have a right to be told the truth; asking for help is a sign of strength.
• Courage: Undertaking projects requires courage in many areas like telling the truth and asking for help.
• Money: projects consume money. This requires a fiscal and ethical responsibility to be shared by all team members and stakeholders.

Rob concluded with some of concerns (silver bullet syndrome, lack of whole-of-life view, focus only on technical issues, lack of cultural awareness) and drivers (faster delivery, change friendly, more enjoyable, real teams, great values) of further Agile distribution.

In between sessions I talked to some acquaintances and met some new people. Together with Exoftware (thanks Andy!), we invited people to come to the next day’s Business Value Game. By then, we had already updated the game with the feedback from the Brain Train tryout.

Agile Business Conference day 2

After the opening keynote we played another Business Value Game with 13 participants. This time my team won! Again, the players had fun and learned lessons about planning, teamwork and prioritisation. It’s interesting to see how players react to the time pressure of the game:

• one of the teams used some extra time to come up with elaborate strategies and tried to make decisions before they had all the information.
• one team discarded information because they felt they didn’t have enough time to examine the information.

All teams could have done better and worked faster if they had shared more information in the team and if they had only taken decisions when they needed to. But that’s the subject of another game, the “Real Options Space Game“.

Agile Business Conference – closing

One of the highlights was seeing Ole and Jenni from GoAgile in Denmark again. Thank you for the gift and the great conversations about sessions, presentation techniques and Agile project management. We still owe you an explanation of Real Options. Most of all, thank you for your enthusiasm.

The conference closed with a presentation on the “Responsibility Model” by Christopher Avery. Chris explained the difference between being given accountability and taking responsibility. His model explains how we typically react in the face of problems. Portia has a good writeup of the material. On the way back Portia and I had a lot of fun going through each of the steps in the model in an exaggerated way, because one of the “Keys to Responsibility” is Awareness of how we (re)act.

Come and play!

We got good feedback on the game. Portia, Vera and I are busy working on v2.0 of the Business Value Game.

If you want to play our games, come and see us at the following fine events:

29/10/2008 – Scandinavian Agile Conference – Helsinki – The Business Value Game

20-21/11/2008 – XP Days Benelux – Eindhoven – The Business Value Game and Mirror, Mirror on the Wall

11-12/12/2008 – XP Days London – London – The Real Options Space Game and a new game by Vera. Exciting!

Or you can download our games and play them at home.

Watch this space for the release announcement or come and play with us at one of the upcoming conferences and seminars.

]]> http://blog.nayima.be/2008/09/27/show-me-the-money/feed/ 1 http://blog.nayima.be/2008/08/15/the-business-value-game-v10-released/ http://blog.nayima.be/2008/08/15/the-business-value-game-v10-released/#comments Fri, 15 Aug 2008 16:49:11 +0000 Pascal http://blog.nayima.be/?p=544 How do you prioritize your backlog?

If you want to create a good iteration and release plan, you should make sure that you work on the high value stories. But how do you know which stories have high value? It’s simple: your Onsite Customer will tell you. You do have an Onsite Customer, don’t you?

But how does the Onsite Customer decide? How does your company prioritize stories, epics and projects?

Playing with Business Value

In the XP Game you get story cards with the Business Value number already filled in. That makes it easy to prioritize: just look at Business Value/Cost.

The Business Value Game looks at the problem from the Onsite Customer’s point of view. Vera and I developed this game as a complement to the XP Game, to explain the difficulties facing the Onsite Customer.

We simulate a situation where a group of salespeople sell projects to customers (like Jonathan on the right) and need to decide what the development team will implement. The goal of the game is to make money by releasing features and by keeping customers happy (by releasing features).

Over 6 iterations, we introduce Customer Requests like the one below. Each request generates some income for the company when all the stories in the request have been implemented and released. Delivering a release makes the Customer happy. The players need to define the Business Value of each Request taking into account many factors: potential income, potential customer happiness, constraints, deadlines… Using the estimated Business Value and the estimated Cost (already on the Story cards), the team must decide which stories go into each iteration. Of course, the developers can implement no more than their velocity.

We introduce more and more difficulties and parameters in each iteration: developer output fluctuates, there are dependencies between projects, some Requests are inconsistent, you can invest in process improvement and many more that we can’t reveal now.

Tried out

Tryouts are an essential part of game development. I hosted a tryout at Agile 2008. Last Wednesday Vera and I hosted a tryout at the Belgian XP Users/Agile Belgium group meeting in the offices of Cap Gemini. We received a lot of feedback from the participants at both tryouts. Thank you.

We have so many tips and ideas that we’re thinking of creating two versions of the game: a basic version with 6 iterations in 90 minutes and an extended version with 9 iterations in 120 minutes. As we add more difficulties in each iteration, the 9 iteration game might become very challenging!

Try this at home!

The Business Value Game is licensed as Creative Commons and available online like the XP Game, the Bottleneck Game, the Real Options Space Game and Mirror Mirror on the Wall.

DOWNLOAD IT!

The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.