Five Common Mistakes With Agile

As Agile becomes more mainstream, it seems that the number of misconceptions surrounding it grows rather than shrinks.

In an effort to address some of the common mistakes made when integrating Agile into your daily working practices, I’ve compiled this far from exhaustive article in the hope that it gives you food for thought.

Here are some of the more common mistakes that I’ve seen as a Professional Scrum Trainer:

Mistake #1: Thinking Holding a Daily Scrum Makes You Agile

Just as going to church once or twice won’t make you religious, the simple fact that you’re holding Scrum meetings doesn’t mean that you’re now Agile. The Daily Scrum is a vital part of Scrum, but just holding it for the sake of it doesn’t do anyone any good.

In order to get the most out of the Daily Scrum, it’s important to stick to the core principles of the event, no matter how difficult it seems. The point of the Daily Scrum is for the Development Team to review and plan their progress towards the Sprint Goal. It is also a forum to allow you to identify potential problems and deal with them Q-U-I-C-K-L-Y or later. It is designed to be short to surface issues and ensure (a bare minimum) level of on going Development Team communication and planning as the Sprint progresses. It is rarely enough on its own and is designed to work out the things the Development Team needs to spend more time talking about and dealing with outside of the Daily Scrum. 

Mistake #2: Thinking a Scrum Master Has To Be the Project Manager

Let’s examine the role of a Scrum Master for a moment. It’s this role perhaps more than any other that people struggle with when implementing Scrum into their working practices.

Some people assume a Scrum Master is the same as a project manager; others assume it’s the same role as lead developer. Neither is accurate. A Scrum Master is likely a role that you’ve never seen before.  That doesn’t mean that a project manager can’t do the job, but it’s certainly not a fait accompli.

A Scrum Master is someone who is there to coach and facilitate; they do not technically manage the team. The Scrum Master offers guidance and advice to the team as well as to the product owner, especially with matters regarding the Scrum framework

You might want to let your team decide who should be the Scrum Master; it doesn’t have to be anyone in particular.

Mistake #3: Making the Scrum Team Too Big

Ideally a Scrum team should be a small dedicated unit working closely and organising itself. For that to happen, it can’t be too big or unwieldy.

I subscribe to Jeff Bezos advice on this one: the co-founder of Amazon.com postulated that the ideal team is the size of two pizzas – i.e., only as many people as can be fed by two pizzas. It’s up to you to determine just how hungry people will be and therefore how far the pizza can stretch.

Mistake #4: Getting the Wrong Product Backlog

Product Backlogs come in many forms. The initial requirements gathering phase sets the groundwork for everything that follows. Get this wrong and you could set your whole development off course.

If you are making use of User Stories, it is best if they are written by the closest person you can find to the Customer. Often this will be your Product Owner, but they can enlist help if the task is over whelming.

As a general rule, aim for the following information –

Specific person/ role WANTS new feature/ issue that has to be addressed BECAUSE specific benefit that it brings to the consumer + acceptance criteria (used to confirm that a Product Backlog Item is completed and working as planned).

Without any one of these criteria, your user stories are incomplete and you should think carefully before attempting to start technical development work on them.

Mistake #5: Thinking You Don’t Need To Document Anything.

Yes, the Agile manifesto says that we value completed functionality over comprehensive documentation BUT that’s not the same as assuming you don’t have to document anything at all.

Whereas in the pre-Agile days, you likely had to document everything from requirement and technical specifications to test plans (everything apart from your inside leg measurements), you now only have to document that which is truly valuable.

This could include your source code, for instance, and/ or a short document on your architecture. Whatever you do decide to document, remember the principles of Agile and make sure that it is useful to the product in some way. If it isn’t valuable, chances are you don’t need to write it.

As a final note, let me just say this: feel free to reject any of the advice above (and any other tips you get) if it doesn’t work for you, your team, your customer or your company. Agile is not a one size fits all solution so don’t feel that you need to hem yourself in with any aspects that don’t work for you.

Don’t be afraid to throw away the book (as opposed to throwing in the towel) now and again if you need to.


Share this Post

Leave a Reply

Your e-mail address will not be published. Required fields are marked *