A Medium-Sized List of Agile Practices

I wanted to compile a list of important agile practices, big enough to include all the important ones, but not so big as to be overbearing, intimidating and unhelpful to agile beginners.

You would probably be right to interrupt me at this point by asking, wouldn’t such a list constitute a process? Doesn’t the Agile Manifesto teach that we should value individuals and interactions over processes and tools?

You would be right because the Agile Manifesto says nothing about using, for example, continuous integration. But how many of the early adopters of agile refuse to use it? Hardly any. At the same time, the word agile is used by many more people now than ten years ago and stories like “we’ve implemented scrum; we now hold status meetings daily instead of weekly” abound.

So, the list of recommended practices will of course come with disclaimers and caveats. Each listed practice is optional and following all of them won’t automatically make you agile. But let’s try to compile the list first.

I visited a blog, NOOP.NL, whose author, Jurgen Appelo, is both a recognized agile expert and seems to be a fan of top-100 lists. He did The Big Agile Practices Survey a while back and then published the results. Out of the survey’s many questions, I decided to consider the following three:

• Which practices are REALLY AGILE, or… highest level of agility?
• Which practices are REALLY IMPORTANT, or… highest level of importance?
• Which practices are REALLY APPLIED, or… highest level of application?

Which practices are REALLY AGILE, or… highest level of agility?

Area	Best practice	Score
Process	Iteration Planning / Planning Game / Sprint Planning	98.8%
Process	Velocity	98.1%
Process	Sprint Backlog	98.1%
Process	Daily Stand-up Meeting / Daily Scrum	97.6%
Organization	Self-Organizing Team / Scrum Team	97.5%
Process	Story Points	96.9%
Organization	Scrum Master	96.3%
Process	Sprint Review / Iteration Demo	96.3%
Process	Timeboxing / Fixed Sprints / Fixed Iteration Length	96.0%
Requirements	Product Backlog	95.6%

Which practices are REALLY IMPORTANT, or… highest level of importance?

Area	Best practice	Score
Construction	Source Control / Version Control	100.0%
Process	Definition of Done / Done Done	99.4%
Construction	Refactoring	98.9%
Organization	Sustainable Pace	98.6%
Construction	Frequent Delivery / Frequent Releases	98.3%
Requirements	Product Backlog	98.2%
Requirements	Requirement Prioritization	98.2%
Testing	Unit Testing	98.2%
Testing	Storytesting / Acceptance Criteria / Acceptance Testing	98.1%
Process	Retrospective / Reflection Workshop	98.0%

Which practices are REALLY APPLIED, or… highest level of application?

Area	Best practice	Score
Construction	Source Control / Version Control	100.0%
Requirements	Requirement Prioritization	94.4%
Testing	Unit Testing	93.4%
Requirements	Product Backlog	93.2%
Process	Iteration Planning / Planning Game / Sprint Planning	92.9%
Construction	Refactoring	91.8%
Process	Daily Stand-up Meeting / Daily Scrum	90.8%
Process	Timeboxing / Fixed Sprints / Fixed Iteration Length	90.8%
Construction	Daily Builds / Automated Builds / Ten-Minute Builds	90.3%
Testing	Integration Testing	88.2%

Several observations can be made:

• Notice the amazingly high percentages of respondents who said that they associate a particular practice with agile, believe that it is important, and actually apply it.
• The identified practices are not constrained to any particular agile method. For example, there is no mention of pair programming (an XP practice) and the respondents didn’t say the scrum master has to be a designated person.
• Some of the practices are mentioned more than once. The Product Backlog occurs in all three lists.
• Let’s say you don’t have a product backlog. The Agile Manifesto doesn’t say you must have it. But it should be clear now that either you have a good reason not to have it or you are missing something important.

By joining the three lists and removing the duplicates, I got a list of 21 practices. I removed the percentages (they are now unimportant), grouped related practices together and renamed the areas. Here is the result:

Area	Best practice
People	Self-Organizing Team / Scrum Team
People	Scrum Master
Timing	Timeboxing / Fixed Sprints / Fixed Iteration Length
Timing	Sustainable Pace
Timing	Frequent Delivery / Frequent Releases
Requirements	Product Backlog
Requirements	Requirement Prioritization
Requirements	Iteration Planning / Planning Game / Sprint Planning
Requirements	Sprint Backlog
Tools and Techniques	Source Control / Version Control
Tools and Techniques	Daily Builds / Automated Builds / Ten-Minute Builds
Tools and Techniques	Refactoring
Tools and Techniques	Unit Testing
Tools and Techniques	Integration Testing
Tools and Techniques	Storytesting / Acceptance Criteria / Acceptance Testing
Feedback	Daily Stand-up Meeting / Daily Scrum
Feedback	Sprint Review / Iteration Demo
Feedback	Definition of Done / Done Done
Feedback	Retrospective / Reflection Workshop
Feedback	Velocity
Feedback	Story Points

Now I want to take one more simplifying step: get rid of the tabular form of information.

Start with people. You need a scrum master and a self-organizing team. Timing-wise, your process is iterative, uses fixed-length, time-boxed iterations and emphasizes sustainable pace and frequent releases. What do you do in each iteration? You start with a product backlog, which is maintained to reflect your current prioritization of requrements. Once you have it, you can hold an iteration planning meeting at the start of an iteration and select user stories into the sprint backlog. Now, what techniques to you use to engineer the solution to satisfy your customer? Well, source control is a must, daily, automated builds (probably enabled by a continuous integration system) are helpful. There are no recommendations on how to design and write your code, but it is recommended that you refactor it. Then there is a three-pronged testing strategy: unit-, acceptance and integration tests. (Serious QA strategy will have more prongs, but we are talking about the minimal agile-specific set.)

Lastly, and most importantly, there is feedback, lots of it and in various forms. The daily scrum (or, in a literal translation from one of the foreign languages, the synchronization reunion!) and the iteration demo, when there is no avoiding the question: what is our definition of done? Retrospectives to improve the teamwork and fine-tune the practices. Velocity is very important in agile estimation and planning and to track velocity you need story points.

OK, getting to this list was labourious, but the result itself is compact as I promised at the beginning of the post.

Advertisement