Select Page

Getting an Agile Team Started

by | Nov 1, 2016

I was asked recently what working in an Agile team was like.

Wow! Where to begin? At the beginning of course…

We have a standard approach to enagage with teams new to Agile which we adapt to fit each customer. Initially, the whole team go through a half-day end to end Agile session; everyone quickly onto the same page and then we launched into it.

What is the vision for the project? The stakeholders? Assumptions? Risks? A quick context diagram and we were into writing stories.

Experience coaching Agile teams told me that the first few stories are slow and clunky to write, then the team get the hang of it and the stories start to flow. The important thing from my point of view as a coach during this period is to ensure everyone stays engaged. For me, that’s not just everyone contributing to the ‘words’, which is important, but also everyone gets an opportunity to hold the pen. It being mightier than the sword!

I try and cap the story writing at a few sprints worth, with epics to capture the next few sprints. I find that writing a lot of stories up front hasn’t helped as much as I thought it would the first time I did it. For one, the team are unable to write detailed stories too far ahead as it’s hard to guess the future and also they start to leave gaps which only appear as they get closer to doing the do. This is particularly unhelpful as your typical new and slightly nervous Product Owner starts to calculate the number of sprints to complete the project from an unrealistically low number of stories (not very agile, but old habits die hard.)

Over the first two sprints the team rapidly realize that the stories that they’ve written weren’t as great as they thought they were; typically, the acceptance criteria are a bit too loose and they start to learn to write better criteria.

The first two sprints are normally really successful. I put this down to two reasons. Firstly, I work hard to set them up for success; I limit the number of stories going into the sprint. Also the team tend to pick the easy stuff to start with!

Then we get to sprint 3, everyone is happy and velocity is still on the up. Time to push the team a bit harder. Time to teach the team a very important lesson about failure. Sprint 3 is normally when I let the team bite off too many stories or overcommit in one skill area without looking at the dependencies with the other stories. Halfway through the sprint, there are usually more stories to the left than the right or the sprint board, or worse, a whole mess of stories stalled ‘in-progress’!

The team can obviously rescue themselves from failure; renegotiate with the Product Owner for example. But there’s a lot to be learnt from failure. Most important, is that they continue to behave as a team, not play the blame game or bury themselves in their own work to the detriment of others. After all, Agile is a team sport!

By sprint 4 and 5 the team should be getting through the work but this is generally when they become ‘aware’, a bit like Skynet. ‘Oh! We’re a team! I have to keep working with these people.’ It’s this point when a bit of team friction arises and it’s time to coach the team into being a team, not just working as a team.

But we’ll save that for another day!



Geoff blogs from a flat overlooking the intersection of Agile, Business, and Life

Want to read more?

We run regular Data Requirements and Agile data warehouse training courses with an Agile business intelligence slant in both Wellington and Auckland


Start your AgileBI journey with us.

Other steps in the AgileBI Journey

And sometimes a sprint or a scrum.
%d bloggers like this: