Written on October 27, 2016
Author: Lewis Gavin

What have I learnt about Agile

agile what I've learnt

This is a brief post outlining what working in an Agile team has meant for me. How it has changed the way I work, and the team work. I’ll also dive into the things I’ve seen that should never be repeated!

What does Agile mean to me?

Like every company new to Agile, to start off with it was all a big illusion. Buzz words and phrases are being thrown around like “death of documentation”, “no more governance and red tape” and “We’re reacting because we’re agile now”. However when looking back at this, we had no idea what it meant and none of these things are particularly true. However they’re said so often, usually by people who dont understand or like the new methodology, that people start to take them as gospel.

One reason this can happen is because Agile is imposed on a team without them understanding why. No team is going to do something just because they are told they must, it should be an organic process where the benefits of Agile make the team want to use it.

With all this in hindsight, Agile to me is a culture that promotes: collaborative working with a customer and iterative and pragmatic engineering - only concentrating on what you can control and building things in small enough chunks that they can change quickly. If you start off with that in mind, you’re ahead of most people who have been introduced to the concept through word of mouth.

What works well?

Small teams

I can’t stress this enough. I’ve worked in big teams, I’ve worked in teams based in two different physical locations and I’ve worked in small teams. Small teams, especially when getting started are great. With a team of 4-5 people you quickly get to understand each other and begin working together. It’s a lot easier to become self managing when there’s only a small number of you - even teams of 10 struggle with self management.

Flat structure

Forget all your previous role definitions. The thing that is most difficult to begin with is the fact that essentially, if you’re backlog has been created and prioritised correctly - as a developer you basically work on whatever task is available, keep your team in the loop and you drive the work you do. I’ve seen many teams struggle to break out of the old “that person is the manager” mentality that they end up doing daily stand-ups and report everthing they’ve done back to one person. That one person then goes on to ask them to do things. This is not self managing and this is not what stand ups are for.

Utilise the guidelines

This may be an unusual one to see, as most people say the guidelines are there just for pointers and that you should do what you feel is necessary for your team/project. However, if you are just starting out I would recommend you try to do things by the book, try and enforce the concepts and use the techniques and processes. This will force you to move away from the way you used to work and let you see why certain things are done. Once you have done this for a while - iterate the same way your product does. You can now more openely tweak and modify the processes to suite you as you have a good understanding of what they are.

Things to avoid!

REALLY LONG STAND UPS! The only thing more painful than being a spectator to a stand up that lasts 30 minutes is being a participant in one. Brevity is key. It’s a key skill that everyone in the team should learn. Explain what you’ve been up to briefly, update the team on whether you’re done and if so what you’re going to pick up next or provide details of blockers to the scrum master. Nothing more, nothing less. If you can help someone out on a blocker or a task, let them know but save the details until after (unless they are brief and useful for all).

Holding too many Sprint planning and Sprint Demos without the product owner. If your customer cannot help prioritise and organise the backlog and they cannot make time to see the output from a sprint then you’re screwed. How do you know what the important features are to build? How can you validate that what you’ve been doing for the past 2 weeks meets the expectation. Best guesses and a mass of assumptions can surely only result in rework further down the line.