September 28, 2012

Blame On!

At the first Agile Game Lab in Berlin, which I am organizing as a regular event together with Stephan Schwab, we had chosen the historical Beer Game and the new Blame Game (1) that just emerged from the last game incubator (2) hosted by Agile Holland (3).

 The Blame Game is pretty simple yet powerful to experience what different reward system can do to a group. In the game a group builds a house of cards and uses two different reward systems for making progress. On collaborative where the whole group wins, when a card is added or looses, when the house falls apart. Erwin suggests in his blog (1) to play different rounds with the same group but changing reward systems. We modified the rules, so that one group used the collaborative and another the competitive reward scheme without knowing about the other and played several rounds with each group - round ending when card house collapsed.

After 45 minutes we joined to tell stories and share insights. Both groups had a different size and gender mix, so don't call this experiment scientific. Still it was amazing how different the stories where. In the competing group did not take much care about how often the card house collapsed. Player were not taking into account how the next player could add a card after one self put her card on the house. Their card house evolved flat and was shabby compared with the card house of the collaborating group. The collaborating group actually invented ways to make the house more robust by adding thicker walls consisting of multiple cards. They discussed how to improve the card house while the competing group did not do any planning or designing.

A framework (4), that I came across for a while - thanx to Christoph Oberle for sharing - seems to make some sense of the situation. Obviously the competing model and the collaborative reward system differ in the psychological safety they create. The bond that emerges between people who share the goal of building a card house did not emerge in the competing model. It's a bit far-fetched to talk about Anxiety or Apathy but it was obvious that the collaborating group had more fun.

Insights: It was good to have at least two groups play independently and more than one round with the same rewarding scheme. It would be interesting to play for a longer period of time and see how this changes behavior in the group. Then use story telling for the debriefing and try to find frameworks to make sense of what happened. I would limit the building ground to force card houses to grow higher but not add any other constraint for building to allow for maximum creativity. Would be interesting to play with additional challenges, like beauty contest of card houses or even add a Product Owner to tweak the goal axe of the game. Sad, that we missed to systematically capture the house designs to use in debriefing. If there are many people at the Agile Game Lab I would ask people to act as observers, interesting to hear their voice in the debriefing too. And last but not least Blame Game makes good use of all the branded planning poker cards that we don't need anymore.

(1) Blame Game,
(2) Game Incubator
(3) Agile Games Night by Agile Holland
(4) From The Competitive Imperative of Learning, Amy C. Edmondson, HBR 7/8, 2008, p. 60 - 66

September 21, 2012

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. 

September 17, 2012

Leadership for Startups: Change Agent

As Kent Beck (1) says in his talk at Startup Lessons Learned 2011 Initiate Change is core of any startup and goes beyond the agile manifesto's goal of being capable to respond to change. If the startup successfully changes the world, it has to scale - or to pivot, if the product hypothesis proves wrong. Both, success and failure, require a difficult to lead change that affects the everyone in the company.

At the last leancamp in Berlin I have used a brief version of the Change Agent exercise form the management 3.0 agile leadership practice training to gather and share insights with other lean startup enthusiasts.  Here is what I have learned from the session.

First, since my partner Mike Leber missed his early flight in Vienna, I had to choose between the sessions I wanted to do. A/B testing by asking for hands up voting at the open space "Grow a Lean & Agile Organizational Structure" vs. "How to lead change" showed, that there was much interest in the change topic but little interest in growing structure. This result had little to do with the voting on the user voice. Learning: don't take votes on the user voice too seriously and be prepared to act in the moment.

After a very very brief introduction to the management 3.0 framework of change, three groups formed to tell stories about change and to share their insight how the change worked and why. The management 3.0 framework considers change from 4 perspectives: System, Individuals, Interactions and Environment.

Part of the game are a set of cards, which provide questions to make you think about the aspects of change fand gather input or playing the story telling game. What I think many people found puzzling was to start with a more abstract framework instead of using more emotional input like pictures to stimulate their phantasy for story telling. Learning: Don't use the framework to inspire story telling but use it for gathering insights.

The story share&capture exercise itself worked pretty well though and I got some feedback that the stories vs. insights concept actually was a simple and powerful tool to guide the conversation. Below you find the pictures I took from the wall. In case you have any feedback for me about what you like, what you wish and what if whatever comes to your mind let me know.

