Are you starting or expanding an Agile rollout? Already experiencing or expecting trouble?
Applying Agile is like driving.
Adopting Agile is like buying your first car: you only do it once.
Read up on it, kick the tires, ask your questions — and go with someone who understands about buying cars.
From: Gil Broza and Johanna Rothman
Toronto and Boston
Dear colleague,
Chances are you drive on a daily basis. Whether you enjoy it or not, you've mastered driving. Remember learning to drive? It took a lot of practice and patience, and after a few road-hours you'd learned enough to drive on your own.
Remember buying your first car? Your driving ability didn't help. All of a sudden you had to deal with matters of reliability, market value, insurance, mileage, etc. Did you have a parent or a trusted friend go with you to buy that first car? How did that boost your confidence? (And wasn't it nice that once you'd bought your car, you could actually forget about those matters?)
An Agile transformation is the same experience: You only do it once.
Dozens of organizations have engaged us as that trusted friend in order to avoid an Agile Lemon. We've worked across so many contexts, we're now masters of buying that first Agile car.
Agile Adoption is a BIG DEAL
Let's be blunt: Agile adoption hurts at the beginning. It's strange and unfamiliar and the traps are plenty. Agile changes the dynamics and the experience for everybody, not just a few developers and testers.
Unfortunately, many Agile adoptions are not totally successful or even mediocre. Many of them are backwards. Organizations draw little if any benefit, and good people get hurt.
We know this: There are a few dozen known risks with known mitigation strategies. If you master those, at least you'll be able to avoid outright failure or mediocrity. You will end up doing better than before.
So, what are we offering? If you can't hire us (like those other companies), we have a self-study course for you to teach yourself how to prevent adoption disaster and mediocrity.
The trouble
See, Agile is still new. No matter how established, certified or documented in books it might appear to be, the particular package of principles that comprise Agile Software Development is barely a decade old — and undergoing massive experimentation world-wide.
And so, many people jump in, and they know that they are missing some things. They need to get on top of certain skills, tools, processes, and techniques, so they go learn them. They take courses, read books, and our newsletters :-).
But, they don't know what they don't know. Unless they invest the time to research and learn everything about this newfangled methodology, which sounds sensible but is devilishly difficult, they can't always tell the effects of their decisions.
For example
What if most of your stories aren't “done” by the end of their scheduled iterations (sprints)? Some teams would notice that and say, “Hey, that's not how Agile works.” This might be met with, “Who cares, we're not purists!” or “Next time, let's make sure we really get to done!” or more commonly, “So what? Let's just roll these loose ends into the next sprint.” Few people realize that none of these responses actually addresses the real problem, and that several iterations of that typically spell mediocrity.
What if despite using iterations, features are still developed big-bang style? Again, some folks would notice this and say, “Hmm, that's a mini-Waterfall.” Many teams truly can't see how to build features in small steps. But combine the mini-Waterfall approach with what otherwise passes for Agile, and you'll get uneven workloads (remember overtime?), impatient management, and teams that don't self-organize. After several months of that, the iteration ceremonies become optional. Several more months, and you have a Waterfall process without artifacts.
What if you need more time from your product owner or customer than you're actually getting (and you keep getting less and less)? This common situation is often resolved by having the ScrumMaster or a manager sub for the PO. That might work if the PO has merely gone on vacation, but guess what? Six months from now senior management will come knocking and ask, what were you drinking when you built this application? Only programmers can use it!
And on it goes. The team wants to expand the timebox because they just can't get everything done in time. You need an infrastructure or design iteration, or two or three. Occasionally, people don't show up to the standup meeting because they don't see the point or don't have the time. Story/epic estimates are way off, and task estimates are useless, no matter how you try to improve.
(Speaking of which, if your team has been Agile for six months and still can't feed useful estimates to higher-level portfolio/program planning, this stops being their trouble. How long before senior management swoops in and says, enough is enough, we want to see exact estimates on everything? Both of us are helping clients in this situation right now — and just to be clear, it's not about learning to estimate better.)
We might diagnose these symptoms as Agile Adoption disaster-in-progress, mediocrity, or ain't-gonna-scale.
When Agile adoption is a disaster, you can see at least one of the following failures:
- Process failure, where the mechanisms by which the team and the organization work to deliver the project are not effective. They sprint in place, so to speak.
- Team failure, when the team doesn't behave or interact sufficiently well to deliver the project. In some teams, people stop talking to each other, or wait for their managers to tell them what to do.
- Project failure, when the project doesn't deliver business value to the right people when they need it. This is usually related to project scope, time, cost, and quality.
Even when you avert outright disaster, it's really hard not to end up with a mediocre implementation of Agile. Enough people have told us, “We don't know why Agile isn't working for us as promised.” The danger there is that mediocre transitions usually result in a bounce-back to the old, “safe”, familiar way.
The third situation is when you have a great Agile implementation for one or two teams — and now you can't figure out how to scale it! Maybe you have a large program on the horizon, where you need six or seven teams to use Agile. What works for one team rarely works for several.
You can hear us pinpoint common Agile Adoption trouble, and how we would set up a successful pilot, in this class, which is an introduction to the program we mention below.
 |
