Games for Product Management

I followed a Innovation Games© class by Luke Hohmann. I read the book some time ago and did not think much of it. I thought they where just more agile games, how wrong I was.

In the Agile games the focus is more on learning about agile practices, understanding it’s principles and just having fun. The Penny Game e.g. illustrates effects of batches on cycle time and ballpoint game makes you feel what it is like to work in a Scrum team.

The Innovation Games© are more about collaboration and together learning about things you don’t know that you don’t know. It is about as the name suggests innovation.

At the training we played numerous games like Give Them a Hot Tub. Below an action photo of the Give Them a Hot Tub game being played.

Team 1 is presenting to team 2 all the crazy ideas they came up with for a airline. A onboard hot tub, on board comedian and in flight dating are just some ideas. The best idea was to have beds in the plane so people could sleep during flights.

Another game I really liked was SpeedBoat. It is kind of a ‘bitching’ game but potentially give great insights because of the way the game is setup.

In the training I learned some valuable lessons in the way you can help people playing the Product Owner role with roadmapping, prioritization and discovering what customers actually value.
What I learned is that there is an interesting difference between the games we play in consulting and training aka Agile games and the Innovation Games©.

Supported Change

Below a pattern I am working on. Feedback on how to improve it is more then welcome.

NAME
Supported Change

CONTEXT
You are helping an matrix organization transition to agile. You are working with different teams coaching them on using agile practices in their organization.

PROBLEM
You want agile practices that are introduced in the organization to persist. How can you help the organization to adopt agile practices in such a way that they persist over time?

FORCES

• Illusion of control: People that define how to do agile practices in their specific organization themselves tend to support them better.
• Anchor change: Telling people how to do agile does not work as the people doing the work know their organization best. Therefore you want to facilitate learning and let the people discover themselves how to do agile within their specific organization.
• Create knowledge: Every time you provide a specific solution to a team you loose an opportunity for self organization. You want the team to be able to fail and learn but also to protect the team from not having a major accident.

SOLUTION
Create optimization teams for particular areas such as Agile Product Management, Scrum Masters, Agile Testing and Agile Development. People acting in different projects across the organization get together regularly in an optimization team to share their project experiences and discuss challenges they face and how to tackle them. The optimization team facilitates experiments in projects to create knowledge about how agile works in the organization. The optimization team makes the created knowledge explicit and available in the form of Standards for Improvement.

CONSEQUENCES
Benefits

• People are encouraged to experiment and question the way things are currently done. People from different projects across the organization learn from each other and spread the knowledge across the organization. A supported standard is established that forms the basis for improvement.
• People are committed, feel accountable and fully support the change because their opinions have been taken into consideration and they feel the changes are made by themselves.

Liabilities

• The Optimization team meet-ups can result in endless discussions with no real results.

ScrumTulipPloP venue is known

We have decided to organize the ScrumTulipPloP at the Kasteel de Hooge Vuursche. The ScrumPloP.org website is also updated with the latest information about writing and submitting a paper for shepherding.

See ScrumTulipPloP for details and the call for papers.

Professional Scrum Master training in Utrecht on 4 & 5 juni

I’ll be giving the Scrum.org certified Professional Scrum Master training in Utrecht on June 4 and 5. The training will be in Dutch.

You can register at here at Scrum.org

Check AgiliX for more information.

ScrumTulipPloP

On october 29,30 and 31 there will be the first ScrumPloP conference in the Netherlands. I am organizing this conference together with pattern experts Neil Harrison and James Coplien. The ScrumPloP is supported by the Hillside pattern community

If you don’t know what a PloP is I recommend to read What is a PloP?

At the ScrumTulipPlop you have the opportunity to

• Learn from peers & industry experts about Agile & Scrum
• Share your knowledge in the form of patterns to contribute to the Agile & Scrum community.
• Improve your pattern writing skills at the various writers workshops during the conference.

We will be announcing the venue and more details in the coming weeks.

Agile estimation is not waste per se

So you are not going to do estimations as they are a waste?

Great! How are you going to create a common understanding of what you need to deliver as a team?

You’ll probably pick a feature and discuss it in your team right? Discover what it is that needs to be build, discuss development approach, tasks and so on. The time it takes to do this depends on the story a hand. After you have had this planning discussion you’ll have a common understanding. Then you’ll discuss the next feature and so on. After your team has build up a common understanding of a feature and a plan for delivering it they also have a good idea of how much work it will be. So the team is able to give a estimation pretty fast (within 1 minute) as all the work needed for estimation is already done. Even if the estimate is completely wrong the so-called waste is almost zero!

Ok, what if you have a big list of features? then estimation of the whole list upfront is a waste? what if I have a list of work that is more or less equally sized?
Ok… but how did you get such a list? Don’t tell me you had to break it down into equally sized parts!

Lets take a look at waste.

• Type I muda is necessary waste, it is something that does not add value for the customer. The way of working of the business needs to change in order to eliminate this type of waste.
• Type 2 muda is unnecessary waste. Non value added tasks that can eliminated directly without any change.

Ok. So who is the customer in Lean?

Maybe the most important part of lean is called Respect for People.
The end customer is the most important customer but not the only one. Everybody that receives work in a value stream is a customer to the ones who deliver. Respect for people in this context also means that you offer your work in such a way that the receiver can handle it in the best way.
So e.g. Product owners, shareholders, management and so on are all customers in the lean context. The product owner is offered easy and clear indicators of progress and estimated work remaining; operations is offered a clean and high quality product; management is offered clear and honest information on costs, opportunities and risks.

So the question becomes: Does estimation not add value for any customer?

Example: You have projects in your portfolio and you have to choose which one to do? How are you going to choose?
You could take into account things like estimated added value, estimated risk, estimated duration, estimated costs etc.

Should we estimate a whole big release backlog? of-course you should as long as there is someone who needs a number to make valuable decisions. Just make sure it does not take you to long! Give input to make the budgeting decisions and then concentrate on improving your estimates and plans as you make real progress.

So if estimation adds value to workplace customers is it still a waste?
Only if you change the business in such a way that it does not need estimations anymore then estimation becomes a waste!

So in summary

• Estimation is a waste only in certain contexts.
• If you work as a team and plan your iterations you probably already did al the work needed to give an estimate anyway.

Déjà vu – What is a good sprint plan?

I observed a Sprint Planning meeting the other day where people wanted to reuse the task stickies from other sprints as they claimed to be more or less the same in every sprint. It actually was a Déjà vu moment. While having lunch with a old friend he said the same issues came up in his team.
So I decided to write this little post although I feel a little ashamed to write it.

The Scrum guide states in Sprint Planning part two ‘Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.’

The Scrum guide also states that ‘By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.’

Ok, so how do I achieve that? How do you know you have a good plan? What does a good plan look like?

A bad sprint plan describes what work needs to be done. Remember that the what question is the goal of Sprint Planning part one. The result of Sprint Planning part two should be a sprint plan that describes how the works needs to be done!

Lets look at an bad sprint plan example.
For a user story you’ll probably need to do some coding, testing and other things as described in your Definition of Done. If a team plans what it needs to do then the tasks could be e.g.
Task 1: Code UI
Task 2: Code Server side
Task 3: Write test cases
Task 4: Execute test cases
etc.

Obviously having such a task list does not make any sense unless your team members have a bad memory and forget what they are supposed to do. A team that comes up with a plan like the one above could easily reuse the plan for every sprint.

The whole purpose of the Sprint Planning meeting is to create a detailed and shared understanding of how the sprint is going to be delivered. At least for a good part of the Sprint. The tasks are just a possible side effect but not the purpose of the Sprint Planning meeting!
The team needs to understand what they need to modify, extend and create in order to achieve the necessary results. The team builds on the work they did in Sprint Planning part one where they e.g. walked through the UI prototype or modeled the UI using screen sketches, wrote acceptance criteria, draw flow charts or whatever other Agile modeling techniques they used.

A good sprint plan could have the following tasks
Task 0: Extend page flow A->B->C with …
Task 1: Extend Service X to cope with new ….
Task 2: Sit with Domain Expert to come up with …
Task 3: Update Repository XY with …
Task 4: Create new table A, B, C …
Task 5: Pair test/develop initial FitNesse tests for …
Task 6: Create new component Z for …
etc

So if you can reuse your stickies across sprints there probably is something very wrong with your sprint plan.

Agile teams value assumptions over forecasts

This post is inspired by my favorite systems thinker prof Russel Ackoff.

In development we have lots of uncertainties. Uncertainties in technology, scope, costs and schedule just to name a few. We face the challenge of staying in control in a uncertain environment. We face the challenge of dealing with the uncertain future.
There are two things you can do to deal with the future. You can use assumptions and you can use forecasts. Forecasts are about probabilities of events happening and assumptions are about possibilities of events happening!

A thermostat controls the temparature of a room by frequent measuring temperatures and adjusting the heating-cooling system. The thermostat does not need to predict or forecast the future ‘weather’ in the room in order to control it. The thermostat does not need probabilities. It only needs assumptions! The thermostat assumes that the temperature will change in the room and therefore it is made in such a way that it can respond rapidly and effectively to whatever the temperature turns out to be.

There are two nonexclusive ways of dealing with possibilities; contingency planning and developing responsiveness.

