I’m teaching an introductory Agile course at Sheridan College and this week we had an interesting discussion around “best practices”.
The Agile community absolutely despises this term, and with good reason. Of course, the Agile community also likes the Shu Ha Ri model. Shu is beginner stage where the person doesn’t know what they don’t know. In this case, they must follow the rule. The rule, of course, being a best practice until they learn how to adapt the rule to their context (Ha) and finally, how to create their own rules (Ri). So if you’re supposed to follow the rule, don’t you need a best practice until you learn how to tweak it for your environment?
The context of our discussion this week was around daily stand-ups, retrospectives and demos. Are they best practices or not? And does it really matter?
What’s a better technique for a team to stay in sync with their sprint work than a daily standup? Mind-melds? Somehow magically being aligned after 1 sprint planning meeting? I’d say a ‘daily standup’ is a best practice, because the purpose is for the team to plan their day and adjust to new information. Is there a better practice for doing this? I suppose sitting together where they communicate in real-time versus waiting to raise important issues at the next standup might be better.
If so, then does co-location become a best practice and daily stand-ups are relegated to good practice status?
What’s a better technique for teams to get into a regular rhythm of improvements? Kanban says improve on demand. Waiting for a retrospective to improve on something is waste. Couldn’t that lead to thrashing, or change chaos if you’re reacting to every problem in real-time? Wouldn’t that make things worse instead of better?
The best practice is to reflect often enough to make visual progress on improving. Whatever often enough means will differ from team to team, but they’re still doing the same practice. Oh, maybe they should be the practice, not do it. Sorry.
We talked about how teams can get feedback from the Product Owner in the event that person is working on multiple projects/programs/products. I suppose the best practice is that they are only working on one so this doesn’t become an issue. What’s better than that? Working on nothing? Some teams I’ve worked with have placeholder daily demos and they show progress if there is something to show, otherwise they cancel it.
The best practice here is to show stuff when it’s done for feedback. What’s better than getting feedback on a regular rhythm that makes sense?
Agile Best Practices
I think the Agile community despises this term mostly due to the connotation of the term. It implies no thought process is necessary which makes retrospectives irrelevant. If you’re doing the best practice, there’s not much point in having retrospectives.
In my view, it’s more about the implementation of the practices as opposed to the practices themselves. Having Daily Standups, Retrospectives and Demos/Sprint Reviews are non-negotiable starting points for any team new to Agile. You don’t necessarily need to co-locate, or strip everyone of their titles, or even be Agile. The easiest way to get started when you’re new is to do these 3 best practices. How and when you do them is what will need to be adjusted over time, but not doing these 3 best practices means there’s not much point in getting started with Agile in the first place.