Using Scrum to Grow "Best Practices"

Image via Wikipedia

I've noticed agile proponents have issues with the phrase "best practices."  This article, for example, complains that "best practices" are often:

• Handed down by an authority, such as a consultant, management, or other "experts"
  
• Boilerplate rules that may not match your organization's size or culture
  
• Anecdotal, almost arbitrary guidelines that don't explain why you should use them

Personally, I like the phrase "best practices," but only because I need a way to name the goals I've set for myself and for my development team.  "Standard Operating Procedure" sounds so 1950's, and the "standard development process" is pretty vague.  The phrase is "best" because it's the best way we've tried so far, and "practice" because we're still on the path to getting it right.

But, there's still the problem of setting those best practices. We don't want arbitrary boilerplate imposed on us by a consultant or by management. And this is where Scrum, or any other Agile framework helps.

We use a Scrum framework for development, and we chose a sprint iteration of two weeks. At the end of every sprint we have a functional review to demonstrate the recent changes to key people in our organization. Immediately after the functional review the development team holds a 15 minute retrospective of the sprint. The agenda for this meeting looks like this:

Process Review
After the functional review we have a retrospective on the development process itself. We answer three questions:
1) What was good about the process so far?
2) What do we want to change?
3) What 1 thing are we going to try to improve for the next two weeks?

The development team starts by listing the "good" items. Sometimes, depending on the mood of the functional review, this can take some digging.  But, we try to get at least one "good" thing from each person at the meeting written down.  Then we talk about what we want to change. By keeping the question neutral it helps to avoid focusing on blame or rehashing problems, but instead asks for solutions.  Team members offer suggestions, and from the solutions we choose one item that we want to focus on -- in essence, something we want to practice.  Finally, at the beginning of the next functional review meeting we check to see whether the "1 thing" we changed was effective.

"So what?" you may ask, "What does that have to do with 'best practices?'"

Well, after enough sprints, you may find you've written your own set of "best practices."  Moreover, they aren't handed to you by someone one who has a corporate agenda, or may not even know your name. They've been evolved organically by the development group as a set of aspirations.  The team implicitly understands the best practice because:

• They lived the problem.
  
• They participated in creating the solution.
  
• The practice was created organically within the corporate or development team culture.
  
• It's a goal, not a mandate.
  

Here is the team's actual list of resolutions after six sprints:

• "Log test coverage and review the logs"
  
• "Close the feedback loop from the functional review by reviewing changes with trainers, etc before halfway through the sprint."
  
• "We're having too many meetings. Can we schedule some every other week, or once per month?"
  
• "Get the right people in the room. Too often it's just the development team."
  
• "Provide a forum for presenting daily changes. Set up an "alpha" station for the trainers and support staff."
  
• "Each person should take their own notes during the scrum"
  
• "Use the "parking lot" model for tangential ideas"

In some settings these items may be obvious, but not everyone on our team has the same level of technical experience.  It was only after two weeks or more of difficulties that the team decided to change, and the change came from within.  If the change didn't work out, well two weeks after adopting the resolution we review whether the change was successful.  If it doesn't make our development process any better we're free to scrap it and try something else. After a while the successful changes become internalized as "best practices."