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.