With most organizational change, after someone figures out the right or best way to do something, that way of doing it is captured as a “best practice” and shared with everyone else. For some types of work, collecting and reusing best practices is a tremendous aid to the change effort. An organization that is selling a product to a new type of customer may, for example, capture best practices for overcoming objections from potential customers. When transitioning to Scrum, however, collecting best practices can be dangerous.
Although team members should always look to share with one another their newly discovered good ways of working, they should resist the urge to codify them into a set of best practices. What’s good for one team may be too prescriptive for others. For example, one company I visited had decided that all daily scrums needed to be held no later than 10:00 a.m. I found this an extremely unnecessary dictate. I’m not entirely sure what purpose the dictate served, but many employees interpreted it as a lack of trust by their management.
Even a good practice can lure teams into a false complacency once it has been established as the “best.” Like sirens singing to us from the rocks, best practices can tempt us to relax and stop the effort of continuous improvement that is essential to Scrum. Mary Poppendieck quotes Taiichi Ohno, originator of the Toyota Production System, as saying that “there is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over.” Ohno goes on to say that if we establish something as the “best possible way, the motivation for kaizen [continuous incremental improvement] will be gone.”
In Scrum, sharing success stories and methods that work is a good idea. Establishing one set of solutions as the best is not. Don’t limit the very improvement you are seeking. Instead, let your organization’s standards evolve with you as you grow more agile.
For more information on this topic, see Succeeding with Agile: Software Development using Scrum.
Best practices are dangerous but are often a good way to start. Best practices need to be adjusted to the context, then lead to standards (just enough) done by and for the team.
Once the standards done, they can evolve ! It’s only when you build your own standards, that you can challenge it and improve it.
There is a major cultural change to do in the way we see standards ….
Reminds me of a scene from “Life of Brian”:
Brian: “you are all individuals!”
Crowd, as one: “yes, lord, we are all individuals!”
Why do teams treat stuff like best practices as blueprints which can be applied without thinking?
I agree the use of “best” practices and its connotation is dangerous when adopting Agile; it is really the word best that conveys the wrong message.
It is only a “best” practice if it works for you in your particular situation, what may be a “best” practice to one team may not be a “best” practice to another team in their given situation.
I define a “practice” as a common approach for doing something with a specific purpose in mind.
Examples of practices would be:
- Daily standup
- Continuous Integration
- Mastering Iterative and Incremental Development and Delivery
- Test Driven Development
- 4 Level Planning
I have found having a set of practices, which folks can reference as a good thing.
As long as the set of practices evolve and are not looked at as a recipe for success.
Remember, “Individuals and interactions over processes and tools”
Insisting that all Daily Scrums should take place before 10am is something I have been tempted to do myself, since I am generally an early riser – but as someone pointed out, and I quote: “Shouldn’t that be up to the team itself, as it is part of the team’s self organising?”
There might be a good reason behind a desire to hold all Daily Scrums before 10am – for instance, the information surfacing in the Daily Scrum is to be used elsewhere in the organisation, e.g. in a Scrum-of-Scrums at 10:30. “All Daily Scrums are to be held before 10am” is not a best practice, but it might be the right thing to do for a specific organisation. And, to avoid the employees taking this as a lack-of-trust, the reason why should always be explained. (Sometimes Management actually have a good reason for what they’re doing!)
When implementing a best practice, one of the most important tasks is to explain the “why” of the practice to the employees:
Why do we have a Daily Scrum? Why daily? Why standing? Why no more than 15 minutes? Why should it be done first thing in the morning? Why is a Sprint only 2-4 weeks? Why can’t the product owner change the Sprint Backlog during the sprint? Why, why, why, etc…
Employees who understand the “why” are more inclined to follow the best practice, and having followed it a while – more likely to make creative suggestions as to how the best practice can be improved further. (They are also more likely to read up on Agile blogs, parttake in discussions, and thereby understanding more of Agile)
This is a fantastic post Mike, and one I think that enterprises will need to keep in mind. Small businesses are always looking for a better way to do things, as opposed to larger companies that want to know “the” best way to do it and go down that road. Huge difference. The former is kaizen and the latter is stagnation.
Couldn’t agree more. Managers seem to fear or distrust the absence of “standards” against which they can measure compliance and consistency. When teams organically adapt on a continuous basis we are better able to influence what really matters…process outcomes. Maybe it should be added to the manifesto:
We value Process outcomes over Procedural Compliance
Great point Mike. Collecting this information is very important, but setting “best practices” forces focus back on the process instead of success.
Sharing this information as “success stories” allows people to find implementations that have been successful but do not set any expectations of how this “must” or “should” be done to leave room for continuous improvements.
I think it’s still a good idea to document somewhere what a good way of working is for a certain team or company. You can only know that you are improving a process if you know what the baseline is. A not documented baseline is not a baseline I would say.
But I agree that calling it “best practice” makes people lazy and they will just switch off their brain.
Maybe we should call it “best practice so far” or “best practice until the next sprint review meeting”.
I recently attended the UXCampLondon (http://uxcamplondon.org/) and at the Agile/UX beanbag session there were a couple of ‘experienced’ Agilepeeps who were dictating to all the others (struggling with Agile/UX) that ‘you have to do this’ you have to do that’ ‘you have to do it all in 2 weeks’ etc… I was astonished at such dictatorship.
I sat on my beanbag thinking exactly the same sentiment in this post, that you need to be aware of the processes/best practices, but what’s better? stick rigidly to the rules and fail. Or intelligently interpret the established ‘rules’ and ensure they fit within the teams/organisation…
Through adaption you might even discover a new different, even better way of doing something that you can feedback into the community.
Thanks Mike for a concise, easy to read post!
Hi everyone–
Yes, jcQualityStreet, starting by following what others have found to be a best practice is a great idea. It’s one of the reasons I tell teams to start “by the book” (or “by the advice of an experienced coach”). But as Geir points out, teams need to start thinking after a bit and “inspect and adapt” the process to make it its own, which Alistair Cockburn points out as critical.
And, Ådne, you’re right that employees need to be told why something isn’t being enforced on them. My personality is such that I question just about rule anyone forces on me, but if I’m given a good reason I understand, I’ll accept it.
Peter, I love documenting the practices that work. I just try (it can be hard) to avoid calling them “best” especially if that implies “best for all time.” I usually call such things “good practices in context” and describe the context in which I’ve found a practice to work exceptionally well.
Duncan: While I agree with your point that we need to be open to discovering new ways, there are some core things that we probably don’t want to inspect-and-adapt away. I recently read an editorial in a magazine that complained about Scrum being dogmatic about its rule that teams produce something that is *done* within each sprint. It said that the Scrum community should be more open to having testing done in a subsequent sprint. I argued with the editor of that magazine that this was like telling a vegetarian they should be more open to eating meat. Maybe they should, maybe they shouldn’t. But if they did, they wouldn’t be a vegetarian any more. I don’t think this applies to the UX Dictators you encountered. But I can see myself being dogmatic about a couple of things.
Thanks for the comments.
Best topics in agile_development for 2009-11-12…
Best topics in agile_development for 2009-11-12…
[...] and ways to make them better. Keep in mind that in Agile, the idea of Best Practices can be dangerous. What I’m talking about here is more the bad habits and pitfalls that can happen with [...]