7 ‘IAQs’ when implementing Agile

Agile in Learning team
Agile in Learning
4 min readFeb 28, 2017

--

That’s the ‘Initially Asked Questions’

If you’ve already read; ‘How to become an Agile team’ series and ‘Ready to Sprint into Agile?’, then this instalment will help you answer some of the trickier questions you may get from your team.

These are all real questions we faced from our team when implementing Agile. So odds are that some could apply to you too.

  1. What’s wrong with the way we’re doing things?

Inherently nothing. Most teams working in a traditional way, do so pretty well. The key point is that it’s not about people under-performing or doing anything wrong. It’s about experimenting to see if there’s a better way of working. What if you had more visibility of what people were focused on, more opportunity to work together as a team on one goal, more varied and valued work? An Agile approach can help with this.

2. But where’s the project plan?

For us, there is no traditional ‘project plan’. There’s the current sprint board that has the ‘now’ work. And the backlog board that has the ‘future’ work. Priorities in the backlog may change, which means the work may change. But in essence the sequencing of the work and the ‘plan’ will always be driven by whatever the business priorities are. So you could say it’s a flexible plan.

3. What about my BAU that’s not part of the Sprint?

It’s normal to have some level of BAU activity in, and around, the sprint. As a member of the Sprint team, you need to share about what’s pulling you away from the sprint, when and why. That way they can plan around your availability. The Planning sessions and Standups can help air these. Beware being the team member who’s always too busy with BAU. The team will spot this pattern super fast and you can expect some direct feedback in the Retrospective.

4. So who tells who to do what?

No one tells anyone. This is about a self-organising team. It’s up to you as a team member to pick a task and move it from ‘To Do’ to ‘Done’. If tasks aren’t picked up or people don’t work together, then the PO’s not going to get their output. The truth is that this rarely happens, as people have a tendency to ‘take one for the team’ and pick stuff up. And if they don’t have this tendency, again, the team will spot it quick smart and usually call it out.

5. What about people picking ‘my’ stuff or I don’t want to be involved in ‘their’ stuff!

You’ll naturally be drawn to tasks that suit your skill-set or interest, and you’ll probably avoid those that aren’t! Which is fine. The good news is that no-one’s going to tell anyone what to do, you can pick whatever you want from the list, or even double-up if you like. There may be some obvious sequencing and discussion with the team, but essentially it’s up to you. However, the flip-side is that as a sprint team, it’s your collective job to complete it all. It doesn’t matter who does what, it’s all got to get done. Inevitably ‘those’ avoided tasks don’t seem so bad when there’s a showcase looming and the team needs to get everything finished!

6) Doesn’t ‘Minimum Viable Product’ just mean unfinished or basic?

Nope. Think of it instead as the core requirement you’re fulfilling first. There’s no point in producing something that’s full of bells and whistles without knowing first if the foundations are right. If these are right ( via a test with the intended audience) then you can start enhancing the solution or product. One iteration at a time. Constantly testing, measuring and learning. That way your output will be what people are after, and you’ll have plenty of confidence in it too!

7. How long will it take for the team to get onboard this Agile train?

There wasn’t a magic moment where the whole team suddenly ‘clicked’. People just ‘clicked’ at their own pace. Once you get through the first few sprints, people start getting used to the regular drum beat. It then starts to make some sense. And then the team starts coming up with clever improvements. It’s around then, that you know they’re onboard! We also accepted that, like almost everything in life, Agile wasn’t going to suit every single team member. We haven’t had to deal with the impact or consequences of having someone who wants to go back to the old ways, but we imagine this is where the role of the good old line manager and performance management may need to appear for the first time …

This article was written by Tracey Waters and James Perez

--

--