Nokia Demise: More Proof that Agile and Scrum Are Merely Tools, NOT Solutions

Well as many of already pointed out, Agile is not product roadmap development strategy but rather an product technology development tool . If Symbian or Nokia did not see smartphones coming, blame it on the product managers at Nokia - who are supposed to trend the markets and come up with innovative ideas. Most of scrum/agile implementation steps come sometime later during the execution phase and that is where its maximum utility is as a development/collaboration tool.

On all the scrum/lean seminars I have gone to I have never heard it to be presented as a solution rather best practises that will improve your way of working. I tought the phrase silver bullet was forbidden in these groups ;-)

"Second, more important, it was one small part of Nokia, Nokia Networks if I'm not mistaken, that did Scrum" Yes, you are mistaken. Scrum is all over Symbian software development. Thousands of Symbian developers were trained into agile. Craig Larman conveniently "forgets" that he was involved in agile adoption also on the mobile phone side of Nokia. Agile is bigger player on mobile side than networks side in Nokia. And yes, the agile advocates at Nokia claimed that it is the panacea and Scrum is the only thing you need and you must use it "out-of-box". When Nokia started to move into agile, my reaction was: "This ain't gonna end happily".

As an ex- Nokia Siemens Networks scrum master, I have the deep conviction that "Nokia style" scrum really speeded up the development. @ Nokia, the problems happened at a different level, Business and strategy. Symbian was the best mobile OS for a long time. Just wasn't smartphone material. Too many products, one single OS, poor after sales, no tribal culture...

... that's what I also wonder. And Brad, you should really answer it (Um, Who says Scrum automatically saves organizations?) to vindicate your claim that "Scrum community continues to promote the bankrupt idea that managing and building software oriented products and services will automatically be somehow “saved” or “revolutionized” by fostering the adoption of Scrum across both core development teams as well as the rest of the organization".

This has probably already been said but I didn't want to read all the replys. To draw the conclusion that a large company going through a disaster has as its center a failure of Agile, is to take quite a leap - at least based on the information (or lack thereof) provided in the article. Agile projects and programs can surely fail, actually they fail much faster when the environment it lives in is dysfunctional. It's SUPPOSED to work that way. The faster we know something isn't working, the better, then we get to make better decisions about how to move forward. If the people running those doomed to fail ideas don't quit when Agile made it clear that they should, it certainly can't be attributed to the framework. The blame probably can't be placed on Agile directly, but on the lack of commitment to dealing with transparency and on a lack of foresight. Of course Agile can be done wrongly too, which it often is. And again, that would be the fault of the people, not the approach done rightly. Is this somehow different than using any other approach to software delivery and not supporting it like it requires? It does remind us that we need to be careful to not become Agile zealots in the process of believing in it. I think this comes from people sometimes focusing on the process rather than the collaboration it engenders. We should believe in being agile, not in selling a process. We must remember that Agile doesn't really solve problems, it only gets most of the heavy stuff out of the way so that actual people with thinking brains can solve the problems. Whether you call Agile a tool or not, it's not a substitute for using our brains and doing the hard work necessary for success.

which the case for most of us on any given day. I think that whoever pushes agile as a silver bullet is sadky mistaken and worst, completely misinformed about it. If you point it out to us, we will gladly police this misinformation, it should not be out there. I think you hit the nail right on in your last comment (no, I did not get a chance to read them all, though): it takes work and effort to make agile work, and it above all it takes konwledge of the specific company culture and situation. Without doing that, it would irresponsible to roll out any kind of change, regardless of its potential benefit. There are virtues in adopting agile principles, but there are a lot of down sides to it as well. Doing it right takes effort and dedication on all sides, and in some cases the answer is NOT to do it in the first place. You are right: agile frameworks are not a panacea or a "solution" (reminds me of the ERP silver bullet approach before). It is sad that there are people pushing that idea. You are wrong: Nokia scrum implementation failure is not a reflection on the agile community. It is a reminder that business still drives decision making. Thanks for the post.

Common sense

