Comments on: Selling my first Agile project – to the method police http://www.techdarkside.com/selling-my-first-agile-project-to-the-method-police Struggles of a Self-Taught Coder Tue, 07 Feb 2012 02:07:00 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: tate http://www.techdarkside.com/selling-my-first-agile-project-to-the-method-police/comment-page-1#comment-15404 tate Mon, 02 Jul 2007 15:08:23 +0000 http://www.techdarkside.com/?p=124#comment-15404 Initially, I didn't really like the "idea" of the sign-off either, but I have to say this: It forced me to check up on the team and find the pairing on every use case. And guess what? Sometimes people had not done any pairing yet on that use case and they had to arrange something to make sure pairing happened - or at least get somebody to sign something saying they paired. Now, you could make the argument that the developers were smart enough to know when they could use some help and when they didn't need to. But that argument falls down a little bit when you think about it more. If that were extremely true (developers knowing when they might need a reviewer or a sounding board and when they didn't), then we wouldn't really have many defects in software development would we? And, that misses the other benefit of pairing that I saw: You get cross-pollination of knowledge. Everybody gets a little smarter about how to make use of the architecture that is already in place and no single developer holds the only key to a certain pile of code. One of the greatest values I saw to pairing as a PM - which I'm sure was a direct result of the cross-pollination - was that I could ramp up the team a little bit or even lose a person from time to time and not worry about what the ramp up time would be or what a certain developer knows that nobody else does. In the past, a project might live or die by the defections or one or two people. This is a huge problem from a risk management perspective. The data from my project indicated a completely linear impact on velocity based on headcount. Meaning, people came on and off the project and our overall team velocity was always a very stable factor based on headcount. I have never seen that on any 'traditional' project. It was amazing. Of course, I was never able to measure velocity on traditional projects either... Initially, I didn’t really like the “idea” of the sign-off either, but I have to say this: It forced me to check up on the team and find the pairing on every use case. And guess what? Sometimes people had not done any pairing yet on that use case and they had to arrange something to make sure pairing happened – or at least get somebody to sign something saying they paired.

Now, you could make the argument that the developers were smart enough to know when they could use some help and when they didn’t need to. But that argument falls down a little bit when you think about it more. If that were extremely true (developers knowing when they might need a reviewer or a sounding board and when they didn’t), then we wouldn’t really have many defects in software development would we?

And, that misses the other benefit of pairing that I saw: You get cross-pollination of knowledge. Everybody gets a little smarter about how to make use of the architecture that is already in place and no single developer holds the only key to a certain pile of code.

One of the greatest values I saw to pairing as a PM – which I’m sure was a direct result of the cross-pollination – was that I could ramp up the team a little bit or even lose a person from time to time and not worry about what the ramp up time would be or what a certain developer knows that nobody else does.

In the past, a project might live or die by the defections or one or two people. This is a huge problem from a risk management perspective. The data from my project indicated a completely linear impact on velocity based on headcount. Meaning, people came on and off the project and our overall team velocity was always a very stable factor based on headcount. I have never seen that on any ‘traditional’ project. It was amazing.

Of course, I was never able to measure velocity on traditional projects either…

]]> By: dave http://www.techdarkside.com/selling-my-first-agile-project-to-the-method-police/comment-page-1#comment-15403 dave Fri, 29 Jun 2007 14:55:29 +0000 http://www.techdarkside.com/?p=124#comment-15403 Here's a comment I got from Garrett: "Everyone griped about doing the sign-off, but nobody griped about doing a little bit of pair programming. In fact, as near as I could tell, all the developers spent more than two hours paired up per use case. So, I'm not sure why they were so irritated at having to sign something saying that they did, in fact, pair up." Implying that I was a liar would make me gripe. By requiring developers to sign after they have already said or shown that they have done, in this case, pair coding is simply saying that you don't trust them. That's insulting. An additional insult is that management would think that their developers are such simpletons that if they decided to lie that they would be scared into compliance by signing some legal joke of a document. Nice value add there. Accomplishes nothing and ticks off your developers. Here’s a comment I got from Garrett:

“Everyone griped about doing the sign-off, but nobody griped about doing a little bit of pair programming. In fact, as near as I could tell, all the developers spent more than two hours paired up per use case. So, I’m not sure why they were so irritated at having to sign something saying that they did, in fact, pair up.”

Implying that I was a liar would make me gripe. By requiring developers to sign after they have already said or shown that they have done, in this case, pair coding is simply saying that you don’t trust them. That’s insulting.

An additional insult is that management would think that their developers are such simpletons that if they decided to lie that they would be scared into compliance by signing some legal joke of a document. Nice value add there. Accomplishes nothing and ticks off your developers.

]]>