Russel Ackoff

We do contingency planning for the cases we see as an exceptional risk. You identify the small set of possibilities and come up with a plan or measure to tackle each possibility. I carry a Jerrycan in my car not because I forecast that I will run out of fuel in the middle of nowhere but because I assume it is possible that I do. When the set of possibilities is to large and therefore to complex to handle we develop responsiveness.

In agile teams there is a lot of attention for developing responsiveness. We have short iterations and increments, various quick feedback loops, work in order of value and keep quality high so we are ready to change direction every iteration. There is also a lot of attention on forecasts. We have release burndowns, avg cycle times, work in progress, defects trends and so on. There is nothing wrong with forecasts about the future except for the unpleasant fact that they are usually wrong.

In Scrum we used to say that a team committed to a sprint goal. The use of the word commit made lots of people think that a team should be able to predict the future after it was sprinting for a while. Nowadays in Scrum, in order to make things clearer, the Development Team is said to give a forecast of what it thinks it can do within a sprint. So a Development Team actually makes a statement about how probable it is that they can accomplish the selected product backlog. It’s a forecast based on the Yesterdays Weather XP rule.

In agile teams there is little attention for contingency planning. Agile Risk management just does not seem to be interesting enough and set based development seems to be regarded as to expensive by most teams! So lots of agile team focus on their forecasts although the best way to handle the future is not by trying to predict it but by the possibilities we have of adapting to it! An Agile team should therefore assume certain possibilities will materialize and have options ready so they can adapt quickly to what the future might bring. An agile team should therefore value assumptions over forecasts.

Professional Scrum Master training on 19 & 20 march in Utrecht

I’ll be giving the Scrum.org Professional Scrum Master training in Utrecht on March 19 and 20. The training will be in Dutch.

 

You can register at here at Scrum.org

Check AgiliX for more information.

Integration Scrum

This pattern is about an approach I used quite a couple of times to deal with inter team dependencies.
In cooperation with Kate Terlecka for review and feedback.

NAME
Integration Scrum.

CONTEXT
A project consisting of multiple Scrum teams must produce a potentially shippable increment every sprint. Each Scrum team develops features independently. All Scrum teams together develop multiple integrated features at the system level.

Example:
Scrum team 1 develops a feature for ordering a new product through a web shop. A second Scrum team 2 develops a feature for billing and administrating the new product in the financial systems. The overall feature value is in the two features working together correctly.

PROBLEM
Projects consisting of multiple Scrum teams must provide a mechanism for organizing the development and execution of system level tests in each sprint. Many of the technical problems in the development life cycle are addressed by continuous integration practices. The remaining problem is organizing who is developing and executing the system level tests and how to deal with defects.

FORCES
• Postponing system level testing increases risk about project progress and feature correctness. If a separate team is responsible for system level testing unnecessary hand-offs, delay and upfront planning is needed.
• Developing and executing system level tests requires effort from the Scrum teams involved. The Scrum teams should therefore be able to plan for system level test activities in their sprint-planning meetings.
• No explicit Scrum team is in charge for developing and executing the system level tests and as a result ownership and commitment may suffer. The Scrum teams involved should therefore explicitly commit for delivering it.
• The Scrum teams needed to provide features at the system level can differ from sprint to sprint. For example, feature 1 & 2 needs Scrum team 1 & 2 while feature 2 & 3 needs Scrum team 2 & 3. It should be possible therefore for Integration Scrum composition to change each sprint.

SOLUTION
Introduce an Integration Scrum event where Scrum teams representatives collaborate on getting the tasks done and create a shared plan for system level testing activities for the involved Scrum Teams.

In detail:
Introduce an Integration Scrum event where representatives of the Scrum teams collaborate as frequently as needed for getting the tasks done related to system level testing. The Integration Scrum is responsible for defining system level test tasks and making them transparent to their Scrum Teams on their Scrum boards. The people who are actually working on a Scrum Integration task take place in the Integration Scrum events.
Identify system level testing Scrum Team dependencies during Sprint Planning I. The Scrum Teams choose which features to implement and therefore also know with which Scrum teams they need to work together the coming sprint. In Sprint Planning II the Scrum Teams together plan the work needed to develop and perform system level testing and commit to it. A result could be a shared task list for system level testing activities.

RESULTING CONTEXT
This pattern enables Scrum teams to extend their Definition Of Done more easily with integration and system testing.
The intent of the Integration Scrum is similar to the Scrum of Scrums. The Integration Scrum specializes the Scrum of Scrums, which is a generic form of synchronizing multiple Scrum teams. If the Integration Scrum hampers lateral communication use Scrum of Scrums and Daily Scrum to find a solution.