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]:
No comments:
Post a Comment