Yes, There Are Best Practices

December 2, 2013 — Posted by Al Shalloway

The term “best practice” has admittedly been mis-used.  But I do not think it should be abandoned.  It is true that the term has been used to search for a common practice everyone in an organization should use.  Or worse, as an approach advisable to all organizations.  I do believe using best practices in this manner is not healthy and carries significant risks.  The irony is that many in the Agile community rail against this type of best practice while promoting those of their own.  For example, many Scrum consultants I know have several they hold to, including:

  • Have cross-functional teams
  • Work in iterations
  • Have a Scrum Master
  • Have a Product Owner
  • Daily standups
  • Measure velocity

I have not found any of these to be universal. Interesting that these almost define Scrum.  The Kanban Method has it’s own:

  • Start where you are (not decide on your approach based on where you are)
  • Explicitly manage WIP in the workflow
  • Don’t have iterations
  • Don’t estimate

Note, I am referring to the Kanban Method here, not Kanban as most folks I know who use Kanban espouse (I have written several blogs and we have several webinars that discuss the difference between these).

I agree that universal best-practices don’t exist.  It’s why Net Objectives pulls from the practices of Lean, Kanban, the Kanban Method, Scrum, XP and other places to guide our clients in their endeavors.  However, I do believe that if you do a simple classification of teams by the type of work they do, that for each of these sub-groups, it is possible to come up with several practices that are very powerful for 80+% of them. Let’s do a simple, incomplete, classification:

  • Cross-functional teams doing development
  • Development teams that are mostly cross-functional, but are missing a few key people who cannot belong to any particular team
  • People doing maintenance work
  • A team responsible for maintaining shared system components for other development groups

Are there practices that should be considered by each of these types of teams, practices that will very likely be very useful for them?  Let’s see:

Cross-functional teams doing development.  These types of teams are excellent candidates for Scrum extended with the Lean principles of explicit policies and managing flow (likely with managing WIP).  This is the excellent context for Scrum. However, these teams will almost certainly get huge benefit from Acceptance Test-Driven Development as well, which is almost always useful in development situations. See our Acceptance Test-Driven Development page for more on this virtually universally good practice for development teams.

Development teams that are mostly cross-functional, but are missing a few key people who cannot belong to any particular team.  In situations like this whether Scrum or Kanban should be used for the team is hard to tell.  But ATDD is likely useful as before.  And, it is almost certainly likely that managing the WIP for the constraining person(s) will be helpful.

People doing maintenance work where each person works on one fix by themselves.  This is usually a natural place for Kanban.

A team responsible for maintaining shared system components for other development groups.  If the organization is doing Scrum, it often is a great practice to loan out its team members to the teams they are supporting.  In other words, these members are temporarily on the team for which the component team is writing software for as well as the component team.  These means working side by side with the supported teams and going to the daily standups of both teams. This creates a cross-functional team as needed.

Best practices aren’t just for teams, however. If the development part of the organization is working on too many, too large projects, using Minimum Marketable Features and managing the WIP at the portfolio level is almost certainly a good practice to start with.

At scale, there are many essential best practices:

  • Portfolio management
  • Have a team in front of the teams decide what they need to work on
  • Have teams work on iterations that are in synch with each other
  • Strive for continuous integration
  • Manage dependencies across teams
  • Use mocks when useful

The challenge in saying there aren’t any best practices is that we tend to relearn what works.  We should be asking ourselves – “in this situation, what practice has shown itself to be successful 80+% of the time?  Should we use that?”  Note, there is no blind following.

It is tragic, in my mind, that people clamor for answers with the answers being given in the form of practices.   All too often someone has a good approach in certain situations, creates a certification program in it, and we then ossify the knowledge of that approach - having some person of authority we look to.  Scrum (Scrum Alliance, and the Kanban Method (LKU) have taken this approach, amongst others.   Some have claimed that the Scaled Agile Framework is doing that on a large scale now.   However, that is not its intent.  SAFeTM is truly a framework with practices built into the framework.  As a contributor to SAFe we are obviously biased.  But I have worked closely with several of the Scaled Agile insiders and swapped out practices, within the framework, with no one telling me I shouldn't be doing that (unlike all of the afore-mentioned organizations). 

But couldn't the framework part of the Scaled Agile Framework be wrong?  Well, again, SAFe is for particular contexts:

  • large organizations doing Scrum and having challenges to scale
  • transition initiative being led at the director level or above
  • a development group of at least 100 people and not merely comprised of independent teams
  • a culture that can make a big shift when they understand why to do so

SAFe is based on principles that apply in all situations, primarily Lean-Product Development flow and the nature of human interaction. If you want to learn more about SAFe, look to our SAFe Resources page. Or, better yet, attend our free, upcoming Day of SAFe, December 9th.  After the event I’ll post the recordings to illustrate what I mean. In particular, watch the What You Must Attend to to Achieve Agile at Scale: And How SAFe Does. This is useful whether you want to do SAFe or not, as are many of the other talks.

If you are having challenges getting your Scrum teams working together yet aren't ready for SAFe, you might want to consider our new Multiple Scrum Team Workshop.  As always, if you are having challenges at scale, or other development challenges, please contact me if you'd like a free consultation.

Al Shalloway
CEO, Net Objectives

BTW: we currently have two public SAFe courses scheduled in Seattle and Atlanta.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Hi Alan!
One of the things I liked about Software Patterns versus "Best Practices" is that the former supposedly identified the problem and context for their applicability, whereas the latter left it pretty nebulous. In order to call something a best-practice in the universal sense, the "thing" had to be so broad as to not convey enough concrete information about how to do it or apply it situationally.

Portfolio Management is an example here. Is it a general best practice? Sure, but now tell me how to go about doing it in any general manner that is concretely useful? you cant - at least not at the practice/practitioner-level. You end up having to describe it as a discipline rather than as some concrete practice, and having to convey the knowledge and principles of how to figure out how to apply it, instead of merely how to execute it.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban