Agile Is Not a Religion

Agile is not a religion and following it at all costs will not save you. In fact, it could really hinder your efforts if you don’t look out for some common pitfalls and know when to adapt it for your team and business.

What Is Agile Anyway?

Roughly speaking, Agile is a series of repeatable tasks for helping teams of people work out what is important and helps them to get it done. What makes it different from traditional project management is that it is a physical and collaborative process, rather than something managed by a person or piece of software.

There are lots of flavours of Agile, I’ll just talk through a common example:

• We usually start with a Sprint – a defined period of time where we want to get a number of things done. Usually 2 weeks.
• From the road map and input from key stakeholders, we pull out some of the work we would like to do.
• We write them on cards in a way that makes sense to any reader. Who is it for and what is the outcome we hope to achieve.
• We then assign a business value – is it small, medium, large or extra large – we call these the T-shirt size values.
• Then the development team attempt to assign an effort value – how easy or difficult is it? This can be in t-shirt sizes or point values.
• We then identify the high business value and the low effort cards and add more to the Sprint until we think there is enough work.
• We put them on a wall with columns – To Do, Doing, Tech Review, User Review, Done, Measure.
• Every day we meet at the wall for a Stand-up and talk through all of the cards, what is happening with them, are there blockers and are we still on track.
• We move cards across the wall as we get them done.
• At the end we can work out how may points we delivered compared to what we thought we could do. We learn and get better at estimating, we can develop velocity charts and work out our burn rates (how much work can we get done and how quickly).
• We run a retro (retrospective) and openly discuss what went well, badly and put things in place to improve next time.

It’s a great tool and really helps us focus on the moment. However, there are a few common issues to watch out for:

1. It’s not a religion: Some teams obsess about the process and get lost in the discussion about how to set values or objectives, rather than a best effort to get moving. Agile is a tool, not a set of rules.

2. Too much detail: It is hard to stay on top of what is going on, if you can’t make it to stand-up everyday or you need to understand at a higher level, stand-ups are very detailed and so you need to find a way to keep all stakeholders up-to-date.

3. Random work: No cards should be on the wall if they don’t help you achieve your business goals and these need to be vetted by your product or business owner first.

4. Owner Bias: Technical teams often feel like ‘their’ cards are not prioritized and work on them anyway, adding them up later and Product or Business Owners can push their own cards and not those of other teams (marketing/operations) – a producer can help with this issue, they are an independent manager of the workflow and help the group decide what is important across departments.

5. Roadmap, schmodemap: The road map can become a slippery slidey game of snakes and ladders as new things are constantly added and you slip further behind. Make sure you find a way to keep your eyes (and your teams) at the horizon and not at your naval.

6. Workarounds: In larger organizations, Project Managers end up working around Agile to provide visibility to the business about what is being done on the floor – try to find ways for everyone to help with this, instead of making the project manager feel lonely.

7. Fragile: sometimes teams are so Agile they are in fact fragile. Working on the fly is all very well, but we must keep our eye on the horizon so that we don’t lose our way.

8. Dev-signing (developing and designing): Scoping of the work needs to be done in advance or your developers are stuck waiting for designs and requirements that aren’t ready – often this creeps in to the Sprint. Don’t get me wrong, I love having developers part of scoping and defining, but a little before the work begins, so we can more accurately estimate the work effort.

9. Collaboration not committee: Just because we’re asking for input and ideas, it doesn’t mean we all have to agree. At the end of the day, a person will need to decide on the priorities, with knowledge of all the options and the business goals.

10. Trust and respect: If your team don’t respect and trust each other, no amount of Agile or any other process is going to help them - and although last, this is probably the most important point.

We talk about the important measures of success and things that aren’t on the board. It lasts about 20 minutes and is always valuable. We’re always looking at ways to improve the way we work, but we try not to obsess too much and let the tools help rather than hinder us. However, we also have some of the necessities for running a business, like a strategy and plan of how we hope to achieve it.

Work doesn’t begin and end with the wall.