The Last Sprint – Has Agile helped us deliver?

As I’ve been discussing in previous posts, we’ve been working on an Agile transformation here at Telensa.  This is wide-ranging and covers many areas on which I’ve written articles – reporting, roadmaps, structure,  training and approach.  I’m sure I’ll write more on the approaches we are taking.

But implementing the change is one thing.  The proof is in seeing that approach deliver.  So I’m taking the opportunity to think about:

Has Agile helped us deliver?

Our journey

We started on the agile journey ramping up slowly with a single team running Scrum.  It’s a good place to start.  It lets the organisation get comfortable with the language, the concepts and the culture as we trained the teams and built some infrastructure.  That phase went well enough to push Scrum out through the organisation.

The next challenge was a step harder.  We were looking at a pivot – a fast delivery of a new product representing a change of direction.  Moving into a new product area means you don’t know all the answers.  We had previously run into the problems of using classical project approaches in this situation.  You can get stuck trying to generate a specification, or committing to estimates and dates.  It can be really hard to build momentum if you’re trying to learn every detail before you start.

Scaling

We wanted Agile to help here.  But one challenge was scale.  We now had three teams working together on the pivot.  Scrum is focussed on one small team and doesn’t say much about multi-team working.  This scaling can be a challenge for new Agile organisations.  We wanted to manage more people, with cross-team dependencies.  Most critically we needed to ensure that the teams aligned towards the vision.

We borrowed the “program” layer from Scaled Agile.  We’re not using SAFe directly (we’re probably not yet at the scale to need it) but we have found many of the concepts very helpful.  As I’ve written previously, SAFe gives you Scrum working at the stories and iterations level, but adds in a level of features and program increments.  We found this partitioning really useful in ensuring that everyone manages the difference between pulling stories off a team backlog and involving the business in feature prioritisation.  Except in the very simplest cases these are quite distinct.

So the last few iterations we have been using SAFE “PI Planning”-like sessions which focus on progress on the product and the vision and prioritise the features.  To be clear, we are not (at present) replicating the details of the SAFe rituals (SAFe is prescriptive about how PI planning should run), but we are aiming at the same end goal.

PI planning … includes a presentation of business context and vision followed by team planning breakouts – where the teams create their Iteration plans and objectives for the upcoming PI. – Scaled Agile

We have learned that these meetings seem to work and I’d recommend others consider this approach.  We run these planning meetings with physical cards, everyone in a room and lots of discussion.  I’d recommend allowing plenty of time.  And cakes are usually good too.

The last Sprint

This week we had the last planning session for this release, feeding into the final sprints for the teams.  There was a certain amount of pressure for this meeting.

Could the teams commit to enough of the remaining stories to have an effective product?  Would the dependencies line up?  It’s a tight timeline with challenging new work and no-one walked into the planning meeting knowing the answer.

before

At the start we made everything visible.

What had people asked for?

Would we achieve a Minimum Viable Product?

What new work had appeared?

How did the remaining work match the skills of each team?

There was a lot there…

We went through everything.  Slowly we started to get agreement.  Everyone discussed the details of the remaining features and how they would break down into stories.  Teams pulled the features they felt they could achieve.  They traded features between teams to fit skill gaps.  People compromised on their favourite features to focus on what really mattered for the MVP.

after

Slowly the board cleared.

The critical items became clear.

And finally the board was empty.

Every card had been pulled or agreed it wasn’t needed for the MVP.

We had an achievable plan.

Thoughts

There’s still one Sprint to go.  We have to close this out and deliver.

Our first cross-team Agile development has not been easy.  We’ve learned a lot about the product and about Agile.  We’ve argued a lot (again about both).  But I can safely say we would not be at this point without Agile working.  Agile has given us the space to incorporate the learnings and to have the arguments.  The teams have responded with focus and enthusiasm.

What saves a man is to take a step.

Then another step.

It is always the same step, but you have to take it.

Antoine de Saint-Exupéry

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s