Managers Protect Your New Agile Teams

One of the key tenets of agile software development is transparency. The team visualises work by using physical boards to show the current state of the work in open sight of all. However, if your new agile teams are working in an organisation that’s not used to this, expectations can quickly destroy them.

All Fired Up

You’ve been on the Scrum training, you’re all fired up and passionate about delivering value faster, with high quality. The team’s trained and ready to go. Your customers are happy to hear that they’re going to get something valuable faster.

You start your first ever Sprint with both the euphoria that comes with starting a new project but also using a faster delivery framework. You tell your customers to come back in two weeks for the Sprint Review, (you’ve read the blogs that say most Scrum teams use two weeks) and off you go.

Time passes.

You’re now into week two of the Sprint. It’s the daily Scrum. You all look at the work on the board and finally someone calls out what everyone else is thinking.

“We’re never going to get all that to done in a week without a miracle.”

The team then start to work longer hours. Individuals start work on any unstarted stories. You all reason that at least then you’ll stand a chance of finishing them before the end of the Sprint.

The day of the Sprint Review comes around. You’re removed as many of the impediments from the team as you could. You’ve ordered in pizzas every night from the best pizza shop and barista made coffee throughout the day. Still you all look at the board and out of the 15 stories you took in only 5 are done and the other 10 are all in progress.

Crash and Burn

You start the meeting by explaining that the team will demo 5 out of the 15 stories the team committed to as the others aren’t quite ready yet. Before you get anywhere near demoing anything the customers express their annoyance at the team not having completed what they committed to.

You try to explain that you’ll still get the unfinished stories complete but in the next Sprint.
“That’s not the point. You’re already behind and we’re only two weeks in!”, says the key sponsor.

You’re now in a bad place. Don’t get here.

Although agile describes being transparent it doesn’t say be naive. You need to have the time to build an ecosystem in which agile can survive first.

You need to have time to practice and build trust.

You do this through proving the value whilst protecting the teams by giving them space to learn.

So having made the same mistake myself, here are some techniques I’ve successfully practised to keep credibility during these critical early days of transforming to agile delivery.

Do Less, Then Do More

You can always pull more from the product backlog into the Sprint if you get everything you’ve committed to done. So for the first few Sprints commit half of what you think you’ll get done. Once you’ve done all those then bring in more, but only a small number, and get those done. Keep the classic phrase - under promise and over deliver in mind during the early days of Scrum adoption. This will help build more trust than continually under delivering.

I’ve never seen a team deliver more than they’ve committed to in their first ever Sprint without this kind of advice. Combine this approach with the other ideas listed below.

No Mystery

Warn the customers that in the first few Sprints the team may not complete all the stories they commit to. Things will get better as you and the team learn how to operate Scrum in the organisation. Explain that the team is learning about noth the requirements and also their capacity and how to survive the ecosystem (finance, audit etc). This works well if you already have the customer’s trust.

One for Me - One for You

When you’re in a more challenged environment, where you need to establish trust I’ve found the following approach works better to build the trust.

Have a customer Sprint length of four weeks and a team Sprint length of two weeks. This allows the team to fail the first Sprint in private, learn and adapt for the customer Sprint.

Survivable Experiment

Combining the above techniques gives your early teams the chance of success. It keeps the transparency at the right level for the organisations ability to operate with the truth.