The Agile Manifesto has four tenets:
Individuals and interactions over processes and tools: I don't think anyone would argue that individuals and interactions are unimportant. But does this really mean a choice? Of course not. What about tools that encourage interactions? We all want our development teams to have the best individuals in them, but it is a truism that 50% of developers are below average (almost, but not quite, by definition). So how do we make the best of these less than stellar individuals? Well, how about having a process in place that lets us check their work, and maybe even lets them learn. Hey, maybe we could pair them up with a more experienced (better?) developer? We could even give it a sexy name, maybe "pair-programming". (See what I did there - agile prefers individuals and interactions over processes and tools, and achieves this by, oh, having processes. Hmm.) And how do we get interactions? Maybe we could have a quick meeting every day, we'll make everyone stand up so it doesn't take too much time. Oh, another process. Well, how do we decide what to do? I know, we'll keep a list of things to do (what will we use to store this, I don't know, maybe some sort of todo list tool? Oh, look, a tool) and every so often we'll decide which are the most important. Oooh, another process. OK, scrap all that, let's just let everyone interact with everyone else. Let's see, we have ten developers on the team, that means forty-five communication channels. We can manage that. What happens when the project grows and we now need twenty developers? We now need 190 channels. Whoah, that's a lot. Maybe we should break things down into teams and get the teams to communicate through the team leads. Sounds like more of that darned process stuff.
Working software over comprehensive documentation: I think we can all agree that we want working software. This is a no-brainer, right? So, how do we know the software is working? How do we know it doesn't have some hidden flaw that's going to bring the whole thing crashing about our ears? We don't. Unless we test (actually, that's no guarantee, but that doesn't invalidate the argument here). What are we testing against? Well, we have these User Stories, and the software meets all of those. But does it also behave in the expected way when people do the wrong thing? OK, so we need to make sure that the User Stories account for user error (or missing input, or communication line corruption, or invalid data in the database, or...). Great, sorted that out. oh, just thought, what happens when it doesn't work? We'll need to look into the design to see how the story was implemented, and we will want to know why design choices were made so that we can decide if they are (still) valid. And we will also need to understand how the code matches the design. Ah, there is no comprehensive design documentation. OK, I'll just ask Joe, who coded it. Oh, Joe left six months ago and is now at a competitor. Hmm
Customer collaboration over contract negotiation: Hey, Mr. Customer, we've got a great idea! You just give us some money and we'll deliver what we can. And we'll keep chasing you for input. What, you want to know how much it will all cost so you can work out Return on Investment? No, you don't need that, we'll just keep spending your money until it's good enough. No, there's no need for a contract, you can trust us! No, wait, come back, it will work, honest, lots of people who make their money telling people how to do this say it will. OK, let's step back a little, we all know it isn't really like that (don't we?). But in the real world, customers do want to see some commitment. And, sad though it may be, they often want that commitment to be legally binding. And that means a contract, which needs to be negotiated. Yes, we would all like to be collaborators with our customers, and a good contract provides the legal framework for that to be possible.
Responding to change over following a plan: Change happens (to mis-quote Forrest Gump). A change is only a change if there is something there to be changed. What is that something? Well, a good start is what was planned to be produced. Actually, this tenet isn't as much of a false dichotomy as the others. In fact, it is one of the bases of good project management practice in all disciplines. But there must be some sort of plan, even though it is acknowledged that it will inevitably change.
So when we look at these "X over Y" statements, they either don't stand up to scrutiny as being in as much opposition as is claimed, or are what has been best practice for a long time. So what is agile giving us? Unfortunately (stand by for wild over-generalization), it is often used as an excuse for throwing out the "Y" parts of the tenets without considering the consequences. In many cases, it is little more than an excuse for undisciplined hacking of the worst sort. To reiterate a statement that I have made many times in the past, I am not against the ideas and ideals of agile. What I am against is people treating it as a panacea or something that blows away the need to remember the lessons of the past. So, perhaps you should prefer X over Y, but that does not mean that you don't do the Y at all.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Individuals and interactions over processes and tools: I don't think anyone would argue that individuals and interactions are unimportant. But does this really mean a choice? Of course not. What about tools that encourage interactions? We all want our development teams to have the best individuals in them, but it is a truism that 50% of developers are below average (almost, but not quite, by definition). So how do we make the best of these less than stellar individuals? Well, how about having a process in place that lets us check their work, and maybe even lets them learn. Hey, maybe we could pair them up with a more experienced (better?) developer? We could even give it a sexy name, maybe "pair-programming". (See what I did there - agile prefers individuals and interactions over processes and tools, and achieves this by, oh, having processes. Hmm.) And how do we get interactions? Maybe we could have a quick meeting every day, we'll make everyone stand up so it doesn't take too much time. Oh, another process. Well, how do we decide what to do? I know, we'll keep a list of things to do (what will we use to store this, I don't know, maybe some sort of todo list tool? Oh, look, a tool) and every so often we'll decide which are the most important. Oooh, another process. OK, scrap all that, let's just let everyone interact with everyone else. Let's see, we have ten developers on the team, that means forty-five communication channels. We can manage that. What happens when the project grows and we now need twenty developers? We now need 190 channels. Whoah, that's a lot. Maybe we should break things down into teams and get the teams to communicate through the team leads. Sounds like more of that darned process stuff.
Working software over comprehensive documentation: I think we can all agree that we want working software. This is a no-brainer, right? So, how do we know the software is working? How do we know it doesn't have some hidden flaw that's going to bring the whole thing crashing about our ears? We don't. Unless we test (actually, that's no guarantee, but that doesn't invalidate the argument here). What are we testing against? Well, we have these User Stories, and the software meets all of those. But does it also behave in the expected way when people do the wrong thing? OK, so we need to make sure that the User Stories account for user error (or missing input, or communication line corruption, or invalid data in the database, or...). Great, sorted that out. oh, just thought, what happens when it doesn't work? We'll need to look into the design to see how the story was implemented, and we will want to know why design choices were made so that we can decide if they are (still) valid. And we will also need to understand how the code matches the design. Ah, there is no comprehensive design documentation. OK, I'll just ask Joe, who coded it. Oh, Joe left six months ago and is now at a competitor. Hmm
Customer collaboration over contract negotiation: Hey, Mr. Customer, we've got a great idea! You just give us some money and we'll deliver what we can. And we'll keep chasing you for input. What, you want to know how much it will all cost so you can work out Return on Investment? No, you don't need that, we'll just keep spending your money until it's good enough. No, there's no need for a contract, you can trust us! No, wait, come back, it will work, honest, lots of people who make their money telling people how to do this say it will. OK, let's step back a little, we all know it isn't really like that (don't we?). But in the real world, customers do want to see some commitment. And, sad though it may be, they often want that commitment to be legally binding. And that means a contract, which needs to be negotiated. Yes, we would all like to be collaborators with our customers, and a good contract provides the legal framework for that to be possible.
Responding to change over following a plan: Change happens (to mis-quote Forrest Gump). A change is only a change if there is something there to be changed. What is that something? Well, a good start is what was planned to be produced. Actually, this tenet isn't as much of a false dichotomy as the others. In fact, it is one of the bases of good project management practice in all disciplines. But there must be some sort of plan, even though it is acknowledged that it will inevitably change.
So when we look at these "X over Y" statements, they either don't stand up to scrutiny as being in as much opposition as is claimed, or are what has been best practice for a long time. So what is agile giving us? Unfortunately (stand by for wild over-generalization), it is often used as an excuse for throwing out the "Y" parts of the tenets without considering the consequences. In many cases, it is little more than an excuse for undisciplined hacking of the worst sort. To reiterate a statement that I have made many times in the past, I am not against the ideas and ideals of agile. What I am against is people treating it as a panacea or something that blows away the need to remember the lessons of the past. So, perhaps you should prefer X over Y, but that does not mean that you don't do the Y at all.
