It was the time teams had been using Agile methodologies for some time. Some teams used Scrum, others Kanban. At that point there was going on a huge transformation towards Enterprise Agile. One of the main concepts was Epic based development. That basically meant that Epics (you can think those as big user stories or projects) where created to describe the customer value regardless of the organization or product limits. So the idea was excellent, to be able to exploit the software and product assets of Nokia for customer benefit, what ever needed.
Story of Epic and 113 people
So I got appointed to be the Epic Owner for one of the first Epics trying this new process out. Epic as such wasn't my idea and the contents of it are irrelevant for this blog post. In short basic idea of the Epic was to combine Entertainment and new social technologies. So it was a perfect example for the Epic thinking. It used existing SW assets, needed bit of code on top those and would create a new kind of value to the customers and new business to Nokia.
There was a small team gathered around this Epic. I can't recall exactly, but I think there was 5 of us in a team. My role was to work similarly as product owner to keep the vision of the Epic in place and make sure our team could actually accomplish the thing.
After the start, first things was to get to see the codes, API documentation and stuff like that from different SW teams. Those would help us creating the solution we were after. That already needed lot of internal selling. I flew around and had quite many online and face to face meetings to convince the involved teams to let us work with their code.
After we had everything in place to start, we were able in less than two weeks to have a well working prototype about the solution. It wasn't in the sales quality, but good enough quality to show around. At that time we started to do more internal selling to be able to actually make the final solution, which wasn't that complicated in the end. That was the point we hit the big organizational wall.
There was tens of people who wanted to have their say what was needed to take in to account before releasing the solution out. Some of the people had valid points, since releasing to basically all the countries in the world was not that easy. And all the others were still doing the job they were hired to do. It was exhausting. We had a solution, but getting it out from the company was near to impossible.
One evening I was flying home from one the internal selling sessions, when I started to count that how many people who haven't contributed anything to code I have had to agree with. The number raised to 113 people! There had been 113 people who I had to talk with, in order to get a solution that took 4 developers less than 2 weeks to prototype, to get approved and released.
It's not an extreme case
Some of you might think this is extreme example of how things can go wrong. I'm sorry to say that's not. I've seen some other product development companies to have this problem too. In many cases creating the software isn't the hard part in creating the solutions. It's all the internal sales that need to happen on top of the solution. There needs to be, even in smaller organizations, tens of people who needs to approve the plan before something can actually happen.
There's a good intention of course behind all of this control. People often mean well. They have their own view to things and they want to control that something that is under their radar get thought properly. But that is exactly the problem, companies shouldn't be build on control, but on trust. But that's a different story.
More and more organizations have extensive SW or Product Portfolio. One of the things I hear discussed in many companies is, how to leverage the existing assets better to create new kind of business in the future. This definitely makes sense, it at least these kind of solutions could and should bring competitive advantage and to be even lot cheaper to create.
Unfortunately organizations rarely are ready for this. For example internal cash flows (meaning budgets) can make cross team work harder or even impossible. Also layer of product managers looking after their own products is a common show stopper for these cross product exercises. But there are lot of other hurdles in the way and this post's purpose wasn't to go in to too many details about that one.
Overall the problem is common. Big organizations should have all the assets to compete against the smaller ones, but most often the only way to compete it to acquire the small ones. For many reasons, big companies can't create innovative product easily. My example is just one from many different barriers.
Final Words
As a final words I have to say Symbian organization in Nokia was at the time really advanced in Scaling Agile to Enterprise level. There was lot of good practices in place and lot of competent people driving those forward. In order for the Epic thinking to actually work, it would have needed years of cultural change. This change was started, but as all of us know, Symbian was left burning and change never got to the end.
Written by +Henri Hämäläinen
