Necessary Conditions

Note: Partly revised 4/7/2022.

People often try Scrum without getting the following conditions.  I do NOT know for a fact, from lots of experiments, that the following conditions are “required”.  But I do think I have enough experience to recommend that you try to achieve these conditions as soon as you can.  And that you will then (likely) be more successful.

Why?  Why do I hedge?  Well, a Team is a very complex human system.  Many moving parts.  No one really understands it.  We don’t understand one person.  Much less a Team.  So, it is probably true that “one team” can achieve really good results without one or more of these conditions.  But, my eyes tell me that not having these conditions is at least reducing your odds of success or lowering your level of success.

To have a decent Agile-Scrum Team, here are my conditions:

• An important set of work
• An ability to define that work well enough (clearer requirements)
• A team that wants to do that work — an inspired team would be great
• A team that is willing to try Scrum
• The courage to face the truth
• Someone who knows Scrum well enough to explain it accurately (not a beginning SM)
• A 100% allocated and stable Team

Note: For some people, it does not take courage to face the truth.  But it commonly does for lots of people.  And for organizations.

Note: If you don’t have all of these, I think you can start.  But you want to fix these impediments as soon as you can, as much as you can.

Here are some more conditions:

1. A team that is not dysfunctional
2. A team that is capable enough (right skill sets)
3. A willingness to identify enough impediments
4. A willingness by the team and the organization to change things to fix impediments
5. The thoughtfulness to add to Scrum usefully
6. The ability to get decent feedback each Sprint

Can you be successful without these?  I suppose so, depending on who you are competing against.

But aren’t these reasonable conditions that management should provide so that a Team can be successful?

Note on 100% dedicated:  Depending how you read this idea, this can be very difficult.  The first key thing is that it is clearly valuable that the Team focus on one “release” of one product. (Why I will discuss elsewhere.)

In real life, other important things come up.  In general, the organization should have fairly quick releases, and allow the Team to mostly focus on their (singular) release.  AND, there may occasionally be some small pieces of work that “can not wait”, but the distraction of this work is small and well-managed.

In the field, what I see, in most firms, is that it is not well managed yet.  First, they do not see the huge loss of productivity of endless (seemingly) context-switching and project-switching.  So, often they basically do not try to manage “interrupts” of this sort.  When some organizations do try, they do not do it well.  Or so I see.

But, if the firm and the Team actively manage these interrupts, then I think there is a reasonable compromise.  And so, logically, to some degree the Team will not be exactly 100% dedicated to the current release.  And in that sweet spot, that would be good and right.  The most important stuff is getting done with low trade-offs, low costs and delays.

« « If no Team, then Scrum events are crappy || Agile Release Planning Webinar — Context and Basics » »