(1) Kent Beck talks beyond agile programming

July 31, 2012

Fail Better

In 2009 the CEO of the startup company moreTV asked me to help with his product development [1]. The startup had grown over several years into local - German/Romanian - and functional units. Within the dysfunctional silo structure even crucial information like: "when would be the first platform release for a partner" got lost. I remember one of my first meetings together with the management circle as everyone started to scream and shout at each other when it became clear that the new product would be released several weeks after the IFA fair in Berlin. Product development was split into product management, backend, set-top-box and operations as well as distributed over two places in Germany and a subsidiary in Romania. The German developers were working more or less independently on several projects while the Romanians where working more like a team, yet disconnected from the rest of the company and mainly dealing with buggy set-top-box firmware or bug reports posted by German product managers. 

The reason I am writing about this story now is that I have just used it at the Product Owner Lab during the last weekend to illustrate two things: on the one hand it shows the power of Scrum to clear such a product development mess and on the other that Agile product development is not enough to be successful. After a year or so many of the issues I describe above were resolved: first we have formed feature teams and removed functional silos, second conflict of goals coming mainly from product, partner, operations and investor side were integrated into the Scrum Product Owner role, which was strong and directly authorized by the CEO, and third development was able to ship after short Sprints of two weeks on multiple platforms over satellite using a sophisticated automated deployment and test framework we had developed. While this is a success story for Agile and Scrum, the story of the company as a whole is a sad failure. The subscription base did not grow as expected and the product team was not capable to distribute the product on as many platforms as planned. By end of 2010 moreTV went out of business.

Scrum is, besides other things, a great diagnostic tool to make bottlenecks apparent to everyone and thus enable the organization to fix them. Scrum focuses on the 'Solution not known' type of problems and not so on the 'Problem unknown' type like Lean Startup[2] does though. It is easy to fall into the trap of the man who looks for the lost key: 
"A policeman happens upon a drunk crawling on his hands and knees under a streetlamp on an darkened stretch of sidewalk. When he inquires, the drunk explains that he’s searching for his lost keys. The policeman promptly kneels down and begins searching as well. After they’ve scoured the nearby pavement and gutter several times over the policeman thinks to ask, “Are you sure this is where you lost your keys?” The drunk replies, “Oh no, I lost my keys about fifty yards back.” He gestures at the darkened street behind him. “Well, then, why are you searching here?” asks the policeman. The man replies, “The light here is so much better.”[3]
Actually I believe in being good in Agile technically may even create a barrier to leaving the comfort zone and pivoting the strategy since development can become very efficient in solving complex issues and thus compensates 'how-to' problems with the strategy. Speaking in the metaphor of the drunk man Agile may provide more light at the wrong place for finding the key.

So what has happened? In retrospect complex things often are simple: the product scope was too big to make integration with hardware vendors easy and caused trouble in the manufacturing value stream. The firmware integration depended on goodwill of the vendors . The troublesome integration lowered the interest of partners to let the plugin onto their products even though our team found and fixed many issues of their firmware which would have escaped the partner's quality assurance. 

The Scrum Retrospectives, the Sprint Reviews and the visual management of impediments proved to be excellent tools to make the issues with firmware integration visible to everyone in the company and also solve them partly. The Scrum teams did an amazing good job in dealing with this dependency taking responsibility for the product cross-functional and end2end. They found creative solutions to the integration problem within their scope including frequent trips to China for onsite co-development at the vendor's site, onsite test support at the partners sites and a sophisticated automated build, deploy over local satellite link and test framework. I remember the Romanian team called Panda being deeply connected to the R&D people of a large Taiwan based hardware vendor. Still the problem persisted, which was revealed even more transparently after Scrum had removed the many other obfuscating issues. 

What blocked the organization from learning was from my point of view first the hierarchical distance between developer and CEO or product manager creating a cultural distance on which the assumption based that problems of development need to be fixed by development. Second the cultural distance between Romanian and Germans added to this problem too. I remember from Steve Dennings [4] Radical Management seminar a few weeks ago in Amsterdam that Steve said national culture is a subordinate factor.  Here is a good example that professional combined with national culture can form a strong impediment for organizational learning.  Another thing that added to the problem was that moreTV had once launched successfully a product with a very good subscriber registration rate. So there was kind of myth fueling hope that this would happen again. 

