Help shape the new book "Agile in the Bloodstream"
Chapter One
Hi,
I'm posting our first chapter, as it has been submitted to Addison Wesley. I'm not going to post every chapter, but this may be a good introduction to the book that you can use when explaining it to friends and colleagues.
Please read and let me know your thoughts.
We promise this book will be like no software book you've ever read.
Why does a team use the particular practices that it does? What we've seen with Agile, as with countless practices before it, is that teams adopt particular Agile methods because they were told to. It might have been that they went to a conference and heard people touting Agile and its many successes. It might have been that their bosses suddenly got “Agile religion” and the people in the organization were asked to adopt Agile. Or it might have been a consultant coming in, convincing one and all that “Agile works – you need to start using it.”
This is all fine. We need to learn from one another in industry, we need to pay attention to what our bosses want, and consultants hopefully give us good advice. The problem happens when a particular method does not quite fit. Let's say that a project is wrestling with the Agile idea “Product Owner in the Team Room Full-Time.”
This team's product owner is in another part of the world. “What do we do now?” The response the team has to that question is the biggest issue we tackle in this book. If the answer is “Find out what the top Agilists have blogged about this,” or running back to the consultant to get instructions, then there are going to be problems on this project. Because a faraway product owner is not going to be the last time that “Agile doesn't fit.” This will happen over and over again.
This isn't a problem that is specific to Agile, but it is something that is hurting the entire Agile movement right now. We posit that if we do not solve this issue, this brittleness of our Agile mental models, that Agile will follow every other discredited “software fad” right down the drain, including waterfall, rapid application development (RAD) and all the rest.
The solution is to change the way we view Agile, and the way we view our own teams. To look at it all “with new eyes.” Marcel Proust, the French novelist, said that “The real voyage of discovery consists not in seeing new landscapes, but in having new eyes, in seeing the universe with the eyes of another, of hundreds of others, in seeing the hundreds of universes that each of them sees.”
We want to take you on a voyage of discovery, not of new lands, new practices, new advice, but of having new eyes to look at how we do what we do. Once we gain those new eyes, we will change our behavior, not because someone told us to, but because our previous ways make no sense to us anymore.
If, for instance, we start to ask the most innocent question “why?” we will often find surprising results. We will find, sometimes, that we don't know why we are using a certain method. “Why are only the in-room team members (pigs) allowed to talk at standup and not the merely 'involved' (chickens)?"
Our industry experts may give us a set of polished-sounding reasons (don't get off-track, allows observers without pushing standup time to be too long, etc.). But can our industry experts really prove that this works? Can they prove that allowing chickens to talk inevitably leads to project failure? Of course not.
In fact, and here's where we begin to get in trouble with industry experts, we have to take a lot of the details of each Agile practice on faith. When the experts say “Do this practice my way” or “You have to do all these practices together” we have to believe them. The experts cannot prove that this works. They can point to previous success projects, and they can link the execution of those practices with the success of those projects, but that, by any standard of logic, is flawed. There are too many variables on any project - combinations of practice, goal, team, environment, etc. - to point to any factor and say “That's why it succeeded.” The old consultant line “I've seen it work,” simply isn't worth the breath it takes to say it.
To push the point further, our adherence to practices within Agile (or any other set of practices) is driven by a type of superstition.
People have long spoken of a phenomenon called “cargo cults.” Cargo cults happen when an isolated society suddenly encounters modern technology, and often tends to worship it or to think that it is magic. One occasion was when American cargo planes were landing and taking off on an island in the Pacific. The natives on a neighboring island saw this happening, and connected the arrival of food and supplies with the landing of these giant “birds.” In response, they tried to lure their own “birds” by building dirt runways, bamboo control towers and cocoanut shell headsets, mimicking the rituals they saw the Americans doing.
Several people have used the concept of cargo cults to show how many organizations have adopted Agile, mimicking other success projects, but missing the underlying points below the surface.
Here is an example of what one blogger sees as a “cargo cult” mentality:
So far, people have seen cargo cults in the teams that "do Agile wrong." But the real cargo cult happens whenever we take an expert's word as gospel and we scurry around trying to comply and copy.
The way that the experts are telling us to use Agile, by following “best practices” given to us from the outside, is the cargo cults. Cargo cults are a way to describe, not just “people doing Agile wrong” but, in fact, “following the best practices of another blindly.”
When you hear the phrase “best practices” from any type of adviser, or book or boss, you can be pretty sure that you're headed into the land of cargo cults. We're saying that, yes indeed, the Customer in the above conversation is in a cargo cult, thinking that he is following Agile, but the Coach is also in a cargo cult. The Coach's cargo cult is one that says “Just follow the 'True Agile' practices, like Product Backlog and Product Owner, and you will succeed.” Both people are wrong.
The key to getting past blind obedience and simply copying practices from one place to another is to ask why. Think of every day as if it were “Take Your Daughter to Work Day.” Think deeply about the practices you are using and, like your son or daughter might, ask “Why? Why? Why?" See if you like the answers. “Because my boss told me to,” or “Because the book says so,” or “I don't really know why” might not be very satisfying answers.
We fully intend to show the problems with the concept of “best practices.” But that comes later. For now, we simply want you to sit back and prepare to set yourself up with a new pair of eyes. Eyes that can help you see things that are currently invisible to you, but yet are right in front of you. Eyes that can give you some answers to that question “What do we do now?” without having to run back to the expert. Eyes that can give you the confidence to tear Agile apart, put it back together, scale it up or down, and sustain it for years to come. Eyes that may turn your current world upside-down.
I'm posting our first chapter, as it has been submitted to Addison Wesley. I'm not going to post every chapter, but this may be a good introduction to the book that you can use when explaining it to friends and colleagues.
Please read and let me know your thoughts.
Your World – Upside Down
There's no need to hear of it. There's no need to discuss it. Every one of you knows it by heart by the time you're six or seven, black and white, male and female, rich and poor, Christian and Jew, American and Russian, Norwegian and Chinese – you all hear it. And you hear it incessantly. Because every medium of propaganda, every medium of education pours it out. And hearing it, you don't listen to it – there's no need. It's always there, humming away in the background. But once you know this story, you'll hear it everywhere and you'll be astonished that those around you don't hear it as well, but merely take it in.
Daniel Quinn, Ishmael
We promise this book will be like no software book you've ever read.
Why does a team use the particular practices that it does? What we've seen with Agile, as with countless practices before it, is that teams adopt particular Agile methods because they were told to. It might have been that they went to a conference and heard people touting Agile and its many successes. It might have been that their bosses suddenly got “Agile religion” and the people in the organization were asked to adopt Agile. Or it might have been a consultant coming in, convincing one and all that “Agile works – you need to start using it.”
This is all fine. We need to learn from one another in industry, we need to pay attention to what our bosses want, and consultants hopefully give us good advice. The problem happens when a particular method does not quite fit. Let's say that a project is wrestling with the Agile idea “Product Owner in the Team Room Full-Time.”
This team's product owner is in another part of the world. “What do we do now?” The response the team has to that question is the biggest issue we tackle in this book. If the answer is “Find out what the top Agilists have blogged about this,” or running back to the consultant to get instructions, then there are going to be problems on this project. Because a faraway product owner is not going to be the last time that “Agile doesn't fit.” This will happen over and over again.
This isn't a problem that is specific to Agile, but it is something that is hurting the entire Agile movement right now. We posit that if we do not solve this issue, this brittleness of our Agile mental models, that Agile will follow every other discredited “software fad” right down the drain, including waterfall, rapid application development (RAD) and all the rest.
The solution is to change the way we view Agile, and the way we view our own teams. To look at it all “with new eyes.” Marcel Proust, the French novelist, said that “The real voyage of discovery consists not in seeing new landscapes, but in having new eyes, in seeing the universe with the eyes of another, of hundreds of others, in seeing the hundreds of universes that each of them sees.”
We want to take you on a voyage of discovery, not of new lands, new practices, new advice, but of having new eyes to look at how we do what we do. Once we gain those new eyes, we will change our behavior, not because someone told us to, but because our previous ways make no sense to us anymore.
If, for instance, we start to ask the most innocent question “why?” we will often find surprising results. We will find, sometimes, that we don't know why we are using a certain method. “Why are only the in-room team members (pigs) allowed to talk at standup and not the merely 'involved' (chickens)?"
Our industry experts may give us a set of polished-sounding reasons (don't get off-track, allows observers without pushing standup time to be too long, etc.). But can our industry experts really prove that this works? Can they prove that allowing chickens to talk inevitably leads to project failure? Of course not.
In fact, and here's where we begin to get in trouble with industry experts, we have to take a lot of the details of each Agile practice on faith. When the experts say “Do this practice my way” or “You have to do all these practices together” we have to believe them. The experts cannot prove that this works. They can point to previous success projects, and they can link the execution of those practices with the success of those projects, but that, by any standard of logic, is flawed. There are too many variables on any project - combinations of practice, goal, team, environment, etc. - to point to any factor and say “That's why it succeeded.” The old consultant line “I've seen it work,” simply isn't worth the breath it takes to say it.
To push the point further, our adherence to practices within Agile (or any other set of practices) is driven by a type of superstition.
People have long spoken of a phenomenon called “cargo cults.” Cargo cults happen when an isolated society suddenly encounters modern technology, and often tends to worship it or to think that it is magic. One occasion was when American cargo planes were landing and taking off on an island in the Pacific. The natives on a neighboring island saw this happening, and connected the arrival of food and supplies with the landing of these giant “birds.” In response, they tried to lure their own “birds” by building dirt runways, bamboo control towers and cocoanut shell headsets, mimicking the rituals they saw the Americans doing.
Several people have used the concept of cargo cults to show how many organizations have adopted Agile, mimicking other success projects, but missing the underlying points below the surface.
Here is an example of what one blogger sees as a “cargo cult” mentality:
Another example is this actual [paraphrased] conversation I had with a potential customer: Customer: Oh yes, we’ve been doing agile for a while.
Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team?
Customer: Well, we…uh…don’t really have a Product Owner.
Coach: Oh. Well, who keeps the Product Backlog in shape?
Customer: Well, we…uh…don’t really have a Product Backlog, per se.
Coach: Oh. So how do you plan your sprints?
Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?
http://www.rallydev.com/agileblog/2009/07/implementing-scrum-avoid-...
So far, people have seen cargo cults in the teams that "do Agile wrong." But the real cargo cult happens whenever we take an expert's word as gospel and we scurry around trying to comply and copy.
The way that the experts are telling us to use Agile, by following “best practices” given to us from the outside, is the cargo cults. Cargo cults are a way to describe, not just “people doing Agile wrong” but, in fact, “following the best practices of another blindly.”
When you hear the phrase “best practices” from any type of adviser, or book or boss, you can be pretty sure that you're headed into the land of cargo cults. We're saying that, yes indeed, the Customer in the above conversation is in a cargo cult, thinking that he is following Agile, but the Coach is also in a cargo cult. The Coach's cargo cult is one that says “Just follow the 'True Agile' practices, like Product Backlog and Product Owner, and you will succeed.” Both people are wrong.
The key to getting past blind obedience and simply copying practices from one place to another is to ask why. Think of every day as if it were “Take Your Daughter to Work Day.” Think deeply about the practices you are using and, like your son or daughter might, ask “Why? Why? Why?" See if you like the answers. “Because my boss told me to,” or “Because the book says so,” or “I don't really know why” might not be very satisfying answers.
We fully intend to show the problems with the concept of “best practices.” But that comes later. For now, we simply want you to sit back and prepare to set yourself up with a new pair of eyes. Eyes that can help you see things that are currently invisible to you, but yet are right in front of you. Eyes that can give you some answers to that question “What do we do now?” without having to run back to the expert. Eyes that can give you the confidence to tear Agile apart, put it back together, scale it up or down, and sustain it for years to come. Eyes that may turn your current world upside-down.
About
Badge
© 2009 Created by Daryl Kulak on Ning. Create a Ning Network!
