Written on June 3, 2019
Author: Lewis Gavin

How to avoid common Agile pitfalls

Photo by [David Travis](https://unsplash.com/@dtravisphd?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral) Photo by David Travis on Unsplash

This is a brief post outlining what I’ve learned working in a number of agile teams. I’ll talk about what worked well and what failed miserably in the hope that you can learn from this and implement decent agile workflows in your company or improve on existing ones.

What does Agile mean to me?

Like anyone 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”.

When looking back at this, no-one had no idea what it meant and none of these things were particularly true. However they are said so often, usually by people who don’t understand or really want it to take off, 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.

[Image Source](http://anagilemind.net/2015/02/07/collection-of-agile-related-memes/) Image Source

With all this in hindsight, Agile to me is a culture that should promote collaborative working with a customer and iterative and pragmatic engineering. Teams should concentrate on what they 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.

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 get used to as a developer is that you basically work on whatever task is available in the backlog/sprint. Everyday you keep your team in the loop and you drive the work you do. Now this only works if you have a well planned sprint or prioritised backlog, something the product owners should be helping shape.

Photo by [Priscilla Du Preez](https://unsplash.com/@priscilladupreez?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral) Photo by Priscilla Du Preez on Unsplash

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 everything 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 openly tweak and modify the processes to suite you as you have a good understanding of what they are.

Pitfalls

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.

Long standups are boring!: [Image Source](https://giphy.com/explore/bored) Long standups are boring!: Image Source

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).

Lack of real Product Owner

If your customer/product owner cannot help prioritise and organise the backlog and they cannot make time to see the output from a sprint then this whole process breaks down.

Without them, 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 will only result in rework further down the line. Make sure constant interaction with the customer is possible to make sure what’s being built still meets their aim.

A little recap

In all honesty, from my experience people make it way too difficult.

Discuss priorities and goals and constantly review with customer.
Work sequentially through tasks in the backlog. Make tasks small and measurable.
Review progress with customer.
Repeat.

Just keep these few things in mind and you’ll start to reap the benefits in no time and start to develop workflows that naturally work for your team.

It’s a cultural change and it’s all or nothing. Changing the mindset of everyone is the first and biggest hurdle.