Interview with me at STOOS stampede

Rini van Solingen did a interview with me on the Stoos stampede on large scale Scrum.

It was fun 🙂

You can see the video at YouTube.

ScrumPloP 2012

Lachlan Heasman made this funny video of the ScrumPloP 2012.

Check it out 

ScrumPloP 2012

The next ScrumPloP is in the Netherlands. See ScrumTulipPloP for attendee list and registration details.

There is also time for drinks 🙂

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.

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.

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.

Scrum & Complexity

Complex system theory and especially social complex systems are getting a lot of attention the last few years in the Agile community.
Complexity remains a ‘complex’ topic as there are so many views and perspectives from e.g. neurobiology, anthropology, social sciences, mathematics, molecular biology, philosphy, economic studies and computing science just to name a few 🙂

Scrum is build around empirical process theory, but also around complexity theory in general and Complex Adaptive Systems (CAS) in particular. See Jeff Sutherland on this.
In a CAS something spectacular can happen! Without any centralized control and with very simple rules the most amazing results can be obtained. Termites for example make these great hills full of chambers and complex tunnels and groups of people are able so solve problems they do not know upfront how to solve. Individuals self organize, the right results emerge and the CAS adapts to a changing environment to stay successful. Wow… this is to good to be true!

See Beats 2006, Complexity, learning and organizations for details.

Interesting to notice is that a CAS naturally moves towards operating in a region called the edge of chaos. This is interesting because research shows that groups of people operating in the edge of chaos are maximal creative and productive.

Put more formally “there is maximum capacity for information computation”
– R. Lewin 1999. Complexity: Life at the Edge of Chaos.

Hmmm so what? why should I care?

Most of the time when you are developing software you are cracking a problem which you do not know how to solve upfront. Usually there is a lot of uncertainty on what to build exactly and on exactly how to build it.
A situation like this can be handled by moving your team towards the edge of chaos! The exciting part is that Scrum helps you set up the conditions for doing so and also providing all the inspection and adaptation points necessary not to fall over into chaos.

Just in Time details – A refresher

A backlog can contain user stories. And these user stories are just the three C’s as Ron Jeffries stated.

• Customer
• Collaboration
• Confirmation

It is written by the Customer and it is so little text that you are forced to Collaborate with the customer because otherwise you do not know what to develop.
The Confirmation enables a team to make a reasonable estimate of the user stories and so we come up with a estimated backlog.

A good thing is that the user stories naturally encourage us from adding requirement details at an early stage. Once the PO selects user stories for the next sprint the necessary details can be added Just In Time, like UI, data specifications, business rules, business process flows etc. People need time to add these details, not because the actual writing or describing takes time, but because people need to think about what they want. It is partly a creative process, partly a discovery process and this takes time!
Not all requirements should be written down in full detail, but just enough to have a good start the next sprint! Next to adding details to the scheduled user stories the backlog should also be improved by for example adding new stories, splitting stories from existing epics and estimating any new stories.
So people of the team need to start thinking about some details and adding the details to the selected user stories for next sprint during the current sprint. This of-course interferes with their activities in the current sprint, but the benefits of preparing are often higher then the losses due to e.g. task switching.

In order to start the information transfer to the team members early on, half way the sprint a requirement workshop can be organized to share and learn about the user stories scheduled for next sprint. The result of this workshop is a better mutual understanding within the whole team about what to build and what can be improved prior to the sprint planning meeting. Such a workshop should also result in a set of acceptance examples of how the PO wants to verify that a user story is build in the right way.
An important benefit is that the end result of the user story details are better because the knowledge of the whole team is used. A great side effect is that because the team is involved and contributes to the requirements and therefore the direction of the product to be developed, their responsibility and motivation is increased.

So now the sprint planning will go smoother, concurrent development during the sprint is much easier to do and WIP is under control.
In Scrum btw we expect a team to spent around 10% of a sprint grooming the backlog and preparing for the next sprint.

But isn’t this mini waterfall? No! In waterfall all requirements are detailed before development starts. But even if it was waterfall, so what! Is the goal to not do waterfall?

Retrospective results Bathtub II and peek at Bathtub III

We, Carlo Bechi, Oana Juncu, Pascal Dufour and Cesario Ramos had a retrospective on the 2nd Bathtub and come up with the following improvements for the 3rd Bathtub

1. Introduce 3 – 5 min breaks between the talks, so people have time for a break and some discussion using IRC, Twitter and so on.
2. We are going to search for a new tool that support multiple organizers
3. We will keep the IRC channel for collaboration
4. We will go back to 5 talks of 12 min + 3 min questions each.
5. We will be asking the country of participants to get a overview of the participants locations.
6. Plan retrospective with speakers and attendees upfront before the conference.
7. Survey after the conference.

Potential speakers for the 3rd Conference that wil be organized in october 2011.
– @vhazrati
– @cesarioramos
– @olavmaassen
– @jbrains
– Elisabeth Hendrikson
– @filippodesantis (shorter version of http://www.slideshare.net/p16/xkanban-xp-kanban-e-timeboxing)

The Bathtub initiative is for the ALE community and organized by the ALE community. So if you want to contribute in the organization or as a speaker please contact me.