What would have been a pivot with more chance of success? Scaling down to a minimal viable product would have surely eased the integration pain. While the planned product feature set promised to company shareholders was clear, it was relatively unclear what customers really want. Since moreTV was a pure satellite based software with no backchannel it was difficult to gather insights from the users behavior. So it was relatively difficult to test hypothesis about the users needs but not impossible. After Go Live of the product there was plenty of data showing that the users liked the product only partly but some features were not used or even seen as annoying.  Scaling down the scope would have meant throwing away already developed features without knowing exactly what customers really liked and unfortunately was never considered as an option. 

I have no clue if a Lean Startup based approach would have saved the company but for sure it would have helped to fail much earlier. I find it interesting to see from hindsight how cultural issues blocked the organization to learn and explore potential paths towards success. moreTV is an example of Scrum and Agile done well while failing to be effective with the startup idea. The pivot of a companies strategy is beyond the scope of a Scrum team even though the pivot may have to be initiated by the team's insights. But this requires the flow of information from the Scrum team to the rest of the organization and not outvoting the fuel gauge that was flashing read [5]:


June 21, 2012

When Faith Moves Mountains

"When Faith Moves Mountains" is a work of art initiated by Francis Alÿs (1) and serves as a powerful metaphor of the possibility of change for me. "500 volunteers were equipped with shovels and asked to form a single line in order to displace by 10 cm a 500 m long dune from its original position" describes what took place in Lima, Peru on April 11, 2002. I have seen the video documenting the event a while ago at the Guggenheim Museum in Berlin as part of a group exhibition titled „Once Upon a Time: Fantastic Narratives in Contemporary Video.“ (2)  The video tells the stories of the people who took part in the event:

When Faith Moves Mountains (making of), April 11, 2002, Lima, Peru.

The work demonstrates the impact a faithful group bonded by a shared vision can have, when applying a simple action collectively to an overwhelming, arduous or complex problem:  moving a great dune 10 centimeters by shoveling a line of sand first up and then downward. The power behind the Chinese proverb "The man who moves a mountain begins by carrying away small stones"(3) increased exponential within a group and changed the peoples feeling of helplessness when individually facing the enormous challenge of moving a huge dune in the hot desert around Lima into a kind of euphoria when the group finally reached the top of the hill.

What the participants are saying in the video reflects how the event invoked transformation within the group's mindset mirroring the change in the physical world:
"But a group of people on the base of their faith can do things that otherwise would be impossible. Something totally irrational"
"Up at the top, we could see for miles around. We felt on top of the world you know."
Francis Alÿs goal is to infiltrate the local history and mythology by translating social tensions into narratives. Unlike the transience of the physical result of moved sand, the stories told by the participants will, if passed on, persist and become a myth that survives the event itself.

(3) via Inspiration e-mail for Agile Coaches from Lyssa Adkins

May 7, 2012

We Bring the Post-its – You Do the Learning

"But one is forced to translate thought into action and action into object… …I am not a teacher who tells his students only to think. I say: act; do something: I ask for result. It may take different forms. It can have the form of sound, or someone can do a book, make a drawing or a sculpture. I don’t care…" Joseph Beuys, 1969
A startup begins with an entrepreneur, having an idea and a question: “How to initiate a change in the world, that a growing business evolves around the initial vision?”. There is no single method or best practices which can guarantee success of such a difficult venture, yet there are several thinking tools which may be helpful when bringing a startup to live. Among others I believe these three are particularly useful for a startup venture: 
  • Design Thinking to understand the user's needs and explore potential solutions
  • Scrum to develop shippable chunks of product in a disciplined and collaborative way and
  • Lean Startup to systematically innovate and bootstrap the ecosystem of an enterprise.
Reading books and blogs to understand these frameworks is essential, though getting the concepts right is comparatively easy in contrast to applying them solving real world problems, which can only be learned by practicing. It takes a few minutes to explain the ingredients of Scrum, doing it just fairly well requires weeks, if not months of continuous practice and learning from failures. Although games and simulations can't substitute fully first hand experience they are a great alternative to expensive trial and error learning on the job.

