The Agile Test
At the end of my Agile2005 Keynote I had everyone in the audience (675 people!) raise their hands. Then I ran through a litany of questions that caused certain people to lower their hands.Lower your hands if:
- You are not working on an Agile Project.
- You are working on an Agile project and the iteration size is > 30 days.
- Your iteration size is > 2 weeks.
- You are not working in an open office or lab.
- You have no unit tests.
- You are not writing unit tests first.
- You have no acceptance tests whether automated or manual.
- You have no continuous build process.
- You have no automated acceptance tests.
- You are not pairing
- Less than 100% of your features are defined by automated acceptance tests.
The pattern of hands going down was illuminating. By the end there were only two or three hands left up.
From a posting below, I think the following ought to be added to the test:
- You do not develop features in an order chosen by the customer
- You do not deploy to production at the end of each iteration
- You do not talk to your customer every day
- The customer does not sit alongside the developers
- Customer cannot reprioritises features at the end of each iteration.
!commentForm
Bob,
I wanted to send a quick note of thanks for your comments at the opening session yesterday.
Not only do I now know how (aprox.) old the universe is (a Jeopardy winning question if I ever heard one) I very much enjoyed your comments on how, when time lines are crunched (or not even thought about but dictated) developers write "crap" and QA people suffer like martyrs.
Your ability to convey complex ideas within a compelling story context was inspirational. I hope to bring that technique back to my engineering group and spread the word of Agile far and wide!
Thank you! For your enthusiasm, your wit and most of all for your solid ideas on how to actually get things done!
- Sarah
saoliveira@hbs.edu
I wanted to send a quick note of thanks for your comments at the opening session yesterday.
Not only do I now know how (aprox.) old the universe is (a Jeopardy winning question if I ever heard one) I very much enjoyed your comments on how, when time lines are crunched (or not even thought about but dictated) developers write "crap" and QA people suffer like martyrs.
Your ability to convey complex ideas within a compelling story context was inspirational. I hope to bring that technique back to my engineering group and spread the word of Agile far and wide!
Thank you! For your enthusiasm, your wit and most of all for your solid ideas on how to actually get things done!
- Sarah
saoliveira@hbs.edu
Hey Bob,
I realize that many people out there aren't doing all the things you mention. But how do you get them there? How do you get people to do all these things you mention. Developers are very stubborn people. In fact, at my new company (I left Apollo btw) I've been trying to push TDD and get people to start coding that way. I gave a presentation with examples on TDD, and everyone went, wow, thats frickin cool, then went about with their business as usual. I had another dicussion about comments in code. So how do you convince very stubborn people to change?
Up for some Sushi in Boston?
-Ben
I realize that many people out there aren't doing all the things you mention. But how do you get them there? How do you get people to do all these things you mention. Developers are very stubborn people. In fact, at my new company (I left Apollo btw) I've been trying to push TDD and get people to start coding that way. I gave a presentation with examples on TDD, and everyone went, wow, thats frickin cool, then went about with their business as usual. I had another dicussion about comments in code. So how do you convince very stubborn people to change?
Up for some Sushi in Boston?
-Ben
Great test. Dramatic summary of "Where we are." Consider doing it again at the Thursday night banquet and getting a rough count of the number of people at each step. Maybe have someone take a digital photo after each question. Maybe repeat it each year. Maybe add the list prominantly on XP web sites. Maybe a self-assesment web page on the OM site. Sorta like the CMMI self assessment test only quicker...
Could have a scoring scheme. (web page) For example some team may be doing all the other cool stuff except their iterations are 3 weeks. Seems like they should get a high "score".
Could have a scoring scheme. (web page) For example some team may be doing all the other cool stuff except their iterations are 3 weeks. Seems like they should get a high "score".
Ben,
I don't know how exactly to get people to change, but I've had some good results in helping people who were struggling with this or that programming problem. We sit together and I walk them to find the solution writing tests first, a simple test at a time. They come out of it quite impressed.
I don't know how exactly to get people to change, but I've had some good results in helping people who were struggling with this or that programming problem. We sit together and I walk them to find the solution writing tests first, a simple test at a time. They come out of it quite impressed.
Pretty easy.
Convince the manager that it is important to test every single method in every class. Then create a report that shows which code has been tested and which hasn't. Then when bugs are discovered, write them down using Attlassian Jira or something like that, and add an attribute to each bug report showing the failing class/method and if it does have a test or not.
Eventually you will see that most bug reports are for code that had not been previously tested.
Convince the manager that it is important to test every single method in every class. Then create a report that shows which code has been tested and which hasn't. Then when bugs are discovered, write them down using Attlassian Jira or something like that, and add an attribute to each bug report showing the failing class/method and if it does have a test or not.
Eventually you will see that most bug reports are for code that had not been previously tested.
At which point would YOU drop your hand, uncle Bob ? :-)) I bet there's one that would have forced you to do so. Otherwise you wouldn't be in the software business but in Heaven :-D.
- As a roving consultant, I don't pair nearly enough. I love pairing when I can, but I can't do it often enough.
- For the same reason as above, I don't often work in an open office. Object Mentor headquarters is set up as an open office, but I'm not there nearly as much as I'd like.
- 100% acceptance testing is an ideal that I have approached, but not achieved.
Just wondering if the last point was supposed to be '100% of you features are _not_ defined by automated acceptance tests' or if it is displayed as intended, and 100 of your features aren't supposed to have automated acceptance tests.
Hi Bob!
Seems to me your questions were really trying pinpointing whether or not a project was being faithful to XP rather than agility. Iterations that are a month or less is pretty standard across the agile spectrum; two weeks or less starts getting very XP-centric. Ditto with Pair Programming and Test-First.
A good question on integration might have been to ascertain "how frequent" is "continuous"? If it is at least daily or nightly, that still within agile parameters, though probably not XP unless it's many times per day.
For the more general "Agile" test, maybe going thru the dozen agile principles with questions designed to elicit (a) if you were doing it and (b) if you were doing it sufficiently small/frequently
Seems to me your questions were really trying pinpointing whether or not a project was being faithful to XP rather than agility. Iterations that are a month or less is pretty standard across the agile spectrum; two weeks or less starts getting very XP-centric. Ditto with Pair Programming and Test-First.
A good question on integration might have been to ascertain "how frequent" is "continuous"? If it is at least daily or nightly, that still within agile parameters, though probably not XP unless it's many times per day.
For the more general "Agile" test, maybe going thru the dozen agile principles with questions designed to elicit (a) if you were doing it and (b) if you were doing it sufficiently small/frequently
Brad,
You are not the first person to suggest that this was more of an XP test than an Agile test. This surprises me.
It is true that these are XP practices; but I consider that incidental. These are practices that I think ought to be helpful to any team aspiring to be agile. I agree that some teams may not be able to follow these practices yet. But I am taken aback by the notion that there are teams who have no intention of trying to integrate these practices.
You are not the first person to suggest that this was more of an XP test than an Agile test. This surprises me.
- Apparently there are agile teams who do not have automated acceptance tests, and don't feel that they need them.
- Apparently there are agile teams who do not write unit tests first, and don't feel that it would help them.
- Apparently there are agile teams who do not work in an open office, and don't feel it would help them.
- Apparently there are agile teams who do not pair, and don't feel it would help them.
It is true that these are XP practices; but I consider that incidental. These are practices that I think ought to be helpful to any team aspiring to be agile. I agree that some teams may not be able to follow these practices yet. But I am taken aback by the notion that there are teams who have no intention of trying to integrate these practices.
That list is interesting. Firstly it concentrates almost entirely on the *technical* practices of agile development, most of which are equally applicable to non-agile development. Secondly, many of the practices are specific to XP, not agile in general. E.g. Crystal Clear doesn't mandate pairing.
Most odd, to me, is that it doesn't once mention the delivery of value to the customer or, I notice, the customer at all!
How about some questions along the line of
I like these! You are right, they should have been part of the original. - UB.
Most odd, to me, is that it doesn't once mention the delivery of value to the customer or, I notice, the customer at all!
How about some questions along the line of
- You do not develop features in an order chosen by the customer
- You do not deploy to production at the end of each iteration
- You do not talk to your customer every day
- The customer does not sit alongside the developers
- Customer cannot reprioritises features at the end of each iteration.
I like these! You are right, they should have been part of the original. - UB.
So you /cannot/ be agile if you don't pair? You /cannot/ be agile with an iteration size more than two weeks? You /cannot/ be agile if < 100% of your features are defined by automated acceptance tests?
That was not the intent. Agility is not a binary value, it's a continuum. So you can be more agile if you pair, you can be more agile if you shrink your iteration size, you can be more agile if you automate more of your acceptance tests. - UB
That was not the intent. Agility is not a binary value, it's a continuum. So you can be more agile if you pair, you can be more agile if you shrink your iteration size, you can be more agile if you automate more of your acceptance tests. - UB
I've been firmly in the open office camp until my recent read of Peopleware by Demarco & Lister. Now I'm considering converting our space into several 3 - 4 person offices. Have you read it & what are your thoughts?
(I've also read A Pattern Language, and Peopleware's ideas seemed to be in line with it.)
(I've also read A Pattern Language, and Peopleware's ideas seemed to be in line with it.)
Hi Bob
There are some very interesting questions here, and ones which I would probably ask of my own clients. But I'm siding with Brad a little, in that it does rather look more like a "how XP are you?" test than a "how agile are you?" test - though I suspect the more agile you get, the more XP it looks :-)
Perhaps a more testable definition of agility could be offered? Maybe it could be driven by the core agile values. How simple did we make our solution (compared to the complexity of the problem)? What is the frequency and quality of feedback? How feedback-driven are we? How much do we communicate, and how rich is that communication? I'm a bit stumped on testing for courage, TBH. But maybe there's a way...
If we could get testable definitions of "agility" that don't apply specifically to software development, I'd find that a very powerful tool as a consultant. For example, right now I'm working with a client whose developers are very agile, but whose marketing department still does waterfall, creating a disconnect in product management that's a bit of a barrier for them. If I could apply agile principles effectively to product management, I think it would help them. I can readily apply SPI principles to pretty much any process (once you've identified time, scope, cost and quality in that domain, it's quite straightforward.) If I could do the same for agility, I'd find that useful for sure.
Jason
Of course, I could be talking rubbish :-)
There are some very interesting questions here, and ones which I would probably ask of my own clients. But I'm siding with Brad a little, in that it does rather look more like a "how XP are you?" test than a "how agile are you?" test - though I suspect the more agile you get, the more XP it looks :-)
Perhaps a more testable definition of agility could be offered? Maybe it could be driven by the core agile values. How simple did we make our solution (compared to the complexity of the problem)? What is the frequency and quality of feedback? How feedback-driven are we? How much do we communicate, and how rich is that communication? I'm a bit stumped on testing for courage, TBH. But maybe there's a way...
If we could get testable definitions of "agility" that don't apply specifically to software development, I'd find that a very powerful tool as a consultant. For example, right now I'm working with a client whose developers are very agile, but whose marketing department still does waterfall, creating a disconnect in product management that's a bit of a barrier for them. If I could apply agile principles effectively to product management, I think it would help them. I can readily apply SPI principles to pretty much any process (once you've identified time, scope, cost and quality in that domain, it's quite straightforward.) If I could do the same for agility, I'd find that useful for sure.
Jason
Of course, I could be talking rubbish :-)
i found this article from <UL>http://www.ruhezuo.com</UL>,thank a lot.
What happens in very small organizations where the entire engineering department includes the Lone Ranger programmer? Is not agility a virtue for such organizations where pairing is extremely impractical at best?
Add Child Page to TheAgileTest