DARE2013 conference, Day 2
For those who are looking for my presentation slides, you can find them at http://www.slideshare.net/samililja/dare-sliljaflow
Day 2 of DARE2013 kicked off with Dean Leffingwell‘s keynote Be Agile. Scale Up. Stay Lean & Stay Happy.
He started a longish history of SW development and what things looked like 20+ years ago. The point he made was: while technologies are advancing with huge speed, methods and practices are not keeping the same pace. Agile is a promise but for small teams, how to scale up?
Then Dean presented Scaled Agile Framework (SAFe) big picture. The slide looked noisy, tons of things packed on one page. I found the picture a little scary, but I know lot of managers who start drooling when they see a framework that they can deploy in organization.
Dean then presented Lean thinking. Goal is to sustainably create value with shortest lead time, best quality, most delight to customer and lowest cost. This is pretty OK, although to my opinion this inside out improvement: we organize ourselves according to these goals. There was very little about customer demand and nothing about organizing against different (varying) demand.
Dean made a good point about Lean: it is for building products repeatedly. We are inventing new things. Then another good point: Methods are not competing, “doing XP does not diminish the value of Kanban. Team can move from Scrum to Kanban if needed”. What he did not mention is the spectrum of work: different work requires different approach. Different approach do not succeed in random, they succeed if they are applied in correct environment.
I did not like the pseudo-funny “Agile-hakka”-video (team fails in their planning, so they go and dance aboriginal hakka and then gagnam-style).
Some nice quotes from the end of the presentation
“You can’t scale crappy code”
“You can release too frequently” (for example Adobe updates or large enterprise systems)
“Develop on cadence, release on demand”
At the end were few things I did not like
- Dave suggests common sprint lengths (cadence) across organization. This may or may not work, depending on the demand to the teams
- Every team must be on train, you don not integrate if teams are not in synch. Again this synchronization is done because organization, not because customer demand.
- “Enter the Agile dimension”-video, promoting Dave’s work with a customer.
My key takeaway: I know about SAFe and some thinking behind it.
Keynote: Laurence Vanhee / Happiness at work, you deserve it!
The second keynote was a very interesting piece. Laurence is a Chief Happiness Officer in Social Security Office (basically government job). She talked about happiness.
The talk started kind of awkward. She wanted to make jokes, but they were clumsy and audience was not with her. Eventually the pace improved and we had nice laughs.
Did you know that origins of word “work” are
in French: Travail = tripalium = torturing device
in Flemish Arbeid = Robu = Slave
She listed worst jobs in the world, including Fukushima cleaner and Foxconn employee. Then we watched a funny video about a complainer; person who had to work 14-16 hours a day, without labor union, all day standing up, hands aching — as a masseur for gorgeous supermodels.
Laurence mentioned that traditional HR tried to make people happy with policies: Salary and bonuses, job descriptions, organizations, motivational events.
She had found that real happiness comes from: personal challenge, job where you are at your best, right time, right skills, trust, freedom and autonomy (“we are adults, law prohibits child labor”), achieving personal results and monitor the progress, feeling responsible, receiving feedback, improving self-confidence, being part of the team
We watched again few funny videos about breakdancing traffic police and hip-hop flight safety announcer.
People who feel good work better –> happy people feel good –> Happy people work better
Research shows that happy people are 50% less sick, take 6x less absence, are 9x more loyal, 31% more productive, 55% more creative.
Five principles that Laurence promotes at work
Don’t motivate – Trust
Don’t manage – Love
Don’t think – Think green
Don’t work – Have fun
Don’t complain – Innovate
The results of the policy are very good. Laurence highlighted that their office have
Engagement rate is 88% (how likely you continue with us)
Attrition dropped 50%
69% are working from home
Job applications increased +500%
50% of leaders are women
38% in top functions are women
She ended by saying: If you can not live your work, leave your work.
Yuval Yeret: Starting Kanban – Managers first
After the keynotes, I joined Yuval Yeret’s talk about Kanban transformation. His talk was interesting mix of techniques. We started with Pecha Kucha – he gave a lightning talk where slide change every 20 seconds. Interesting twist was that his presentation was one picture, which scrolled and zoomed to various details while he was talking.
Yuval mentioned that team level agility is kind of solved case and getting managers on board was the bigger challenge. How to make management understand language that matters in teams (WIP, classes of service, Kanban). His proposal was to work in Kanban mode with management as well, helping their work, and gradually “merge” teams’ work with management.
Unfortunately I had trouble following Yuval’s presentation. While “zoomable flyover” was a nice trick, I did not understand where the talk was going.
After the pecha kucha he talked about transformation anti-patterns:
1. Analysis paralysis: People want to plan everything before starting anything
2. Managers are left out from transformation (here I argue that if someone does not understand what teams are doing she should go there and learn!)
3. fake agile: keeping silos and having tons of dependencies
4. Pilot approach (“tiger team”), managers feel outsiders
We discussed in small groups about the anti-patterns. After this, Yuval started a Q&A session and some participants were active. I did not get much from that.
This session did not provide me much, probably because I work mostly with managers and do not see the same way the fear of “managers are left outside”. Key takeaways anyway were:
- Involve management and understand their reality
- Try to make teams have “WIP diet”, that brings fast visibility to system
Egor Sviridenko – I SEE, how unconventional visualization helps agile projects
Next up was interesting session that turned out to be the best experience for me. Egor Sviridenko from Targetprocess gave a speech about visualization.
He started with a (familiar) story: London cholera epidemic in 1854. He pointed out that John Snow used visualization to identify patterns of epidemic and finally found the cause. Egor concluded that visualization is a fast way to influence thinking.
He presented four patterns of visualization
1. Networks give relations between things, for example mind maps. He shows some quaint examples of maps: “200 most visited websites as Tokyo subway map” or “Agile practices train map”. Also Kanban board is a map, since we can see relations between things.
2. Maps tell stories. Egor told how Charles Minard created a map of Napoleon’s mission to capture Moscow: 400.000 troops started the journey and about 10.000 returned alive. The maps illustrated locations, temperatures, sizes of armies and battles. This is a key point: visualization should tell a story.
Another examples of maps were newspaper interactive maps, e.g. NY Times illustrating immigration from 1800′s to current day.
3. Many variables is illustration where lot of information is shared quickly. Here his case was Score-board, illustrating risk of cardiovascular diseases across gender, age, blood pressure and smoking. Kanban board is a multi-variable map, where sizes and colors and locations of cards can combine several things together.
4. Timelines are powerful to make a subjective experience of time into a objective. Egor showed funny pictures of movie timelines, with characters appearing and taking roles and disappearing. Next example was Marey’s train time table visualization from 1880′s and finally he showed Sparkline from Tufte.
Egor ended his presentation by saying that good visualization tells a story. It can improve flow, save time and even create fun at workplace,
I enjoyed the talk a lot — it was a perfect conference presentation. I did not learn anything that I could use next Monday, but I feel something is bubbling in my mind. His slides were nice, easy to follow and presentation style was nice.
Key takeaway: Visualization has a story to tell. It is a fast way to influence people and a gateway to a deeper analysis/discussion on details that become important.
Paul Klipp – My first two years with Kanban, hard lessons for the quest of flow
Final presentation before my own was Paul Klipp’s experience report with Kanban. The session started with a longish presentation of childhood and hugh-school experiences. When he started talk about SW development, he made an interesting observation about Scrum.
Very often Scrum teams take stories and work parallel with many stories. That creates a flat burndown chart, where visibility to “done” comes very late. That causes mistrust and stress, if the first item is fully done at day 8 of 10 day Sprint. Remaining work may burn down nicely, but nothing is done before very end.
He then showed how Kanban and limiting WIP and completing items one at the time created better visibility to system: how things are going, where are the bottlenecks. Also team members worked better together, when WIP limits were “forcing” collaboration.
Then he talked about the tool they develop: Kanbanery. Thankfully he did not promote or sell the tool, but instead told how their process evolved. They started with Scrum-ish process and added WIP-limits later. In his team the limits were aggressive and he instructed to use looser WIP-limits if team is not ready to take shock therapy.
His learnings in the Kanban journey were:
- Meetings need structure despite the fact that Kanban does not give any structure for meetings
- Backlogs are waste: bad ideas and harmless bugs go there to die
- Experiments need to be done with clear goal in mind and with a test that proves if the goal is achieved
- Lessons-learned need to be captured better: Write down process policies but do not use permanent ink
In Paul’s opinion the best product owner is a person who wants the SW really badly. She can always tells what the 2-3 next features.
To me the story was interesting and key takeaway from the session was: Device experiments so that you have a hypothesis in mind. Finally validate the results of the experiment.
Rest of the conference
Next session was my “Achieve flow”. I will write a separate blog about the contents. Speaking in a conference was again interesting and motivating experience.
After my presentation I had to leave before afternoon keynote. As usual, for second day afternoon keynote (The art of cultural hacking by Stefan Haas), it seemed to be less formal and more into unexpected. Before I left the venue, I heard “Gagnam Style” once more. Interestingly, I had not heard that before today and now I heard it twice. This tells something — either about me or the Kanban community.
Thanks Maarten and other organizers for a great conference. I attended many useful sessions and met lot of great people. This is the conference I like to attend: high quality, relaxed and well-organized.
DARE2013 conference, Day 1
I attended DARE2013 conference in Antwerp, Belgium, on June 14-15 2013. The conference was earlier called “Re:Think Kanban”, so it was about Kanban, Agile, Lean and Systems Thinking. Here are my notes from day 1. Sorry for a long blog post..
I arrived the venue late (10:30), so I missed the two first keynotes. These were by Jurgen Appelo and Jimmy Janlén. I did see last 15 mins of Jimmy’s presentation about Spotify and that was very interesting. If just my flight would have been 30 mins earlier!
Session 1 / Benjamin Mitchell: More than just moving cards on a board: Demand-driven Product Development with Kanban.
Benjamin gave a presentation about his experiences with Kanban. He started with a case where team “was doing OK” but Benjamin was frustrated. Turned out that organization was missing purpose, or their de facto purpose was not motivating (“Make rich people even richer”). Then Benjamin presented Purpose – Measures – Method framework. In another case he explained that mindset impacts what we see: this case the team was frustrated when they kept looking at remaining work while Benjamin was happy when he was looking at Done column.
After this Benjamin walked through Theaory of Action (mindset -> behavior -> results), Double-loop learning and learning model from Argyris (learning requires valid information and freedom to make choice and constant monitoring of actions).
Towards the end of the presentation he showed control charts and told about A/B testing.
My key takeaway was: Lot of our thinking is assumptions and we have to pay attention to test those assumptions. Otherwise we are limited to make poor decisions.
While the presentation was energetic, fun and had lot of interesting stories from digital media world, the link to Kanban was relatively weak. Also “demand-driven”, as promised in the title, did not quite realize.
Session 2 Mattias Skarin / Visualization – whats my brain got to do with it
This was something completely different. Mattias told us about brain and how it works and how we see. More precisely, how we process information and what that means to visualization at the workplace. Mattias showed several funny videos and pictures where we could test our capability to observe and see.
The session pointed out three issues with brain: (1) Flicker paradigm, our brain has very limited capacity to store visual information and we really live in the present (i.e. can not remember what we saw just a second ago), (2) Change blindness, we only see what we think is important and (3) stress greatly reduces our ability to see.
Putting these together Mattias proposed few ideas for visualisation on Kanban board: Use images that trigger our pattern matching capability, make it interactive so that more sense are involved and make it persistent so that we more easily spot changes.
My key takeaway: We have to teach people to see. If we try to visualize things that have no meaning for the audience (e.g. flow or WIP), they will not see it.
Mattias session was really worth joining. Some of the topics had very weak link to reality and they were anecdotes and interesting details. But in general this brough a new perspective to visualization and reminded that seeing is very subjective experience.
Session 3: Richard Moir / Are we solving the right problem? What happens when you apply the Vanguard method to IT systems
Richard started by introducing concept of system and systems thinking: rather than focusing on parts separately, try to focus to the relations of the parts. This was by the way very close to my presentation at Scrum Gathering Las Vegas (see video). Richard then claims that everyone in the organization has the best intentions, so why thing fail. Reason is flawed thinking, “industrialized management thinking” as John Seddon says.
After the intro, Chris Preston from Aviva presented their case. When Vanguard came in, the IT was a mess. Studying the work showed that 90% of work was other than SW development (coordination, management, “trying to look good”). Average lead time for 100 lines of code was 340 working days, 2 years, and the delivered stuff was probably wrong. This was because system conditions: multitasking, standard deliver, specialized teams. And this was because Thinking: manage costs, standardize, inspect for quality, look busy and control.
“I thought it was a culture problem, but it was actually a thinking problem”.
After intervention, things went better. There was 300% increase in productivity (90 days for 100 lines of code in now upper limit, usually delivers in 3-4 days). Waste is down from 90% to 60%. This was achieved by creating a System of single-piece flow, problem centered team, Value flow and continuous improvement. These were created by new Thinking: Design against demand, manage flow, learning and build quality.
After the case, Richard summarized their work in Aviva: (i) Study and understand what happens in organization and (ii) Understand what assumptions we have in our organization design, why are we organized the way we are
The presentation was well-structure and Aviva-case brought life to it. While most of Vanguard was familiar to me already, it was still good to see what happen in practice and h0w important it is to manage work against demand.
Session 4 / Vasco Duarte: See the “whole” – how Kanban can help you see the system and fix it!
Vasco told his experience about using Kanban to visualize things and improve. He started by interesting research results: while 75% of Agile adoptions fail, still 60%-70% of people would not want to go back to old ways of working. And since we have gone through lot of adoptions during the past 10-15 years, seems that trying new things is favored by people. Vasco mentioned that we as coaches and change-makers are actually responsible for hope and well-being of people.
Next Vasco presented causal-loop diagram of a problem he had. Pressure to do extra work caused need to have more people, which eventually led to off-shoring and that caused extra work due to communication issues etc. He then showed interesting process diagram, which is the most common in R&D or IT
(here be dragons) <–> R&D <–> (here be dragons)
R&D and IT are stuffed between marketing/sales and markets. That is an uncontrollable environment, especially if the organization has tendency to do any work that comes from either direction.
In order to solve this, Vasco showed the evolution of their Kanban system. From visualization of demand to merging two teams together in order to reduce dependencies. Finally figuring out that live system causes different kind of demand to the team that was invisible before.
But did this help? Vasco ended his presentation with a pessimistic tone: politics destroyed the good intentions of the teams. Acting only on the system, without changing the politics, is not taking us very far.
At the very end Vasco invited us to tell stories: blog about experiences, talk in conferences, spread the word. This, he said, helps to draw the map of the world. Just like the first explorers did.
Afternoon keynote: Steve Tendon
Day ended with a keynote by Steve Tendon. He started with promotion of his new book about hyper-productive teams.
After the commercial break, he presented a business case for improvement: how should organization decide between XP or BDD. He viewed it from accounting & engineering perspective and tried to calculate what option would be best. Finally he came to an interesting conclusion that accounting-type of calculation would give wrong results because system had a bottleneck. Even the numbers showed shorter lead-times, the overall performance would not improve.
Then he told a story of Herbie from Eli Goldratt’s “The Goal”(boy scouts marching, one guy falls behind, how to keep the group going). How the constraints in the system should be treated. He pointed out that bottlenecks have significant economical impact of the outcome.
So far the presentation had been floating between embarrassing, boring and useless.
But suddenly Steve got to the point. He quoted Reinertsen who said traditional organization revolve around metrics about money, so we need to learn to talk their language. Steve’s message was: if we want to create hyper-productive teams we need to have (i) Unity of purpose and (ii) community of trust. And how to build this? By having a common goal.
One way of creating a common goal is to align the purpose and this could be done through financial or economical measures. Instead of measuring gross-profit or sales commission or resource utilization rate, how about measuring flow: how much money we make per day. This aligns the organization. While some parts may perform “un-optimal” way, the whole is optimized.
My key takeaway: Purpose aligns organizations. If we want to align everyone in the organization, we have to speak their language. Language of management is numbers and excel and we have to find a meaningful way to present the purpose in their language.
Four shades of coaching
Coaching is a way to help people reach their potential, get energy to pursue towards important goals and understand their life or work from a new perspective. The best coaches I’ve met, they only use questions to open up and clarify my thinking.
I struggle with this issue: I am not the best coach, I’ve only started my journey to become a great coach. And who says coaching (only asking questions) is the only way to help other people? Could I find something that fits my personal style, allows me to be not-perfect and suits in different situations?
I got the following model from Kati Vilkki at Nokia Siemens Networks some years ago. It has proven to be very useful for me, when I have been moving from (command-and-control) management role to a coaching role.
The model helps me to understand my behavior. I never impose this to people I talk with: I do not judge or evaluate people with this — I don’t even show them this model. This is a tool for me to plan a discussion or reflect the discussion I just had.
The model looks at discussion topics from two angles: (1) Do I focus on the process or solution and (2) how supportive or directive my approach is.
Click to enlarge the picture.
For any problem we can
- Tell the solution: This works best in a panic situation (“Fire! Evacuate the building“) or when people have really low competence to do what they are supposed to do. This could also work in simple one-off situations, for example telling a colleague how set display resolution for video projector
- Propose a solution (“Loaded” questions): If the person lacks only knowledge or outside view, proposing solution alternatives could help forward. This requires that people have motivation and are just short of new ideas
- Tell a way to solution (Process): This works in a case where goal or solution is clear, but the person does not have energy to think of steps towards the goal
- Ask open questions: The Real Coaching is here
Staying neutral on the process and solution, just helping people talk and think
There are couple of points worth mentioning with the model.
Different situations require different approach. Different approach gives different long-term outcome. Using lefthand and bottom corners increases dependency. Providing answers (process or solution) does not encourage people to that by themselves. People and teams will not develop to be self-organized. Ownership of the issue stays on advice-giver — therefore advices that you give may not stick and the the team falls back to old ways of working.
On the other hand, working on the righthand side and top may feel uncomfortable and increase anxiety. Imagine if a person comes to you asking for help (assuming you give advice) and suddenly you start asking questions? The person may feel ignored or even angry.
I have found out that whichever “box” you start the discussion, you can only move left or down. If you start advising or telling the process, the others will expect you to continue on the same lines. It will be very hard to “climb up”. That is helpful point for me: In every discussion I try to start as “high” as possible.
A corollary to the previous point is that you can move down or left. I use this if the situation is not suitable for top-right corner. Maybe people are exhausted and need more support. Maybe people feel there is not time for open questions and I help them find more time. Maybe the meeting invitation mentioned “a professional who will answer all your questions“. Whatever the reason is, I can move “down” in the model and provide more safety when needed.
As I mentioned earlier, this is a tool for self-reflection and developing as a coach. This model does not give you ready-made questions or structure to design discussions. I use this model simply to understand my style and how it may affect the people I am talking with.
I hope you find this useful.
By the way, which category in the model this blog itself post would fit in?
Importance of pull, WIP limits and Kanban system
When improving a performance of a system (for example SW development department), people often try to improve the system itself by doing process improvement, organizational changes or removing waste. Such initiatives look at the system detached from its environment and from customer demand.
This inside-out approach will not create significant impact. Changes are not sustainable or the system returns to un-optimal state whenever the environment changes. Fixing the system from inside-out is like taking aspirin for headache: helps for a short while but won’t take away the reason for pain.
More important is to look at the system outside-in, together with its environment and create balance between demand and capability.
A scale is a common illustration of this. Most organizations act on the righthand side of the scale and ignore the left.
The organization operates at its optimal when demand and capability are balanced. For example, a simple system of supermarket checkout register: if there are more customers (demand) than cashier can handle, it creates a queue. This case is easy to solve by adding a new cashier, i.e. increasing capacity.
In software and service development the imbalance creates non-value-adding work (sometimes called waste). Have you ever been in a prioritization meeting? Or tried to work with several tasks in parallel? Waited for your colleagues to finish their part of the job? Filled in status reports for management? Been asked to work overtime? All of these are signs of overload. They are not only unpleasant — they significantly decrease the throughput of an organization: dealing with overload (imbalance) is failure demand: work that does not add any value and is created by the system itself because original work could not be done as promised.
Demand and capability are all the time fluctuating. Therefore balancing must happen when the work enters the system, not before and not speculating. Working in projects hides the real demand (as well as the real capability). Projects make assumptions about work and this makes it virtually impossible to take any balancing actions once the work is put into a project.
In order to reach the balance, the system must be a pull system. In a pull system the downstream work takes (pulls) work from upstream only when downstream has capability to proceed with new work.
Push systems ignore the capability of next step. In out supermarket example, push system would be customers piling up their groceries on the belt. That would block the flow totally.
Pull system requires that work stages have limits for work-in-progress (WIP-limits). Unless the work is limited, there is no mechanism to enable pull and the system turns into a push system.
A pull system creates flow of work that is optimal for the current system. Once flow is established, it helps to estimate completion of work. Such system is more predictable and has less unwanted variation (caused by failure demand). Having a stable flow also helps to improve the system (right side of the scale): once the work becomes more predictable, the impacts of changes are clear.
Click to enlarge
Kanban system is not only blue tape and yellow PostIts. It is more than just visualizing workflow or measuring cycle times. Kanban creates a pull system that balances demand with capability. In addition, Kanban allows to study the real workflow and improve gradually.
To put it short: WIP limits create Pull and this balances demand with capability. Such system operates at its optimal and provides predictability.
Golf, Colin Montgomerie and cost-per-head
Colin Montgomerie (“Monty”) is one the best golfers of all times. During his active career, he played over 500 European Tour events and won 31 competitions. In addition he owns several records in European professional golf: most wins in one season (6), number of hole-in-ones (8) and he has been chosen to European Tour Golfer of the Year four times[1]. While he never won any Majors, he very recently guided Team Europe to an unforgettable victory over USA in 2012 Ryder Cup.
By March 2009[2], Monty had played 499 European Tour competitions and won total of €23,639,775. Someone counted all the strokes he took over the years (121,525) and got an interesting average: every time Monty hits a ball, he earns on average €194. Every single time. Every drive, every putt; every 5-iron from rough, every single bunker shot. Every time when club contacts a ball in a competition he gets almost 200 euros.
Cost-per-head, on the other hand, is a business measure. It shows how much salaries and side expenses cost on average (including social security costs, retirement funds, premises and equipment). Cost-per-head tells, on average, how much it would take to increase number of people (or “head-count”) in a given location.
Cost-per-head is widely used in companies that are doing knowledge work: work that requires very little raw materials and practically all of the value is created by people doing thinking (e.g. programming) or providing services (e.g. call center).
Wait a second. Why am I talking about Monty’s €194 per shot and outsourcing to India in a same blog post?
It is about decisions based on measurements. And how terribly wrong things go, when a seemingly relevant measure is actually horribly misguiding.
Success in professional golf is measured by earned money. Winning a competition is measured by number of strokes (shots) a player takes during rounds. So, “euros per stroke” should be a perfect measurement, right?
Of course it is not. Let’s imagine Monty wants to increase his earnings in a competition. Looking at this measure, instead of 285 shots (about par -3) he should shoot 290 or even 300 (par +12). Adding 15 strokes would give him a hefty €3000 extra in a competition.
Everyone who knows anything about golf understands right away that hitting the ball more is completely stupid. If a golfer wants to increase earnings, he should shoot less.
Success in business is measured by profit. Profit is earnings subtracted by costs. Since most of the costs in knowledge work are people, then cost-per-head should be a perfect measurement to optimize the equation.
Let’s imagine a company knows its cost-per-head is 20% less if off-shored and company wants to increase its earnings. Looking at this measure, instead of X people in current location it could have 25% more people with same cost. Wow, 20% saving leads to 25% more resources!
Everyone who knows anything about knowledge work understands right away that having more people is completely stupid. If a company wants to increase earnings, they should find the right competencies and create flow of work — not look at number of resources.
Unfortunately, costs are often on the driver’s seat. Companies are looking for quick improvement by getting rid of costs and overlooking the bigger picture: how do we actually create value.
As Russell Ackoff said: “Getting rid of what you don’t want does not guarantee you get what you do want“. Reducing cost does not bring earnings.
Test your measures: What if we make decisions based on this measurement, what would customer see? If the answer is “nothing” or you start to speculate a lot, then you are probably measuring a wrong thing.
—
[1] Colin Montgomerie’s official homepage: http://www.colinmontgomerie.com
[2] For collection of Monty’s golf stats, see for example http://www.boards.ie/vbulletin/showthread.php?p=59548477
LKCE Day 2
It took me one month to complete blogging about Lean-Kanban Central Europe. First day of conference is covered in previous blog post.
Morning keynote: “Science of WIP limits” by Don Reinertsen. I had high expectations for this session, since I had never seen Reinertsen “live” but had read his books and saw videos of his talks. Unfortunately, I had seen this talk before (in InfoQ) so the session itself did not offer much new. However, this was a good reminder of WIP and related issues.
My key takeaways from this session were: (i) Systems have tendency to drift to high-queue states and preventing queues has big impact on system behavior, (ii) even a minimum constraint on WIP improves the system without negative impacts and (iii) decisions about queues (WIP, priority, purge,…) should be based on transparent economical framework .. also make transparent if you don’t know the economics
Session 1: “Lean Meetings” by Jim Benson. He has earlier written book about Personal Kanban and now he is on tour advertising his new book. Jim started by misunderstanding Agile and was very American about bashing anything that was not his idea. Then he presented traditional org.charts and pointed out that silo-organizations were actually very effective during the era where (a) cost of change & cost of product creation were high and (b) cost of information was high. Things have changed, so is need for management, information sharing and meetings.
At the end of presentation I had not much to take away. Some new viewpoints: (i) discussion about status and goal are waste in meetings, these should be known by other means, (ii) Meetings should be shared experiences (e.g. working around same Kanban wall) and (iii) meetings fail the same reason projects fail: pre-planning does not work.
Session 2: “ChangeBan” experience story. I skipped this one after 10 minutes or so, I could not understand the point of presentation. I moved to hear Hermanni’s presentation about “System Conditions”. The video is available here (http://bit.ly/RPaSxx). System Conditions was the topic that had the most profound effect on me. It combined systems thinking with organizational reality and showed how (i) change sustains only if the system is changed and (ii) software development is not only software development.
Session 3: “Portfolio Kanban” by Mike Burrows. I was waiting this session since many people ask about “Large projects” and “managing portfolio with Kanban”. I was a little disappointed; I did not get the point of the presentation. There were three case stories and I did not catch anything regarding “portfolio” Kanban. Key takeaways anyway: (i) spiderweb graph to illustrate “depth” of Kanban implementation, (ii) portfolio Kanban is about alignment between managers / customers / peers / team / you.
Session 4: Lightning talks, short sessions without limits.
The first lightning talk was about ”Introducing the change” by Pawel Brodzinski. The trick of the presentation was to handle it through PostIt notes; Pawel pasted tens of postit notes while he was talking. I did not get much from the story itself: main point was (I guess) change is about trust.
Second speech started with annoying and embarrassing Star Wars intro. Talk was “May the Forss be with You” by Hakan Forss. He presented basic Kanban and systems thinking stuff through his trademark Lego pictures. Key takeaways were (i) Human brain needs visual management and (ii) Remember to Collect Data, Go See, Create Habit on Continuous Improvement and Experiment in Small Steps.
Third, and the most interesting, was Benjamin Mitchell “Little less action and a little more conversation”. He challenged Elvis Presley and many others by saying that we actually need to discuss more. He pointed out (very correctly) that Scrum & Kanban provide lot of room to discuss about Doing The Work. Then he listed other topics where a little more conversation would be useful: Purpose, Demand/Need, Work Breakdown, Prioritization, Work Distribution, Team Conversations, Possible Value Deployed.
Finally Gaetano Mazzanti presented a quaint idea of “visualizing” Cumulative Flow Diagram with alternative styles and even sounds. The idea may be more entertaining that useful, but he showed how graphs become more alive by illustrating e.g. age of ticket by different colors and state transitions by sounds.
Session 5: “Double-loop Learning” by Benjamin Mitchell. Again this was a presentation that I had seen before. Still it was interesting and I tried to follow it with fresh eyes. Benjamin presented several models for learning and change, including Double-loop Learning, Ladder of Inference, Mindset-Action-Result. We experimented a little with observation and interpretation. Benjamin’s session was inspiring and I still managed to get several takeaways: (i) Make low-inference interventions, sharing observations rather than advise or judgement, (ii) I see only part of picture and re-framing my approach can change the situation, (iii) make sure you see -> check what others see -> create a full picture from observations.
The conference ended with keynote from David Anderson. He presented very new ideas how to measure Kanban in teams. The keynote started with a very good introduction to Kanban, David has really created a nice 15 min package of Kanban basic idea. Then things turned really odd. David presented question: “Which of several teams should take work from queue? Which team is most suitable?”. He studied the question from financial perspective and created an interesting liquidity model for Kanban: each card movement contributes to “liquidity” of the team and the most liquid teams provide least risky and “correct” throughput.
While the idea was sound and internally coherent, there was a big trouble: I think David was asking the wrong question. It is not the point of “choosing teams” or “finding the most suitable team”. I would ask other questions: why do you have three teams? why do you need to choose? does the organization match the customer demand?
What makes a great trainer?
I have had good fortune to work with some exceptionally great trainers. As I am working towards my Scrum Trainer Certificate (CST), I have been paying attention to training techniques and especially the what part of trainings. My insight is
A great training finds the core message, presents it with clarity and explains the message through several layers for understanding.
My model has three layers and all of them are needed in order to deliver a great training.
The topmost layer is artifacts: rituals, tools, templates, processes and anything else that you can observe at workplace. Many trainings limit themselves to this layer: goal of the training is to learn a new tool or process.
The next layer is stories: it is examples, anecdotes, metaphors and other stories that are used to illustrate the topic. I also include games and simulations in this layer. Stories are a powerful tool to get the message through. Trainer sharing own experience or participants playing a simulation game is a good way to highlight key points of the topic at hand.
The core – and my insight – is that a great training delivers a core message, key points that make the difference.
A good training may fill you with new tools and great sories but a great training connects all this into a meaningful core message.
As an example, Scrum trainings at Reaktor cover the layers in the following way.
Artifact layer is about Product Backlog, Scrum process overview, techniques for scaling Scrum. Anything that you could use as is in your organization after the training.
Stories are trainers’ experiences using Scrum and simulations & games we run during the training.
The core message in the training is clear. It answers the question What for is Scrum? All artifacts and stories link to the core message and core message becomes alive through artefacts and stories.
The core message must be relevant, focused and sufficiently unique to the topic at hand.
An example of a bad core message would be: Scrum is about better quality and happier customers. Well, Scrum is also about that, but so is any other method. Such core message lacks uniqueness and focus.
None of the layers alone are enough to provide a great training. Not even the core message is enough alone: The core message is not comprehensible without related stories and artifacts.
OK, so far I have been talking about a great training. How about a great trainer?
To my opinion the most useful skill for a trainer is not creating a structure for a training session or how trainer is using her voice or how to make beautiful drawings on the flip chart. Those skills are needed, but those alone do not make the trainer great.
A great trainer finds the core message in the training he/she delivers. A great trainer understands the the topic – preferably through own experience – so thoroughly that the core message is relevant, focused and unique.
Unique and relevant core message creates curiosity and curiosity leads to exploration.
A great trainer balances between artifacts, stories and core message. Metaphors and stories make the core message more alive and artifacts show how the core message realizes in daily work.
On my way to become a better trainer and qualified CST, I use this framework in all trainings I deliver. As a training participant, I listen the training content through this framework, Most recently, I used this framework to understand conference presentations in Lean Kanban CE. Paying attention to content and layers hopefully helps me become a great trainer.