Just a few days before the Startup Camp 2012 I met with Ahmet Emre Acar and Stefan Wolpers to think about how we may create such a practical learning experience. Our idea to teach Design Thinking, Scrum and Lean Startup was pretty simple: we create the space, define the rules of a game, bring the post-its and cards while the audience will do the learning. In detail the question of “how might we create a first hand learning experience of Design Thinking, Scrum and Lean Startup, where people can use the frameworks and tools in a failure safe environment of a game but still have the chance to generate insights from realistic situations within a few hours of being together on a workshop?” appeared to be quite challenging.  After an afternoon prototyping we became confident that a role- or card game could probably work and started to design the workshop. We decided to split the sessions into first Design Thinking and second Scrum and Lean Startup and experiment with different formats independently but link them via a joint registration/preparation and a shared vision as well as persona.

Plan of the Game Part II
By designing the event we wanted to make use of the frameworks themselves. The workshop should help entrepreneurs to become more successful and we used our network for a story share-and-capture session to identify common success and failure modes. From that we synthesized first a point of view, consisting of the persona Kai, the CEO who wants a vision become reality. Given that the game’s principle is to gather and share insights by applying elements of the frameworks while moving towards the vision of "a new platform to bring people, ideas & capital together to further innovation and create new startups.“. So the teams would be confronted with questions like finding the right hypothesis to validate, building the minimal viable product for testing the hypothesis, growing an agile organization and last but not least organizing themselves while getting started with a minimum of input from outside.

We were so curious how the frameworks, which are rooted in comparable mindsets, would complement one another when used by groups working practically on the challenge. Our hope was that learning from each other and direct experience by just doing would be much more fun than listening to us talking and presenting slides. Since the time we had to prepare the event was short, we were a little nervous, if our first prototype would provide just enough structure for a collaborative game to evolve was really enough.

Fortunately the workshop attracted an experienced and diverse crowd, were about half of the people had applied some days before for a specific role on the game and thus became already familiar with some concepts doing a warm-up exercise I had send around. During the first part of the workshop the teams played a Design Thinking card game to explore user needs, formulate a point of view including a persona as input for the second part of the session. Then after a short briefing of the game structure and mission: “While building the minimal viable product guided by this vision and growing a lean and agile organization the mission of the game is to generate the maximum of insights for the minimum of bucks” the three groups headed off into their first Sprint in the second session. Each startup-team played on their board on the wall consisting of a Product Backlog, Task Board, Org Chart and Insights. For building the minimal viable product we brought large print-outs of the paper prototyping helper kit. For building the organization we used the free Meddlers game by Jurgen Appelo with the additional roles of CEO and User. Everyone could choose a role before the start, switch and extend the role but teams could also hire more members, e.g. Users, just from the attendees of the conference. To trigger hiring, growing the organization and to add randomly complexity, teams had to throw a dice to add skill constraints to each user story during planning. Only stories that fit the team's skill set were allowed to move into the sprints. Each role had a cost assigned but the budget was unlimited and had to be tracked by the CEO. A tough 20 minute sprint structure kept the whole group moving. The main places to gather insights in the form of neon-orange Post-its were testing with people who had the  role ‘User’ whenever possible and Retrospectives during the Sprints. 

One of our main goals was to convey the experience when self organized teams evolve from individuals working together and how timeboxing helps to establish a cadence for groups moving forward under high uncertainty, which actually worked really well on this event. It had helped surely that we involved participants before the workshop by asking them to work on a warm-up challenge. Nevertheless I believe the atmosphere of the conference and kind of people who joined our workshop contributed a lot to the success of the experiment. The teams generated some great insights and thus proved our assumption that most learning will just happen, when people reflect what they experience together and share their knowledge. 

From feedback we have learned that the two sessions need to be more integrated, especially the teams should be kept stable to make the most out of interleaving Design Thinking, Scrum and Lean Startup. The Sprints were too short and we should plan more time for debriefing. We also should plan time for a dry run at the start. We need a better map that explains the game. We need to find a way how to make the diverse roles more realistic and encourage growing an agile organization which actually didn’t work so well. We need to add more challenges from Lean Startup, even though at least one team managed to collect insights from showing product to users within the short time they had. The others actually experienced by failing to do so a common pattern of optimizing product development but failing to spin the whole feedback loop. And it was much fun to see the CEOs pitching their vision to people outside the workshop for ‘hiring’ more users for their team and struggling to keep in touch with their product development. 

