At recent conferences such as Agile 2009 and SQE's Agile Development Practices conferences in Vegas and Orlando, I've been running into more and more actual decision-makers. This is exciting, because it's one more indicator that Agile is "crossing the chasm" into regular, large-scale corporate use.
These decision-makers usually want to know, "Will this Agile stuff really help, or is it just another process fad?"
I always converse enthusiastically with people interested in "going Agile," but I no longer limit myself to "Agile" methods. Often, I'll avoid even using the term (though I have no plans to change the name of my company just yet...).
I tell them I'm interested in helping teams examine and alter their development processes by identifying bottlenecks, looking for root-causes, finding ways to ease those constraints, and delivering valuable software.
XP practices, Agile management, Lean leadership, and an overall "Theory of Constraints" approach; all these should be in the software-dependent organization's toolbox. What we call "Agile" is a subset that applies to a variety of constraints, but not always to the limiting constraint.
Dramatis Personae
Over the decades, I have picked up techniques to uncover people's key concerns. I can talk until I lose my voice; describe the latest findings, and pause to listen as they come to their own conclusions.
Decision-makers usually have a healthy dose of skepticism towards new (or seemingly new) techniques. They pick things up somewhere between the early adopters and the late adopters. It may even be a corporate survival trait. Skeptics are always fun to talk to.
But then there are the naysayers, who seem to believe their team cannot do anything right without constant oversight and carrot-and-stick incentives. Naysayers will listen, but then they simply reiterate their position, and will try to keep you in the conversation until you concede (whether or not you realized you were in a debate).
I think I know why: These are leaders burned by some past failure, and are avoiding failure by avoiding change. They will try to build a mental model of some new thing (Agile), and then run virtual scenarios in their minds, rather than committing themselves and others to real risk. Unfortunately for them, their mental model cannot be completed through mere conversation.
To them I now say: "Meet The Dragon."
The Boy and the Dragon
There's a story (very old, but I can't find a handy reference, so I'll bring it up-to-date) about a boy who loved dragons. He drew pictures of dragons, wrote poems and stories of dragons, and read books about dragons. He even dressed as a dragon for Hallowe'en, and his Twitter-name had "dragon" in it (there, now the story is updated).
One day a great, wise dragon heard about the boy, and thought that she would delight the boy by visiting him at his home. "Imagine," she thought, "how excited he will be to finally meet a real dragon!"
She appeared one night in his room and began to speak...
The boy saw the dragon in his room and was so terrified, he could neither move nor reply. His eyes were wide, his heart pounded, and he was in such a state of shock that he could not even scream. The terror was so great that he died of fright right there and then!
(Okay, okay, the dragon gives him CPR and he lives. In fact, the dragon, let's call her "Puff,"and the boy--I think his name was "Jackie Paper"--become fast friends. Better? Sheesh! Remember the good old days when children's stories used to be truly scary? ;-)
DM: Dear @AgileCoach, Do Dragons Really Exist?
Yep. There are many successful Agile teams around, actually doing Agile stuff because they want to; because they produce high-quality, high-value software quickly; because they enjoy working in an environment that encourages them to learn and to succeed; and because it seems the most professional way that we know of--so far--to build real software.
I have met many real Agile dragons of all shapes and sizes. I have assisted dozens (perhaps over 100) of transitions, and many of those have adopted Agile far enough to leap beyond mediocrity. I have been a contributing team member (long-term, full-time coach/TDD developer/project manager) on at least four exceptionally successful teams: Small teams, larger teams, applications handling millions of dollars, and one life-critical ("you break it, someone may die") application.
"I'm Not Your Life-Coach, But Since You Asked..."
Do you have a friend who wants to be a great actor, a supreme-court judge, an astronaut? (Not someone simply greedy for fame and fortune, but a sincere, interested, even talented individual.) How many of his friends are supportive, but secretly think he's foolish? Do they encourage him with vaguely positive platitudes, yet privately think he should take that accounting job at his father's firm?
I would tell this person (if asked): "The odds are against you, and you may have to 'settle' for less than a bullseye, but there are indeed famous actors, supreme-court judges, and astronauts in this world. Who is to say you won't be one of them? Seeing is believing, so [quit telling me about your fantasies and] go find one to talk to!"
But assembling an exceptional software team is so much easier. You're not competing for a finite number of roles/seats/launches. There are plenty of problems that software can solve, that it hasn't. You don't have to have only the best programmers. You don't have to have Steve Jobs as the Product Champion and Ken Schwaber as the coach.
I'll give the aspiring actor and the aspiring Agile team the same advice: Identify your weaknesses, work to reduce their impact. Identify your strengths, and leverage them. And don't be discouraged by an apparent lack of progress. You may never get to where you though you wanted to be, but you will be much happier with the results than if you just kept doing what you were doing. You'll "get what you need" (Mick Jagger, of course).
Visit the Dragon's Lair
I think Pivotal Labs in San Francisco will give you a brief tour, and will describe what they're doing. I know that Menlo Innovations in Ann Arbor will give a two-hour tour, and in fact their tours are so popular that they've published a book and posted video on the web for those who cannot make it out to Ann Arbor. Another in the Bay Area, I'm told, is Sarah Allen's Blazing Cloud.
A few Wise Dragons to choose from. At each of these places, you can watch real software being made using Agile management and development techniques.
And rather than falling for the cynical belief that it can never work at your shop, let me bring in my executive coaches, Lean/Theory-of-Constraints experts, and Agile Mentors (me and others), and we'll help you reveal the Wise Dragon lurking within your teams.
You don't have to believe, you just have to get over the shock.
These decision-makers usually want to know, "Will this Agile stuff really help, or is it just another process fad?"
I always converse enthusiastically with people interested in "going Agile," but I no longer limit myself to "Agile" methods. Often, I'll avoid even using the term (though I have no plans to change the name of my company just yet...).
I tell them I'm interested in helping teams examine and alter their development processes by identifying bottlenecks, looking for root-causes, finding ways to ease those constraints, and delivering valuable software.
XP practices, Agile management, Lean leadership, and an overall "Theory of Constraints" approach; all these should be in the software-dependent organization's toolbox. What we call "Agile" is a subset that applies to a variety of constraints, but not always to the limiting constraint.
Dramatis Personae
Over the decades, I have picked up techniques to uncover people's key concerns. I can talk until I lose my voice; describe the latest findings, and pause to listen as they come to their own conclusions.
Decision-makers usually have a healthy dose of skepticism towards new (or seemingly new) techniques. They pick things up somewhere between the early adopters and the late adopters. It may even be a corporate survival trait. Skeptics are always fun to talk to.
But then there are the naysayers, who seem to believe their team cannot do anything right without constant oversight and carrot-and-stick incentives. Naysayers will listen, but then they simply reiterate their position, and will try to keep you in the conversation until you concede (whether or not you realized you were in a debate).
I think I know why: These are leaders burned by some past failure, and are avoiding failure by avoiding change. They will try to build a mental model of some new thing (Agile), and then run virtual scenarios in their minds, rather than committing themselves and others to real risk. Unfortunately for them, their mental model cannot be completed through mere conversation.
To them I now say: "Meet The Dragon."
The Boy and the Dragon
There's a story (very old, but I can't find a handy reference, so I'll bring it up-to-date) about a boy who loved dragons. He drew pictures of dragons, wrote poems and stories of dragons, and read books about dragons. He even dressed as a dragon for Hallowe'en, and his Twitter-name had "dragon" in it (there, now the story is updated).
One day a great, wise dragon heard about the boy, and thought that she would delight the boy by visiting him at his home. "Imagine," she thought, "how excited he will be to finally meet a real dragon!"
She appeared one night in his room and began to speak...
The boy saw the dragon in his room and was so terrified, he could neither move nor reply. His eyes were wide, his heart pounded, and he was in such a state of shock that he could not even scream. The terror was so great that he died of fright right there and then!
(Okay, okay, the dragon gives him CPR and he lives. In fact, the dragon, let's call her "Puff,"and the boy--I think his name was "Jackie Paper"--become fast friends. Better? Sheesh! Remember the good old days when children's stories used to be truly scary? ;-)
DM: Dear @AgileCoach, Do Dragons Really Exist?
Yep. There are many successful Agile teams around, actually doing Agile stuff because they want to; because they produce high-quality, high-value software quickly; because they enjoy working in an environment that encourages them to learn and to succeed; and because it seems the most professional way that we know of--so far--to build real software.
I have met many real Agile dragons of all shapes and sizes. I have assisted dozens (perhaps over 100) of transitions, and many of those have adopted Agile far enough to leap beyond mediocrity. I have been a contributing team member (long-term, full-time coach/TDD developer/project manager) on at least four exceptionally successful teams: Small teams, larger teams, applications handling millions of dollars, and one life-critical ("you break it, someone may die") application.
"I'm Not Your Life-Coach, But Since You Asked..."
Do you have a friend who wants to be a great actor, a supreme-court judge, an astronaut? (Not someone simply greedy for fame and fortune, but a sincere, interested, even talented individual.) How many of his friends are supportive, but secretly think he's foolish? Do they encourage him with vaguely positive platitudes, yet privately think he should take that accounting job at his father's firm?
I would tell this person (if asked): "The odds are against you, and you may have to 'settle' for less than a bullseye, but there are indeed famous actors, supreme-court judges, and astronauts in this world. Who is to say you won't be one of them? Seeing is believing, so [quit telling me about your fantasies and] go find one to talk to!"
But assembling an exceptional software team is so much easier. You're not competing for a finite number of roles/seats/launches. There are plenty of problems that software can solve, that it hasn't. You don't have to have only the best programmers. You don't have to have Steve Jobs as the Product Champion and Ken Schwaber as the coach.
I'll give the aspiring actor and the aspiring Agile team the same advice: Identify your weaknesses, work to reduce their impact. Identify your strengths, and leverage them. And don't be discouraged by an apparent lack of progress. You may never get to where you though you wanted to be, but you will be much happier with the results than if you just kept doing what you were doing. You'll "get what you need" (Mick Jagger, of course).
Visit the Dragon's Lair
I think Pivotal Labs in San Francisco will give you a brief tour, and will describe what they're doing. I know that Menlo Innovations in Ann Arbor will give a two-hour tour, and in fact their tours are so popular that they've published a book and posted video on the web for those who cannot make it out to Ann Arbor. Another in the Bay Area, I'm told, is Sarah Allen's Blazing Cloud.
A few Wise Dragons to choose from. At each of these places, you can watch real software being made using Agile management and development techniques.
And rather than falling for the cynical belief that it can never work at your shop, let me bring in my executive coaches, Lean/Theory-of-Constraints experts, and Agile Mentors (me and others), and we'll help you reveal the Wise Dragon lurking within your teams.
You don't have to believe, you just have to get over the shock.
