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.

Professional Scrum Product Owner training op 16 en 17 january 2012

On 16 and 17 Januari 2012 I’ll be giving the Professional Scrum Product Owner training of Scrum.org. The training will be in Utrecht and will be in Dutch.

You can register and find more information here.

Rotation across Europe for the ALE Bathtubs

Back in March 2011 I came up with the idea for a Bathtub conference in the ALE community. See original thread here on the ALE Linked In group. The ALE Bathub was the first successful project that came from the ALE community that was being put together at that point in time. See ALE Network for the Bathtub and other ALE projects.

People thought it to be a good idea and we got off with ALE Bathtub 1 that was organized on Mar 2nd , Bathtub II on June 30th and Bathtub III on October 20th 2011.

At the first ALE conference in Berlin we came together and discussed my idea to move the Bathtub conference organization around Europe. The first team including Oana, Pascal, Carlo, Guntram and Cesario did a fantastic job for the first 3 Bathtubs but now it is time to pass the bucket and foster fresh ideas from other ALE members across the world.

The idea is that every Bathtub will be organized by different ALE people so that it becomes a real ALE event by the ALE people and for the ALE people.

For Bathtub IV we passed the bucket to Catia Oliveira and Michael Leber. They will be working on the organization and probably invite other to help out and make Bathtub IV even better the the first three.

ALE Bathtub III last slot by Ester Derby

Bathtub III is on October 20th from 21:00 until 22:40 CEST.

Final agenda

21:00 – 21:15 CEST | Esther Derby – Re-thinking Management
21:20 – 21:35 CEST | Scott Barber – An overview of Performance Testing for Agile/Lean teams
21:40 – 21:55 CEST |Cesario Ramos – Lean Agile Sandwich
22:00 – 22:15 CEST | Olav Maassen – ‘Surprise surprise’
22:20 – 22:35 CEST | Filippo De Santis – Xkanban

Goto Bathtub III for more info and registration.

Professional Scrum Master training 12 and 13 december Utrecht

I’ll be giving the Scrum.org Professional Scrum Master training in Utrecht on december 11 and 12.

 

Check AgiliX for more information.

ALE Bathtub III open for registration

The next bathtub is scheduled for october 20th from 2100 until 2300 CEST.
Make a note of it in your agenda.

At this moment we have the following confirmed speakers
1. Olav Maassen
2. Scott Barber (An overview of Performance Testing for Agile/Lean teams)
3. Filippo De Santis (Xkanban)
4. Cesario Ramos (Lean Agile Sandwich)
5. to be announced soon.

You can register at https://www3.gotomeeting.com/register/575550998

Speak on ALE Bathtub III on Oct 20?

ALE Bathtub III will be on Oct 20. The Bathtub will start at 2100 CEST and end at 2300 CEST.

There are still some slots open for a lightning talk of 12 min. Let me know if you are interested in giving a talk at Bathtub III by email or comment. See http://www.bathtubconferences.org/bathtub/ for more details.

 

Professional Scrum Foundations Training in Groningen op 21 & 22 November

I will be giving the Professional Scrum Foundations Training in Groningen on 21 & 22 November in The Netherlands.

Below a description in Dutch.

Om Scrum Teams succesvol te laten zijn is deze 2 daagse training een must. De training legt een grondige basis en bereidt hiermee de studenten voor om gelijk Scrum effectief te kunnen inzetten in het dagelijks werk. Het Scrum raamwerk, de Scrum rollen en Scrum activiteiten worden behandeld met de nadruk op toepassing in de praktijk.

Klik hier voor meer informatie en registratie mogelijkheden.

Deze training legt de basis voor de vervolg trainingen zoals Professional Product Owner en Professional Scrum Master.

Retrospect to FAIL fast and OFTEN

Some teams steadily come to a state in which their retrospectives result in less and less improvements. They have been continuously improving in small steps and improved quite a bit since their start, but eventually they stopped learning.

The thing is that you can learn from things you do right but you can also learn a lot from doing things wrong. When for example you try something that you expect to work and it actually works you confirm your current assumptions and values.
When on the other hand you do something you think will not work and it does work, you just learned that one of your assumptions, values or thinking patterns are incorrect.

The issue is that in general we prefer to learn from doing something that works and try to avoid doing things that we expect not to work.

For example, in retrospectives we look back to see how we can improve. We analyze what the root cause of a problem could be and then come up with a hypotheses and accompanying sprint backlog actions to try out and see if our hypotheses holds in the next iteration. The hypothesis we make is based on our current assumptions and values and this is good, but only goes so far.

The issue with learning from doing things that work is that we limit our learning. We narrow the set of possible outcomes because we in general define our actions based on our current assumptions and thinking models. We do not challenge our assumptions and values this way.
Chris Argyris discribes his double-loop learning as a model for challenging your assumptions and values to foster deep learning.

Therefore I propose that we should challenge our assumptions and values by setting up experiments that we think will fail. We should consider having retrospective actions that we expect to fail, we should retrospect to FAIL fast and fail OFTEN.

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?