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)

[Mark] Continuous Delivery

Good article about continuous delivery.

Original article

As the IBM Maximo team builds on Agile best practices to faster and higher quality development, we are looking forward to implementing many improvements around Continuous Delivery (CD).  In it’s most extreme, CD is a fully automated code delivery and test pipeline that will take a code change, through all the build, test, and promotion steps and make the change available without any manual intervention, and with full visibility to the team.  If there is a problem with the change, the line is stopped and the defect routed automatically so it can be quickly repaired and complete delivery.  Continuous deployment is similar to continuous delivery, but also includes automation to deploy the fix directly into production.


Continuous Delivery allows Maximo to further improve on common objectives around speed and quality.  Maximo’s implementation of CD will focus on fully automated development and test pipelines for day-to-day delivery of code, and minimize or eliminate post sprint testing.

In the past, delivering significant new function, required a lot of test time and effort before delivery.  To maximize the benefit of those large test efforts, we tended towards larger, longer projects.  We had a lot of feedback from customers wanting needed function sooner, quality concerns over the amount of change, and the expense of adopting so much change at once.   Adopting Agile best practices allowed us to start reducing waterfall delays, shifting development and test left in the process, and increasing quality while delivering a lot of great product improvements.

Going forward into CD, we are dramatically improving our automation (Unit Test, Build, Provisioning, System Test …) while introducing new pipeline automation using Urban Code, Chef, Jenkins, and other tools.  The pipeline automation allows us to connect all the steps along the dev-test process together, provides visibility to the team, and eliminates several manual work flows.


So that’s a lot of nice technology, and efficiency, but what does that mean for impact?

For projects, it means:
– Reduce simple change delivery effort (the amount of effort to deliver a small, 1 line change) from a week or more to a day or less,
– A massive, 3x increase in automation, to increase quality, and reduce time
– Reduce post development testing from several person-years (PY’s) of effort, to a couple person-months (PM’s) of effort.

For customers, it means:
– Faster delivery of important requirements
– More product improvements from more efficient projects
– Smaller, more consumable deliveries
– higher quality from better development processes, and much more testing

Overall, we’ll be shifting from very large projects, like Maximo 7.6, that took years to deliver, with a mountain of content, to faster releases that take a few months to deliver, with less content, and keeping a high level of testing, and quality assurance.  Customers can still take content on a schedule that fit’s their business, and will have much more visibility of incremental changes as they come out, as well as the benefit of field feedback as deliveries come out.

Please watch for more information as we adopt Continuous Delivery.  If you have questions, please contact Bjorn Kutz (, Fernando Giglio ( or Jenny Wang (

About the Author.  Bjorn Kutz is the IBM Internet of Things (IoT) QA Program Director for Maximo.  He works with a fantastic Continuous Delivery team including Fernando Giglio – Development and CD Manager, Jenny Wang – Technical and CD Lead, and many other CD enthusiasts across the Maximo Team.  Bjorn is also a regular contributor on the Maximo Quality and Test Community.

My reflection on Lego Serious Play

“You can learn more about a person in an hour of play than you can from a lifetime of conversation” – Plato 

Why are the little bricks so powerful for innovation and business performance? I couldn’t figure out the power until I participated the Lego serious play meetup given by Michael Tarnowski


I would like to take my experience as a case study to share my shallow understanding of the power.

Most time when I share an idea to a group, I feel uncertain or unsure whether I have explained myself clear, always wondering how much the others understand me. The language seems so weak at that moment. It would be even worse if speaking a non-mother language. In such a situation, the little bricks help me to transfer my virtual thought into something real which can be seen. I guess brain processes faster with both hearing and seeing.

Additionally when I am constructing my thoughts into bricks, I am thinking carefully about some metaphors to explain the thoughts. As we know, good teachers when they explain a complex concept, they will always begin with some simple metaphors which are easy to understand and then they will extend them as to finally make clear of this concept. I think it’s the same principle.

The most amazing thing is that by now it has been 40 hours since I finished the play, I still remember clearly every team member’s thoughts about team values they expected, by recalling the bricks they built. For example, different shape bricks represent Diversity; small window brick means Open-mind; fences brick implies Boundary and Privacy etc. It is to a large degree making the work of memory easier.  


I believe there are a lot more scientific studies to prove why LSP works so well. If you are interested in it, you can read more from the official LSP website or a good blog I found out for using LSP in Agile.

Have fun!

Why retrospective?

Looking back often, then you look further.
The postpone of review meeting endangered the retrospective again which made me very nervous.
However no matter what happens, I insist on having retrospective. Maybe for the team it’s just a meeting, but as for Agile process, it’s one of the most important check points.
Let’s first have a bit view on what we do in retro. The common retrospective meeting agenda is as following:
  1. review the result of the action point which was taken out from last iteration. Asking questions: how does it work? if the answer is positive, then we will continue; if not, then we will stop it;
  2. find out what’s next urgent point needed to be improved. There are many Agile retro games to facilitate this step. I only suggest using vote to decide the “to be improved candidate”.
  3. divide team into different groups to brainstorm feasible ideas and actions to the “to be improved” point. One remark is that the action must be concrete and detailed enough so it can be done immediately after the meeting. From my personal experience, filling the action into 4W1H(What? How? When? Where? Who?) question format will make it better to executed. For example,
    • What? to add test cases example to one user story and then show to the team
    • How? use TFS “test cases” functional to add test cases and link them the user story…
    • When? Friday
    • Where? at Li’s place
    • Who? Li and Joey
After retro has finished, the ScM should make sure the action is well followed up and ask for feedback from team on this action in the next coming retrospective.
In the daily work or life, we need some changes to improve ourselves, then we work out some actions. But how do we guarantee the improvement will be finally achieved or not? Retrospective is such a ritual to keep you reviewing on those actions regularly, on one hand to pick out the meaningful-less changes, on the other hand to solid the positive changes we’ve made and then move on.
Why retro

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 Vs. Agile What is the difference?

There is no winner or loser. Agile or Lean, take the best of them!

Li Fang's Blog

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…

View original post 100 more words