I have no interest in Nokia or NSN and whether (whatever they were calling) Scrum helped or hindered them. But I want to make the point that Scrum is NOT a tool. Scrum is a principle-based framework, a challenge to the status quo of the business world. Scrum represents a mindshift away from a hierarchical, controlling, blame-and-fear-driven way of working. It embraces (in Daniel Pink's words) "autonomy, mastery and purpose". Until people get that, until they stop looking for silver bullet solutions, and thinking a check list will fix their massively dysfunctional organization then "Scrum" will always fail. And rightly so. Despite all the protestations towards this article, and despite its inaccuracies I applaud it. The more we can expose "quick-fix" Scrum for the nonsense it is, the quicker we can actually start working in a truly different way. And maybe dispense with all the buzz words.

"C) No obvious way to make progress Unlike other disciplines, such as medicine, there is very little reporting of failures or limitations in the software community in general and ours too, and there is no clear venue or even templates or examplars of such reporting." There are instances in the medical and pharmaceutical industries where commercial interests have overridden good practice, however your point is well made. I would look to the way the aviation industry investigates accidents and incidents as a model for increasing our ability to learn from our mistakes. Whether a 2-seat Cessna 150 crashes or an Airbus A380 with hundreds on board makes an emergency landing after an uncontained engine failure, the country's transportation safety board investigates and determines as best as possible the root causes for the problem. In the software industry, we only seem to do this when lawyers become involved.

If the leadership doesn't value the basis of a lean software development, this is bound to happen. And I can bet Nokia leaders weren't - and how ever you try with any kind of process, you cannot fill that gap. They are bound to fail.

But not Agile. Traditional models inspired processes, like the one followed by IBM, have delivered products and are still humming. Agile, Scrum are of course no solutions, merely a thought process which best can be overlaid over existing models. Also they are the new age gadgets for consultants and institutional study.

Bas and Craig, Mea culpa. Your are 1,000 percent correct. NSN is the origin of “the Nokia Test”, and anyone familiar with the work Bas and Craig have been doing at NSN should know that, shame on me. While the Nokia Test wasn’t invented at Nokia, I have many clients in Telco and colleagues who formerly worked at Nokia that attest to the use of the “Nokia Test” even at Nokia, even though you’re quite right it was not invented there. I will post a new blog to highlight the nerve this has raised and steer the debate the direction I had intended.

Nokia's loss of leadership deserves careful root cause analysis. However, the "well known" Nokia that invested in Scrum and Agile is Nokia Siemens Networks (NSN) - not Nokia Equipment. So, the conclusion in your blog's title appears potentially mistaken. I do agree with many others who have commented here that the failure of Nokia may be due more to a loss of understanding of their market than a choice of product development method, and that methods are not panaceas or silver bullets. On the weekend of the 10th anniversary of the agile manifesto, I'm completely in agreement with Naresh... "People and Interactions OVER Process and Tools". Undoubtedly, the hype over Agile and what it can do for a company is over-stated - and perhaps a number of us in this thread can do our part to share the blame! ;>) Both the change in Nokia's position and the rise and fall of agile methods should not be too surprising - they're just paradigm shifts!

Two concerns: First, who really says Scrum does this magic? Quote them and I'll help you go after them. So would the Scrum community, I suspect. I think no one says that, and that pushing that myth does a disservice. Second, more important, it was one small part of Nokia, Nokia Networks if I'm not mistaken, that did Scrum. Even a Scrum fanatic would not suggest that Scrum will save a company that doesn't do Scrum! Your point that Scrum is not a panacea is of course well taken. It's just your unsupported assertion that the Scrum community says otherwise, and your flawed counter-example that weaken your article. Thanks,

brad, hi. this blog post is based on a widespread misunderstanding, and so is not correct -- this is not your fault ;) i'm an ultimate insider on this story, along with bas vodde, my co-author of our large-scale agile/scrum books and the person who internally led the agile and scrum adoption at nokia-siemens networks or NSN -- and he's a key creator of the "nokia test." other key leaders/creators in this (members of the NSN agile/scrum coaching group at NSN), and our close colleagues and friends, were kati vilkki and petri haapio. we've both tried to correct a widespread misunderstanding that you unknowingly repeat and reinforce in this post. bas and i were the people who first introduced scrum and agile principles at NSN years ago, we've spent years in finland and other NSN sites, and we started to share this very large-scale adoption with the agile community. then, various people who heard our story (such as jeff sutherland and ken schwaber) *incorrectly* shortened the name "nokia networks" or "nokia siemens networks" ("nokia networks" and "siemens networks" merged some years ago to form NSN) to "nokia" and *wrongly* said that "nokia was adopting large-scale agile and scrum", based on bas's, mine, kati's, and petri's reports to them and others (i think they did not grasp that these are very different companies, only with a common parent holding company, "nokia group"). but -- key point -- nokia (nokia corp devices -- the company in the news now) is NOT nokia-siemens networks. we've even mentioned that a few times to some of the people that promulgated the wrong story, but they didn't correct their reports. so, most everything you've heard about nokia and scrum is not correct. the only ones who can explain the "nokia story" are the NSN agile coaching team (and me, their main outside collaborator) so to be crystal clear: nokia (actually, "nokia corp" or "nokia devices") -- the company in the news -- is a completely separate company from NSN, and nokia devices did *not* adopt scrum. nokia devices makes mobile phones and the symbian and S60 platform. they were NOT the "nokia" adopters of scrum that you all heard so much about. rather, it was NSN. NSN creates telecomm infrastructure equipment (radio towers, network elements, LTE, etc). bas and i, and an internal agile team set up at NSN, introduced large-scale scrum there starting in 2005 and *this* is the "nokia" adoption that people have heard about. as an aside: because nokia devices (the mobile phone and S60/symbian platform company) and NSN are headquartered in the same city (helsinki), i was once (2007?) invited to speak with the leadership team at nokia devices on a real scrum (self-managing cross-functional cross-component teams, PSPI each sprint, etc) adoption. however, it became clear to me that they (e.g., in S60) were fixed/rigid and the managers did not want to give up their existing org structure or "management control," and would not really change their org design to real scrum, and i didn't continue to work with them. my co-author bas vodde and kati and petri were the creators of the "nokia test". this test was not created or used at nokia devices; it was for NSN, and then mistakenly attributed to nokia devices. AFAIK, nokia devices doesn't even know about this test; nokia devices people certainly didn't know about the "nokia test" when i visited them; it was only used in NSN for some guidance, and only a couple of times informally in perhaps 2007. then it entered urban-myth land (via jeff and some others) in the public space, and people (as in this blog) have completely got the wrong story. AFAIK (heard this from some experienced real-scrum coaches in finland) nokia devices eventually started (once crisis-time was starting to become more clear to them a few years ago) a "fake agile" adoption that was similar to their prior org design, continuing with component teams, project and program managers, hand-off between single-specialist teams, etc, but now the old project managers were called "scrummasters," their old task lists were now called "product backlogs" (and every component team had their own "product backlog"!), and they had "sprints" in which component teams of programmers produced chunks of WIP code, their existing upstream requirement groups writing docs for the "design teams" was now called doing "agile requirements", and their existing downstream integration and testing teams was now called doing "agile testing", the old program managers were trying to direct all this in their traditional ways, and more. this is *very* far away from real scrum, as perhaps you understand. i think i heard the dean leffingwell introduced some iterative practices there, based on continuing with component teams and a release train and handoff between specialist groups, but of course that is not scrum. on the blog point that scrum is a tool and isn't a solution, yes of course true. test-driven development and continuous integration are also just tools. there is no necessary relationship between TDD, CI, or scrum and success/failure -- pretty obvious. but at the very least, when evaluating the efficacy of a tool or org design, it should at least be really applied before any conclusions are drawn. it would be uninsightful to *not* apply real TDD, then incorrectly say "TDD was applied" and then conclude "TDD is not a guarantee of success." similarly, several groups that i've seen have some kind of "fake scrum" adoption in which names/labels have been changed but the real scrum principles have not been introduced (self-managing cross-functional real teams with no handoff, that delivery PSPI each sprint, with all teams directed by a product owner who owns the product). no conclusion about scrum can be drawn in these fake cases. also, naturally, product success is a result of more complex forces and factors than just enabling agility, transparency, inspecting, and adapting with scrum -- having a good product vision and not being wedded to the past are useful. nokia devices, who never adopted anything close to scrum, was led by managers more invested in the past than the future. -craig

Missing from this analysis - and most other similar analyses - is any mention of the actual technology. No process or methodology can turn an inferior software platform into a superior one. Analyses like this are part of a larger trend I've noticed. There is an emphasis on process and discipline with an accompanying de-emphasis on what actually makes tech companies great - technology and the technologists who make it.

A provocative and interesting post. I worked for a year at Nokia before shifting to a start-up who culturally embraced agile more (although followed the letter of the law a bit less). Without overly dwelling on my 1 year experience @ Nokia (which was generally quite positive), wanted to share a post summarizing thoughts about the Scrum process through the prism you mention. The first quote crystallizes my basic thought: scrum is a practice and “...any technique, however worthy and desirable, becomes a disease when the mind is obsessed with it.” – Bruce Lee :) http://tomwang.tumblr.com/post/3069649551/scrum-at-formspring

I'm not commenting on the premise that Scrum isn't the solution to all problems. But the reasoning is seriously flawed as the author forgot to bother to check the history. What is called "The Nokia Test" has been created in a company called "NSN or Nokia Siemens Networks". This company is a different company from Nokia. The company in the news is Nokia and not NSN--the company where the Nokia Test was created. (and the Nokia Test wasn't created and promoted inside the company. People in both NSN and Nokia are surprised by the name as it was only used by a very small group of coaches) It would have been nice if you checked out the history before starting this rant :) (and I'm not commenting or arguing about your point about Scrum)

