Presentation on theme: "When Agile Fails… Jonathan Rayback Motorola Solutions, Inc."— Presentation transcript:
When Agile Fails… Jonathan Rayback Motorola Solutions, Inc.
Credit where credit is due… Mike Brown blog entry at Utest: “Why Agile Fails, Sometimes…” …piqued my interest in the topic. Brown’s article provides the outline and much of the material for my presentation today.
Hasn’t Agile Won? No waterfall conferences, no RUP conferences… IBM, Microsoft even SAP using Agile… Agile seems to becoming the industry norm… [Insert quote about Agile winning here]
“Agile consultants ruined the software group I work in. Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.” – Anonymous Agile Victim
“This system is bloated with meetings, excel spreadsheets and anemic of any real documentation. Agile and the people who support it are full of themselves and their aversion to documentation is detrimental to real active communication. The disinterest to documentation presumes humans will retain meeting to meeting barrage of verbalized ideas. Agile is full of egotistical self congratulating ideologies over used buzz words like “flexible” and “living”. People can’t remember what they said from one over stated meeting to another.” – Anonymous Agile Victim
World’s Biggest ‘Agile’ Software Project Close to Failure "'Universal Credit' — the plan to consolidate all Britain's welfare payments into one — is the world's biggest 'agile' software development project. It is now close to collapse, the British government admitted yesterday…” May 25, 2013 – Slashdot.org
Voke Survey Voke survey of 200 companies that had recently transitioned to Agile: 64% said it was harder than it initially seemed 40% said they could identify no obvious benefit to the change Of the 60% that saw benefit: Only 14% felt it resulted in faster releases 13% thought it created more feedback “While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems.” – Theresa Lanowitz, lead analyst at Voke
So What to Do? Remember “old habits die hard” Avoid unrealistic expectations Understand the pitfalls of department fragmentation Don’t give up too easily
Old Habits Die Hard “I don’t think most people need convincing about agile principles, even if they’re just attracted to the idea of frequent delivery. In practice, however, a lot of waterfall behaviors survive by hiding behind the new agile jargon. If we want different results, it’s not enough to change our jargon, we have to actually change the way we collaborate!” – Nate Oster, founder of CodeSquads LLC. Be aware of “local optimizations” in your current process that personnel might be loathe to relinquish. Don’t just “go Agile” if your company is already performing satisfactorily. Agile principles can be adopted to help you “get to the next level”. Brutal honesty is crucial for your success. Why are you adopting Agile? Is your organization truly committed to fundamental change?
Avoid Unrealistic Expectations Take the time to understand the Agile principles you are considering and how they fit into your business context. ◦ How big are your teams? ◦ How geographically isolated are they? ◦ How bureaucratic is your company? ◦ What type of software do you build? If you expect that Agile to perform miracles and instantly transform your software development process you will be disappointed. Schwaber has always maintained that the first thing that happens when companies adopt Scrum is that all their organizational dysfunctions come immediately to light. ◦ A wise executive will have the perspective to help his organization thrive through the transition.
Pitfalls of Department Fragmentation What happens when only the developers are “Agile”? Just having Agile teams does not make an organization Agile… Agile needs to be allowed to transform the institution. The full delivery capability needs to be in: ◦ Product Managers ◦ Program Managers ◦ Business Analysts ◦ Developers ◦ Testers ◦ Documentation Writers This is a very common source of frustration for Agilists within an organization: Impedance across organizational boundaries that make true Agility impossible. Can your HR culture support a model where people regular perform responsibilities not implied by the title on their business card?
Don’t Give Up! “When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls ‘fake agile’.” – Mike Brown, UTest.
Beware of “Fake Agile” Don’t hire the “Agile Coach” with only a 2-day CSM certification under his/her belt. Agile isn’t a remapping of a traditional process: ◦ Iteration ≠ Phase ◦ Scrum Master ≠ PM ◦ Stories ≠ Requirements ◦ Points ≠ Estimated Hours ◦ Standup ≠ Status Meeting
“To the people who are victims of Fake Agile, I extend my deepest sympathies. “Agile” ruined your life only in that it provided an all-too-glib buzzword for your organization and management to latch onto. I dearly hope that you’re able to experience real Agile: frequent delivery of value at a sustainable pace while adapting to the changing needs of the business.” – Elisabeth Hendrickson, Test Obsessed
“But there are implications. There’s no such thing as a free lunch! And there’s no magic bullet for software development. Sorry, no, you can’t just drink the cool aid :-) In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can’t blame someone else if things don’t go right, and it generally requires much more commitment and effort from everyone involved – i.e. teamwork is even more important.” – Kelly Waters, All About Agile