Slack is a Culture Shock

Yesterday on the 'yes, we Kanban! oder: Kanban auf Unternehmensebene' meetup at Immobilien Scout in Berlin Arne Rook said in his awesome and funny talk that slack is the ultimate tool for Kaizen. I think that is true and wonder why allowing slack time also is a culture shock for so many work places.

As I understand, the argument goes like this: In an environment where the purpose is clear, the problems are discussed open and the work is managed visible people have the chance to act intelligently without further advice and in most cases will do so. So, given an environment that allows people to make good decisions and assuming people are creative on their own, slack time enables a group to cope with complexity far better than if everybody would be fully loaded with work without time to look and think. I have experienced this happen many times, more in a Scrum context but this is not so relevant for the point - and believe that slack time in an Agile context is a good thing.

So why does slack time in our work culture still have such a bad reputation and the opposite, busyness, being valued so high? Why is it creating fear if you start a new job and after two weeks still are not 120% busy on a project? 

It's interesting to observe in the video 'The Trainee' of the Finish artist Pivli Takala the reactions that are provoked by a trainee, who just sits thinking at her desk without a computer. At least busyness is not solely a German issue. 

Design the Right Thing

Mary and Tom Poppendieck joined the Scrumtisch in Berlin last Monday where Mary gave a great talk on Design Thinking and lean software development. Here is my take from her presentation. Understanding what to design is the hardest job in product development, at least in many areas of software development, especially consumer products and services. Small diverse teams are much better at doing the job of framing the problem than a single person. Many Scrum implementations fail to address this design problem because of

1. putting the design work on to the shoulders of one single person - the product owner problem and/or
2. creating a handover by separating the design work from the implementation work

In her presentation she quoted several approaches to solve this issue which all share a holistic viewpoint and include a double loop iteration over the activities understand the problem, design the solution and address the design problem with a full team. I took a clip where Mary Poppendieck relates the lean startup approach to Agile and compares it to the concepts of Scrum as an example of an Agile framework.

The concepts from the Lean Startup approach she compares with Agile like "Get Out Of The Building" vs. On-Site Customer or “To Learn” List vs. Backlog are compatible extensions of Agile concepts embedded into the holistic view of a business organization instead of the more narrow dimension of product development. Whenever uncertainty is high, the most relevant prioritization factor for a Backlog should be "The amount and significance of learning and new knowledge created by developing the features" (s. Agile Estimating and Planning, p. 80, Mike Cohn 2005) thus actually making it to a "To Learn" List like Mary Poppendieck suggests. Accepting that there is such uncertainty and consequently (re-)prioritizing the Backlog to gather more knowledge with the full team or dealing with the uncertainty as product owner alone are the real problems which are too often ignored. Pointing this out and providing a set of tools to deal with the uncertainty is exactly where I see the most value in the different Design Thinking approaches she presents.