The Startup Camp 2012 was a great space to have a shot at the methodologies in a startup like context and to gather at least some valuable practical insights on how it feels to use these tools and why they may be useful. What struck me most was how quick the groups developed an individual style working together for such a short time. The bottom line is that trusting the audience and having a real minimum of structure felt right for this event. For us it was the ideal environment to test our first prototype of the learning game, which we will continue to develop further using the thinking tools themselves. Thanx for everyone, who was taking part in this experiment!

January 8, 2012

Empower the Product Owner

"Let's empower the product owner role fully!  If the product owner is the one ultimately responsible for the results of the product in the marketplace, then they are the "source and decision-maker" for things like budget, scope, approach, market/product timing.  These were things PMs respresented before but PMs were always just "middle men."  With agile, we put that work where it naturally occurs  –  with the PO.  So, when we're thinking of the "PM stuff" that Scrum does not prescribe, think of the role of PO  (plus, the role of the trash bin, because that's also where some "PM stuff" goes)."  Lyssa Adkins, Post in Lyra Mentor Group 2011
Planning an agile team structure is fun - redistributing the power as a result of introducing Scrum within an organisation is a delicate topic. Getting real with implementing the roles is where the hard work starts including the discussion about empowerment. How far can a product owner and thus a Scrum team go, where is the limit of their empowerment? How much do the managers trust their freshly born product owners and what responsibilities will they delegate to them and to which level? The product owner role links the agile organization with the rest of the company (world) which may be less or not agile at all. Thus the answers to these questions highly depend on the context's level of agility and may not be black and white but grey  –  and may evolve over time. 

Jurgen Appelo provides a simple yet powerful game called Delegation Poker to shed light on this grey area and foster an open discussion about the delicate issue of empowerment. The result of using this tool is an authority board which defines the level of freedom for Scrum teams and visualizes the walls within self organization may happen. Here is what I have learned using the tool with managers and product owners within an agile transformation. I plan two or even three iterationstimeboxed to 60120 minuteswith different focus depending on the size of the group and level of agreement about the management style within the group. One first dry run helps to get a clear picture of how the group wants to work together, an understanding of the work to be delegated and of the meaning of the delegation levels. It's also fun to use the winning element in this round so everyone tries to understand what delegation level may be best suited for the whole group. Another question that should be raised during the first round is how he delegation level will be implemented thus questions like 'uups agreement sounds so nicewe all want to be very polite right?but isn't that a hell of work if we have to discuss about every user story in detail?'. 

The second round focuses on getting real with the responsibilities and their delegation level thus requires that everyone in the group understands the work of the product owner. A simple diagram mapping the flow from an idea to product increment helps to identify the most interesting spots for discussing the delegation level. 

It's essential to make clear how to deal with multiple hierarchy levels, e.g. CTO, product owner and direct line manager of the product owners. A simple diagram will do the job to clarify which hierarchy level is represented at the poker table. The full chain of power delegation being present in the game is necessary for coming up with binding results. Surprising differences between middle and higher management may surface during the game and result in insightful discussions about leadership style. Nevertheless the resulting authority board is most useful when the product owners (or any other group it is designed for) can take it and look up their level of freedom thus the discussion should be focused on the delegatees and not so much on the different viewpoints of the managers who delegate. 

The expected timeframe the authority board is supposed to be valid or will be revisited again should be made clear in advance: is the group discussing about the status quo or crafting a vision for the future or just the next step which includes a small challenge. I prefer not to use the winning mode oft he game when creating the final authority board and to have rather a discussion about deviations like in planning poker instead of truncating the highest delegation levels with the minority rule.

Delegation poker is fun to play, yields a common understanding of the responsibilities and makes the new level of freedom transparent for the Scrum teams when turning the organisation upside down during an agile transition. 

With the authority board in place the group has a starting point for implementing and re-adjusting empowerment when needed. And last but not least betting in a group together on the delicate issue of empowerment helps building the interlocking roles of product owner and agile manager.