Agile Zone is brought to you in partnership with:

Matt is the Group Leader of Research Application Development in the Research Informatics Division of Information Sciences at St. Jude Children's Research Hospital in Memphis, Tennessee. Matt has been developing and supporting enterprise Java applications in support of life sciences research for St. Jude since 2001. Matt is a committer to multiple open source projects and is the founding member of the Memphis/Mid-South Java User Group. Matt is also a regular speaker on the No Fluff Just Stuff symposium series tour (as well as other major conferences), and his articles have appeared in GroovyMag and NFJS the Magazine. His current areas of interest include lean/agile software development, modularity and OSGi, mobile application development (iPhone/iPad/Android), web development (HTML5, etc.), and Groovy/Grails. Matt has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

But the ScrumMaster said I had to!

07.06.2010
| 3676 views |
  • submit to reddit
Today's article will be a short one, but I think it raises a very important point. A wide range of software development methodologies exist, some of them more prescriptive than others. Extreme Programming prescribes twelve to thirteen practices depending on which book or article that you read. Scrum doesn't tell you much about how you should write code, but it's very adamant about how you should schedule features. For more todo lists, look no further than RUP, FDD, Crystal, etc.

Let's take a trip back up to 10,000 feet and revisit the first point of the Agile Manifesto:

Individuals and interactions over processes and tools

Its entirely possible to get so bent on following the tenants of Scrum, XP, or any other methodology, that you forget about the fact that software is developed by people, not process. It's also developed by people, not practices.

Let's say you get started working with XP and pair programming just isn't working for you. That doesn't mean you're just "not trying hard enough." Perhaps pair programming DOESN'T work for the people in your environment. Perhaps it runs too counter to the culture of your organization. Does that mean you can't be agile? Absolutely not.

Any practice's potential success depends entirely on the context in which it is applied. Any practice could work wonderfully at company A, and then epically fail at company B. The bottom line is, if it doesn't work for you, throw it out and find something that does. Insanity has been aptly defined as "continuing to do the same things continually and expecting different results."

Be agile, don't be insane!

In keeping with this theme, let's look at an agile way to evaluate agile practices.

  1. Evaluate: Look back over the last few development cycles and identify areas that need improvement. Of those areas, focus in on the one or two areas that if effectively addressed would return the most value to your team and your customer. Perhaps you have a lengthy verification cycle preceding each release that includes a great deal of thrashing between defect identification by QA and defect fixing by development.
  2. Research: Look into development practices that are targeted at addressing these needs. One practice targeted at the need identified in #1 is acceptance test driven development. Tests are defined in an executable manner prior to development of the features. Features are considered done if and only if the tests pass.
  3. Metrics: You need a way of deciding whether or not the new practice is having its intended effect. Pick a metric that your team agrees will give you this answer. An obvious target for this problem would be the average length of the verification cycle. Try to grab several data points from before you start the new practice (if possible) so that you can get a baseline for comparison.
  4. Install the Practice: Start the new practice. Make sure you continue doing it for several iterations/cycles before moving on to step #5. You'll need time to move through what Martin Fowler calls the "Improvement Ravine." (http://martinfowler.com/bliki/ImprovementRavine.html) Any time you try a new practice you'll usually get worse before you get better. This is because it takes time for you to adapt to this new way of working, and only when you work through this dip will you start to truly see how well the practice helps (or doesn't).
  5. Evaluate: Pause and look back over your metrics. Do you see a gradual dip into the improvement ravine followed by gradual improvement in your metric? Or do you see a downward spiral? Only your team can decide whether or not you've given the practice long enough, so decide together if its time to keep it or toss it.

This process looks an awful lot like the scientific method, and that's totally intentional. It's only by looking at our work in such a disciplined manner that we can get to objective answers about how well a practice fits in our environment. It's a much better way of moving forward than doing something just because "the ScrumMaster said I had to!"
Published at DZone with permission of its author, Matt Stine.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)