|||||
|
|||||
 |
|
|||||
|
|||||
|
These problems are incredibly common.
You are not alone. The Scrum Alliance leadership has estimated that 75%(!) of organizations using Scrum won't succeed in getting the benefits that they hope for.
(In fact, we have compiled an Agile Troubleshooting Guide, which includes 80(!) symptoms of disaster, mediocrity, or not-scaling. The description you read above only has six.)
How are you feeling about these numbers? Well, we don't like them at all. And we know that one explanation for the numbers is that not enough companies invest in their people by getting expert help. So if engaging an Agile specialist is not in the cards for you, we have the next best thing:
“Immunize Your Projects Against Agile Failure”
This program has everything you need to know and do in order to make sure your Agile projects don't get sick.
In your own time and at your own pace, learn from two experts who have done it all. We specialize in managing product development, Agile adoption, and high-performing Agility. Instead of just summarizing patterns of adoption, we have packaged our best diagnostics, tools and strategies to help you see where things are going wrong, and what to do about them.
You will learn how to...
1. Prevent Process Failure- Learn the five most common ways an Agile process fails
- Learn to spot the evidence of each
- Understand the strategies and tactics to address each kind of failure
- Which aspects of the process you should customize and which you must not
- Four characteristics of team failure and how to solve them
- Crafting team working agreements that actually work
- Necessary conditions and strategies for team success
- Seven common areas of project failure and what to do about them
- What's really critical and what you must do for every project you start
- How to create those critical early wins
- Five characteristics of your pilot agile project
- What to do if your project is already selected and doesn’t fit those criteria
- How to select the team for your pilot project
- What to do if your team is already selected and they don’t meet the criteria
- How to transform the group into a team
- Misconceptions about Agile that lead to mediocrity — and the truth
- Various Anti-patterns that lead to mediocrity — and what the right patterns are
- What you should do for the process, team and project now to avoid the bounce-back
- Meet our useful diagnostic tools and learn from examples
- Learn process, system and team techniques
- Understand the critical skills that managers and leaders need to identify and troubleshoot issues
- Engage people who don’t play the obvious parts in a team, including architects and managers
- How to pick your battles—and when not to bother
- Be able to recognize and deal with the simple matter of being human
- Make your Agile implementation more inclusive and reach farther
- Create active management participation
- Roll out to programs and to more teams
|
|||||
|
|||||
|
How is this program structured?
This program is structured as a self-study course, made up of seven recorded public one-hour classes. Each class is provided as an mp3 recording + a transcript. In each class you'll learn the underpinnings and consequences of problems you encounter. You'll chew on possible resolutions and strategies, and see how to apply them in your projects in order to immunize them against Agile failure and scale your success.
This program requires no travel or time away from the office. Unlike a conference or a webinar, its resources stay with you for as long as you need them. And it's highly affordable even if you had to pay for it out of pocket.
Like it and want to cut to the chase? Go here to buy.
|
|||||
|
|||||
|
Your Bonuses
While this program alone is well worth the investment, we'd like to give you two awesome bonuses for making this commitment to yourself.
Bonus One: A copy of the ground-breaking Agile Troubleshooting Guide
The Agile Troubleshooting Guide is your quickest way to stop small problems from becoming big problems.
Keep a copy handy (in paper or on your desktop), and take it to your retrospectives too. Consult this guide any time you observe something — a management decision, a team experiment, a behaviour — that makes you nervous. The guide will tell you its possible reasons and what you might do to resolve it.
Extra-special: Even though the Agile Troubleshooting Guide is a stand-alone resource, we've added class and transcript page markers to every symptom and resolution, referring you directly to where we discuss them!
Bonus Two: Gil and Johanna's answers to numerous additional questions that the live-course participants asked outside of these calls. These answers provide clarification, more context, and more what-if's.
Our Real World Guarantee
We're confident that the classes (which you can follow with our study guides) and the easy Troubleshooting Guide will delight you. We also know that if you follow our advice and use our tools, you will see results within days.
To back that up, we'll give you 30 calendar days from the day you purchase to REALLY decide if it's for you. If you decide it's not for you, email us and get a full refund. No questions asked.
Do you need to know a bit more about us?
First off, we're a pair. We pair-developed and we pair-teach these classes. It still amazes us how much better the result is than had we developed it individually.
You get depth: We've both been technical contributors as developers and testers. We've both been managers at various levels. We've both introduced and facilitated change from the technical and management perspectives. In addition, we're both students and teachers of human systems and organizational behaviour (human dynamics). We share more of our background in the introductory class.
We are pragmatic. We're not focused on just one part of the solution and we certainly don't parrot dogma. Between us we have several decades of agile experience. Johanna chaired the Agile 2009 Conference and Gil produced the Agile Coaching stage in 2009 and 2010. Yet, we still know what it's like to be Waterfall...
|
|||||
|
|||||
|
|
|||||
|
|||||
|
Ready To Get Started? Or Do You Still Have A Few Questions?
Q: I am (or my team has) a Certified ScrumMaster. Isn't that enough?
A: It's a great start. And, it's not quite enough to help you see where your problems lie and what to do about them.
Q: Can't I just go to a conference?
A: Please do, and for sure you'll learn a lot about Agile and problem-solving. Can you send everyone to a conference? We suspect not. Will it cover exactly what you need? Probably partially. Our program would cost you about 1/6 the expense of going to a major Agile conference.
Q: Can't I just buy a book?
A: The books can provide you with the “here's how to do it.” But too few books discuss “here are the [numerous] traps you can fall into, and here's how to move past those traps.”
Q: Can I sample this program?
A: You can listen to the first (introductory) class of the seven. We're aware that we spoke a little fast in this class; we slowed down in later classes :-)
Q: How does this differ from the Agile training everybody else is offering?
A: All Agile training out there is about skills and mechanics. It's all the stuff you must absolutely know and do to run Agile properly. Most attendees leave these courses energized and full of hope, but their resultant implementation is not so picture-perfect. It's easy to describe Agile. It's a lot harder to implement it safely and effectively in your context. In this program, you will learn how to reconcile the Agile ideas (and ideals) with your context.
Q: Come on, it's just a process. What's the big deal?
A: We believe that adopting effective Agile is the biggest change your product development group has ever undergone. We've seen lots of organizations stumble and fall back to Waterfall or Chaos. What we've done is condense everything we know about moving from common starting points to proper Agile implementation — the void between present state and a working Agile process.
Q: I don't have time to listen to recorded classes.
A: You have the option of listening to the classes or reading their transcripts; each class is about an hour, and the associated transcript is 16-20 pages long. Or you can listen to the classes opportunistically: If you observe something fishy or difficult in your Agile implementation, look for it in the Agile Troubleshooting Guide (which you receive as a bonus), and then follow the pointers to read just the relevant discussions in the transcripts.
|
For just $495 I understand I'm getting Johanna and Gil's entire Agile Immunization self-study Program, which includes seven classes. Each of the classes has:
The classes were recorded live, and they include highly pertinent questions and answers. A Table of Contents indicates where each of the covered topic appears in its recording and transcript. I also get two bonuses:
|
|||
|
Rest easy – your order will be processed securely by PayPal. You can use any credit card. P.S. We won't send you anything that ends up in a landfill. All the materials are electronic, so you can download them easily to your computer or media player, and print them selectively. Unlike other training opportunities, we won't put this stuff on some fancy CD or print reams of paper to put in a binder that collects dust. |
|||
Still on the fence?
|
|
If you're not quite ready to immunize against Agile failure but would like a “smaller” solution by just purchasing the Agile Troubleshooting Guide, click here.
To your success,
Johanna & Gil
One more thing. For technology companies, this kind of investment is dirt cheap (it's about the same as a one-hour team meeting.) If you have doubts whether yours would authorize the purchase, just point your manager to this page (http://www.ImmunizeAgainstAgileFailure.com/) and express your need. And if you learn that they won't spend even three figures on securing their Agile transition, there's your number one risk. Run!
|
|||||
|
|||||
|
|
|||||
|
|||||
|
Legal Disclaimer: Every effort has been made to accurately represent our course and its potential. The testimonials and examples used are from previous clients relying on our service, not on this particular packaging of it. There is no guarantee that anyone will achieve the same or similar results. Your organization's, team's and individual success depends on your situation, context, motivation, dedication and actual use of the material.
| Rothman Consulting Group, Inc. 38 Bonad Rd. Arlington, MA 02476 USA E-mail: click here |
3P Vantage, Inc. 545 Douglas Ave. Toronto, ON M5M 1H7 Canada E-mail: click here |
© 2010 Rothman Consulting Group, Inc. and 3P Vantage, Inc.