So the leadership team is on board with the fundamentals, at least in theory.  You look at your team, and muster up the courage to move forward. Dodging the snares of the mind that would take your sanity, adding another to the legion calling for the end of the world… or at least, really botching a project.

If you are stepping into the role of a Scrum Master, this article is not a substitution for experience as a scrum team member or training. Rather, I want to focus on the challenges a team might face when an organization is shifting to Agile.

Failure as culture

In order for an Agile transformation to succeed, everyone from top to bottom in an organization needs to get very comfortable with failure. It seems counter-intuitive given organizations look to Agile to escape quagmires of sunk costs.  However, in the overall transformation, you will inevitably experience set-backs that will threaten the stability of adoption.  Outlining acceptable failures will shore up the confidence of the team to problem-solve and move forward.

What are acceptable failures?

• Realizing MVP features are much larger than the original estimates.
  • Determinations are made early as to what may not be in the final delivery, if go live will be pushed, or if the budget can be increased to deliver the full release plan.
  • This can be caught early due to architecture slicing and tracking the delivery of functionality for user acceptance.
• Discovering technology constraints or other needs to pivot.
  • By delivering slices, you will find missteps early, allowing you to troubleshoot with the team, minimizing rework and cost.
• Addressing dependencies that become impediments.
  • By managing work through each sprint, impediments can be identified and mitigated in a more timely manner and can be planned for as sprint planning is worked through.

These are some of the common growing pains of teams although there are many more. What’s important is that the organization adapt without placing blame.  Teams may be slow to pick up the pace as they work. Use these as teachable moments to grow rather than evidence to scrap the whole effort.

Teams cannot grant wishes 

Agile is explicitly well-equipped to change on a dime when required.  Evolving user requirements? No problem. Unexpected legislation changes? Sure, let’s prioritize it in the backlog.  The part that escapes the notice of many in theory is what does that mean for a release plan?

To put it another way, if you were out to eat and order a 6oz steak, and 10 minutes later you realize you are more hungry than you thought, the steak in progress of being cooked cannot be made larger.  You will likely have options. You might get lucky and someone else has ordered exactly the same thing and you aren’t out the money.  You may order a second steak and wait for the whole thing to be cooked.  Or if you are ravenous now, you might eat the 6oz cut while waiting for the rest to be cooked and served.  However none of these options will get you the size of steak you realized you wanted at the original time and certainly not for the same cost.  Holding the cook responsible for trying to accommodate your change of heart is unfair.  Work with them and they will get you fed and satisfied as quickly as possible.  Product owners, I’m looking at you.

Lead? Follow? Get out of the way

I have often imagined support groups for new Scrum Masters whether they were previously developers or waterfall PMs.  I’ve seen the loss of control drive them to sabotage of the process or apathy.  This is your time to shine y’all. Instead of competing to be the one with all the answers or micromanaging your team, focus on your role and be the servant leader they need to remove blockers. Put those soft skills into action and watch the team become empowered and outperform expectations.

You’ve successfully lured the Elder God back to slumber. You’ve sealed the gate. You think you’re safe… until you hear about SAFe®…