If a company spends more time on process, they won't have time to focus on their product and will soon have to bite dust (Another One Bites the Dust...And another one gone...And another one gone). How ironical, the whole point of Agile was "People and Interactions OVER Process and Tools". If you look around there are many companies falling into the process trap. Hoping process will save the company. Alas.

That is in interesting article. And also, expected. I think the general consensus has been that Nokia has been "inefficient" in responding to the threats from "Smart Phones". I think the general business direction [Strategy/ Product Management] is more to be blamed here. And I say it as someone who has spent last few years as a Product Manager. I'd have blamed Scrum if: 1. The software was buggy [which it could be - I don't know if it was]. 2. The software was not released often enough [again - I have no clue, but I think it was released often]. Having said all of this and without telling you, how I know this -> Scrum in many parts of Nokia was almost non-existent. Not only that many [and I mean many] people in Nokia were not even aware of The Nokia Test for Scrum. I understand that the article seems to target only people who sell Scrum as a Panacea but the general tone of the article is of "Yeah! Scrum failed" and anyone who talks about Scrum sells it like that. I think both are an exaggeration. What will be interesting however, is to see if Scrum surfaced the obstacles and they were not tackled wherever it was being practiced.

Looks like another one bites the dust. Poor agile understanding indeed.

We must always remember to keep our eyes and ears open and be able to discern betwenn the hype and reality. In the end consensus from the team doing the work ont eh best way to proceed with their work is what should be our guide.

I agree! SCRUM, AGILE, USE CASES, CMMI, WATERFALL, ITERATIVE, GRID, CLOUDS, PEGA, MEGA, ABINTIO and the BROOKLYN BRIDGE, all share one common bond. There is a sucker born every minute. No process or methodology is going to save the day. Especially when you don’t completely follow them, or, start your project with the end date! The secret to success is simple. Know what you want to do, do it, make sure it’s what you wanted, test it, and then double check it’s what you wanted! While you’re at it, fund it, keep it onshore, and let the project team say when it will be done!

This is fairly self evident. SCRUM and Agile are great tools to get the most out of a process. They are absolutely not a replacement for poor product decisions (nor inept engineering). I can't imagine anyone believing that the process alone is a substitute for innovation and raw skill/talent amongst the technical teams. I've seen some companies that try to compensate for good product and engineering talent with process. They never seem to do very well. (which isn't to say that's Nokia's problem.

No glee for me in Nokia's troubles... for years they were my favorite handset maker until they lost their way. The point of my article was to foster healthy discussion about the mistake many make in extolling the virtues of Agile as a way of guaranteeing better outcomes.. Your rash analysis of my POV (that I hate Nokia) and your knee jerk conclusion that Nokia executive management is to blame illustrates the point of my Article. Too many Agile enthusiasts blindly apply Agile as a solution without first taking time to understand the context or problem. Thank you.

It should be understood that ANY methodology (Agile, Waterfall, etc) is simply a tool and not a solution. Apparently, whatever happened to Nokia could have happened no matter WHAT methodology was used, so why seem so gleeful that what was used unsuccessfully was Agile/Scrum? The problem here is more closeley associated to poor executive management.

I haven't actually followed the demise of Nokia. However, I agree that agile and scrum are merely tools. Companies live and dive on the quality of their product visions. Agile and Scrum don't help you have great products. In the smart phone space, Nokia used to be a leader. However, they seem to have lost that position to Apple and Android-based systems from HTC and Motorola. Motorola is actually an interesting counter-point. They certainly seemed to have pulled themselves back into the game with their Droid line of smart phones.