Best topics in agile_development for 2009-11-12…

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.

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!

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”.

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.

We value Process outcomes over Procedural Compliance

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)

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.