Global SCRUM GATHERING Munich 2016

3 days conference is exhausting. But it did worth it!
I like the most of the conference is the Open Space.
It’s just amazing! I couldn’t imagine how three hundreds people can be self-organized to work out a day agenda in half a hour. But the result was so surprising. There were three scenes I just couldn’t believe.
  1. the topic volunteer session had been closed in 30 mins and more than 30 topics were proposed
  2. at the end everybody liked at least one session they participated
  3. the voice of machine ending was so fantastic! (i hope i can find the video)
 I can’t tell the magic of self-organization. But it’s really powerful!
Here is a list of all topics I liked.
Day 1
  • The systemic Scrum Master – Marc Loeffler
Take away: PASSION model(Passion, Adaptable, Strong vision, Strength oriented, Independent, Oneness, Nimble)
Day 2 Open space
  • Role Play: Coach uncoachable coachee – Sebastian Keller
Take away: show empathy to uncoachable coachees
  • Agile games – Christo
Take away: Name for multitasking; Non-music chair for new group; Airplane factory for scrum team work
  • Presentation Karaoke
Take away: build up presentation skill and have fun
Day 3
  • Doing half the work in twice the time – Wolfgang Richter
Take away: being lazy might be productive, efficient and effective; sleep urgency for two days
  • Selling the “Fluffy” Side of Scrum – Paul Goddard and Geoff Watts
Take away:
Being emphatic and neutral
Having hope of all challenges
Visualize the hope
  • Experimenting and learning with Origami – Tom Mellor
Take away: how to deal with “bad” product owner



(with Tom Mellor, ex-chairman of Scrum Alliance, a funny guy:)
Closing keynote
  • Dealing with Uncertainty – Nigel Baker, a brillant guy
Take away: passion + Zen
The last but not the least, new friends brought much more fun!
(From left to right: Dymitri, Anna, Donna, Tom and me)

Continuous improvement board

One of my colleague has designed this continuous improvement board. I like it very much and want to share it.

As the design shows, doing improvement continuously is like doing sports. We need to take the improvement exercises regularly in order to build up the “muscle”. Though we will not feel too much difference at the beginning, but if we persist in doing it, I am sure we will see the success one day.

We need only a little patience, passion and perseverance!

CI whiteboard.png

Lean thinking – Retrospective on myself

In the transit period from Scrum Master to Agile coach, I feel I am lost. Frankly speaking, I don’t know how to coach people. It’s really different than I thought it would be.

Suddenly, I feel so blur about my role and responsibilities in the organization.

A friend who is expert at project management suggests me to read “Lean thinking” which might be helpful.

What’s more, I shouldn’t have interfered too much into people management which is not my responsibility scope. When I am pushing the process, I should speak as the representative from the voice of business, voice of customers, voice of management.

The last but not the least, number and data are more than powerful to show the effect of the changes.

All in all, the right thing for me is to think about the voices and numbers.

Lean thinking


“Agile” VS “Agile process”

What is Agile?

Agile is not a process, it is a philosophy.  It’s a philosophy that describes a comparative value system and a set of 12 principles designed to discover better ways of developing products. See “Manifesto for Agile Software Development“.

What is Agile process?

There are many agile embracing processes or process frameworks, e.g. the popular ones are XP, Scrum, Kanban etc.

Henrik Kniberg did an analysis and compared some process tools on the prescriptive vs adaptive scale:

Prescriptiveness in Agile Processes

This chart provides a high-level view of Agile frameworks on a scale of prescriptiveness to adaptiveness. Henrik bases his measurement on the number of ‘rules’ stated in the process descriptions. For example:  RUP 120 rules; XP 13 rules; Scrum 9 rules; Kanban 3 rules. It means, the less rules the process depict, the more adaptive it is.

However as one moves to the right on this spectrum there is an increasing need for self-discipline. Just because you are at the right end, “Do Whatever” doesn’t mean your group has the ability to effectively achieve your goals. Perhaps, you can improve the effectiveness you desire by moving toward the left.

In my experience, it requires a very mature organization to move toward the right on this spectrum.  Moving toward the left creates a rigid structure and can have severe consequences on team dynamics and motivation.

Read more about from Henrik about these processes:


is pretty prescriptive – it has over 30 roles, over 20 activities, and over 70 artifacts. An overwhelming amount of stuff to learn. You aren’t really supposed to use all of that though, you are supposed to select a suitable subset for your project. Unfortunately this seems to be hard in practice. “Hmmmm… will we need Configuration audit findings artifacts? Will we need a Change control manager role? Not sure, so we better keep them just for in case.” This may be one of the reasons why RUP implementations often end up quite heavy-weight compared to Agile methods such as Scrum and XP.

XP (eXtreme programming)

is pretty prescriptive compared to Scrum. It includes most of Scrum + a bunch of fairly specific engineering practices such as test-driven development and pair programming.

XP practices


is less prescriptive than XP, since it doesn’t prescribe any specific engineering practices. Scrum is more prescriptive than Kanban though, since it prescribes things such as iterations and cross-functional teams. One of the main differences between Scrum and RUP is that in RUP you get too much, and you are supposed to remove the stuff you don’t need. In Scrum you get too little, and you are supposed to add the stuff that is missing.



leaves almost everything open. The only contraints are Visualize Your Workflow and Limit Your WIP. Just inches from Do Whatever, but still surprisingly powerful.



Recently people ask me a lot “what’s the difference between Lean, Agile and Scrum, XP…?”.

Yes, to the one who want to learn Agile, there are too many concepts. So I am trying to make these new things clearer.

  • First, let’s read something about the history of these methodologies to help us better differentiate them. From the article we know that Lean Methodology came out much earlier than Agile.


  • Second, let’s find the purpose of the methodologies:

In a nutshell, Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks and documentation. But it also means eliminating time spent building what “we know” we’ll need in the future (things are constantly changing so we often end up not needing them – or if we do, we have to rework them because conditions and our understanding has changed by then). It also means eliminating inefficient ways of working – like multitasking (!) – so we can deliver fast.

Agile refers to a set of values and principles put forth in the Agile Manifesto. The Manifesto was a reaction against heavyweight methodologies that were popular, yet crippling software projects from actually doing what they needed to do – create software that helped the customer! I believe Agile’s values & principles work because of the science behind Lean and so you’ll see a lot of similar themes repeated in agile.

Why should we eliminate unclear requirement?

The first question before the organization transformation is:

What problems does the organization have and what do they want to be?

The voice from product manager:

I can’t make an accurate product plan because the team can’t give an accurate estimation.

The voice from team:

The requirements are not clear which causes a lot of rework.

From my analysis, the reason behind is the same, which is mainly caused by unclear requirement.

Why requirement is important in the process

The chart shows how the unclear requirements lead to inaccurate estimation and lots of rework. For example, if the team has 5 people and the iteration duration is two weeks, then the total working day should be 5 * 10 = 50 Man day. However with the unclear requirement it will cause 60% rework, which means team have to spend another 30 days to finish the rework, if lucky, in the next iteration the requirement can be completely achieved, or else it will go into a vicious circle. The consequence is that team are seem like always busy, but busy with the last requirement, which undoubtedly leads to low productivity and poor efficiency.