Key Agile Practices You Need

Laurie Williams has presented a “top thirty” list of key agile practices. The list defines what you need to do to be seen as being agile. Continuous integration, short iterations and done criteria are at the top of the list.

[bibshow file=http://www.citeulike.org/bibtex/user/greger/]
If you’ve followed my blog, you will notice that I keep returning to one important question. What does it mean to be agile? When can we say that we are agile? Which are the key agile practices which can be used as a litmus test to distinguish agile from not agile.

In Agile is NOT I had a look at statements about what Agile is Not to see what the opposite of agile is. In Agile Things to Remember I stated three simple contrasts that are characteristic for agile. In my two posts on unagile (1, 2) I also applied opposites to clarify the difference between agile and non-agile.

I cannot say that my attempts have been overwhelmingly successful. That’s why I was happy to see that Laurie Williams had tried a more empirical approach to decide what is the core of agile. She has compiled a list of key agile practices (she calls them principles) and performed a large-scale survey among practitioners and others to decide which are seen as the most central to agile. [bibcite key=”citeulike:12799124″]

List of key Agile Practices

Williams survey asked practitioners to rate agile practices on a scale from 1 to 5 on how crucial they were to agile. Below, I am listing the top 25 practices. They all had an average agileness score of 4.0 or higher. The first three tied at 4.5. For more details and a full list, see the full publication [bibcite key=”citeulike:12799124″].

1. continuous integration
1. short iterations (30 days or less)
1. done criteria
4. automated tests run with each build
4. automated unit testing
4. iteration reviews/demos
4. potentially shippable features at the end of each iteration
8. whole multidisciplinary team with one goal
8. synchronous communication
8. embracing changing requirements
8. features in iteration are customer-visible/customer-valued
8. prioritized product backlog
13. retrospective
13. collective ownership of code
13. sustainable pace
13. refactoring
17. complete feature testing done during iteration
17. negotiated scope
17. stand up/scrum meeting
17. timeboxing
21. test-driven development unit testing
21. JIT requirements elaboration
21. small teams (12 people or less)
21. emergent design
21. configuration management

Verification and validation are Key Agile Practices

Quality is a pillar of agile software development. Development and delivery without quality is like delivering empty boxes to the customer. They look just like finished products but as soon as the customers opens them, they will discover that they are not really up-to-spec. Combine this with the attitude that each iteration produces a potentially shippable increment and it is not surprising that the agile practitioners responding to the survey rated many test and validation related practices so highly. I’m thinking of CI, definition of done, automated tests, iteration reviews, shippable features, whole team, customer-visible/-valued features, complete feature test in iteration and TDD.

In my part-time job as an agile coach I have seen quite a few teams where they have had a lot of problems from skipping these practices. The result is always the same: The team reports a feature as done. The customer is disappointed and the team builds up a debt of bugs that need to be handled. After a series of these disappointments trust between the team and the customer will erode. Often this leads to a vicious circle of increasingly un-agile behavior and lower and lower quality and trust. If you are this far into problem land, you will need an agile coach to help you sort out the relationship.

Did you notice that iteration reviews/demos was up there in the top ten practices that you need to do to be agile? Iteration demos are one of the key agile practices which are often not being done [bibcite key=”citeulike:10477962″]. IMHO, getting feedback from customer once an iteration is not enough and skimping even on that relatively minuscule feedback is a recipe for disappointment, rework and a loss of trust in the future.

Communication is a Key Agile Practice

Many of the key agile practices in the list are related to communications both within and outside the team. Short iterations force more frequent customer interaction, iteration demos are the natural culmination of that. Other communication related practices are retrospectives, stand up meetings, negotiated scope, prioritized product backlog, JIT requirements elaboration and small teams.

Problems in this area are not entirely uncommon either. Doing a good retrospective that leads to real improvements in the next iteration is hard. I find that often, team members are disillusioned after going through retrospective after retrospective without ever seeing any real improvement in how their team works. This is often an effect of doing the retrospective in a way that does not lead to doable results. Stand up meetings are also hard, all to often they consist of one person talking – the “team leader” or the person who has the floor – and the others dozing off. The other practices are also hard, even harder, because here you need to coach your customer and make them realize that it isn’t possible that everything has top priority.

Key Agile Developer Practices

It was surprising to me that so few of the key agile practices for agile software development are really coder related as such. All the practices impact developers but very few of them are directly developer related. The coder related practices would be automated unit testing, collective ownership, refactoring and TDD.

My one piece of wisdom in this category is that you need to start doing these things early. Even if you wait just a few weeks you will find that adding test cases, refactoring etc is much harder. One of the advantages of doing TDD from the start is that chances are that your design, modularization etc will be better.

What about Key Agile Principles?

Why all this talk about key agile practices? What happened to the key agile principles as set forth in the agile manifesto etc? Wouldn’t it be better for agile practitioners to take those to heart and let the practices sort of emerge from a proper mindset?

The mindset versus practices debate is age-old. It has “plagued” people for millenia and predates agile by far. From a practical viewpoint, practices are observable and measurable while principles and mindsets are not. In as far as agile researchers, coaches etc need to observe and give advice to practioners starting with something observeable is more empirical and more practical. And being empirical and practical is an agile principle.

Conclusion

Many of the key agile practices are related to product quality and customer interaction while only a few are directly related to development.

References

[/bibshow]