Are You Really Agile?

A lot of companies like to think that they are Agile when in reality all they’re doing is adding a few tweaks to their existing waterfall processes.

Genuine agility is a fundamentally different manner of doing business. It takes financial commitment as well as patience; we’re talking training, education, new techniques, the latest tools and a fresh mind-set. The latter is the key here, as is its manner of implementation – as Ron Jeffries’ said: ‘The practices are not agility. They are a way to find agility’.

Every company will localise Agile for its own purposes and that’s fine as long as they adhere to its overall principles. Some teams will also be more Agile than others; that’s fine too. Think of Agile as a spectrum. If you and your company are new to Agile, you might want to start with modest changes and build from there.

What you don’t want to do, however, is to fool yourself that you’re Agile when you’re not. You won’t see any benefit in doing a half-hearted job; it’s then all too easy to claim that Agile has failed your business when you don’t see the results you want. Of course, the fact that you weren’t really Agile in the first place gets overlooked.

So, with that in mind, and knowing how easy it is to fall into that trap, let’s look as some key signs that you’re NOT really Agile. If you can identify any or all of these in your business, you know which areas to tackle next!

Five Signs that you’re Not/Less Agile

  • You and Your Team Are Not Responsible For the Product Backlog Item from Beginning to End.

Whether it’s because you don’t have the right people on board or your current business hierarchy prevents it, if your team is not responsible for an entire Product Backlog Item – from start to finish, including development, testing and implementation – then you’re not really Agile, or certainly less agile than you could be. It doesn’t necessarily mean that the product won’t get launched on time and effectively, just that you’re doing it in a less Agile way.

In an Agile development, the team is responsible from the Product Backlog Item throughout its lifecycle and iterations.  That means that it is only ‘done’ when it has been tested (which should also be done by the same team), integrated and is ready to use. There are many exceptions (as always), and it is of course possible to be Agile using component teams rather than functional teams, but you will usually be less agile under this setup.

  • The Project Manager Assigns Tasks or Decides Timescales

The whole point of an Agile way of working is that the Scrum Team choose which tasks they will to work on, guided by a Product Owner who sets the overall priorities via the Product Backlog. The Development Team determines timescales based on empiricism and their historical learning of how long things take. It’s a step away from the traditional role of the project manager or team leader assigning roles or tasks based on an external priority list. As long as the team is truly cross-functional and all aspects of a Product Backlog Item can be tackled inside that team, the team should be capable of organising the work themselves.

Likewise, it should be the Development Team that decides how much work it can complete during a sprint and not a project or product manager; if that is not happening, you’re definitely not Agile.

  • You Rely on Email for Communication

If the send and receive button is your most common way of initiating communication with the team, you’re missing one of the most fundamental tenants of Agile: face-to-face communication where at all possible. If you have teams based off-site, find ways to minimise the impact of distance and culture. Technology will help with this. Group video calls are easy and free. This will get you a long way, but is rarely enough. Effective distributed teams travel. Some face to face time will be vital. The most successful distributed setup I saw relied on the Product Owner spending 3 days every 2 weeks with the remote Development Team. Don’t underestimate the impact of remote teams on productivity and the increased demands it will place on all involved to be successful.

  • You End Up Reporting

If the Daily Scrum becomes more like a reporting scenario – you are reporting your progress to a project manager or scrum master – this too is a sure sign that you are not Agile. A Daily Scrum is a planning meeting for the Development Team. Reporting inside a Sprint should not be needed as real progress will quickly become clear at the end of the Sprint in the Sprint Review.

If external daily reporting is still needed, it should not happen at the Daily Scrum as it will prevent this event being effective for its intended purpose. If you have to do it, do it at a separate reporting meeting, with as few people involved as you can get away with and keep it as short as possible.

  • You’re Not Improving Your Processes

No matter how Agile you think your company might be, if you’re not holding Sprint Retrospectives and incorporating new ideas into your processes on a regular basis, you’re pretty much stuck in a rut I’m afraid. You may think everything you’re doing is Agile – and for the most part it may be – but never forget that a big part of genuine agility is constantly assessing whether there is anything that we could be doing better.  If you’re not doing that, you’re missing the point.

There are more signs that you’re missing out on core principles of Agile, of course – your white boards are still white, for instance, or as a company you don’t like to embrace change — but these are perhaps five of the most common traps that I’ve seen companies fall into, even when they think they are doing all they can to be Agile.

Tackle these and you’re already one step closer to truly cross-functional and effective Agile teams.

Do You Want To Learn More About Scrum?

TheScrumMaster.co.uk Simple Guide To Scrum Video Course.
Learn Scrum at your own pace and at lower cost. The course includes over 90 minutes of video content and a practice assessment to test your understanding.

TheScrumMaster.co.uk Ultimate Scrum Master & Product Owner Practice Assessment.
This includes 500+ questions and is the best and most comprehensive practice assessment available anywhere.


Share this Post

Leave a Reply

Your email address will not be published. Required fields are marked *