5 Common Agile mistakes

Here are 5 common mistakes I have come to notice in organisations that use an Agile methodology. There is no particular order to these 5, just things I have observed along the way. Some small tweaks are usually all that is required to bring things back onto a better path.

1 Viewing Agile as process driven

More often than not you hear word like “we need to hone our processes”, “how do we fit that into our Agile process” or “we need to get better at following our processes”.

The whole agile movement isn’t a process thing, we had that with Waterfall. What is a process? Lets see what the definition is:

Process (definition)


Hmm, a series of actions or steps taken in order to achieve a particular end. Agile isn’t a prescriptive methodology, you can’t just follow steps and generate amazing bug free software. Agile is about the people, the individuals that make up the team and importantly the individuals and communication between the business. People often forget that there are 12 principles that accompany the Agile manifesto, they’re often overlooked and it seems more important to choose an ALM tool before really understanding the principles and spirit of agile.

Think of a Barista making coffee, they know and understand the temperature to pass through the coffee beans, they taste coffees to see what would be best to serve to customers, they understand the right levels of water, milk and froth to add to a coffee. We can all grab some instant coffee and tip some boiling water into the cup with a bit of red top in the mix but it just isn’t the same thing? I’ve tried making coffee with the same tools a Barista uses and I just don’t understand it to the level they do to make a great Latte.

2 Tooling for management and communication

There are some great ALM (Application Lifecycle Management) tools out there, all have their pros and cons and if used correctly and within the spirit of Agile can be extremely powerful and useful, automatic burn down charts, collaborating with offsite team members ect

What happens in far too many instances though is that the tool becomes the process driver, the source of what everyone does. Its where people go to look for answers, its where people communicate instead of a face to face discussion.

Take something like Jira, out the box its very simple and comes setup nicely with minimal swimming lanes, story points for estimating and is nice and straight forward. This often ends up getting built into something bigger, more swimming lanes, epics used for grouping items, huge interrelated and nested tickets. Streams and streams of comments on tickets that could have been conversations (often out of date and go stale quickly)

Dont let this happen. Understand Agile, try one of the frameworks. Scrum is great, XP is really good…….. blend the too if you like, find out what works but really understand the principles and practices behind Agile before driving processes into your projects with a tool first approach (see first point).

3 Engineering Practices

Okay so you want to be Agile, we can get software out as quickly as possible feature after feature! Let go, lets go fast!!


You will soon get into trouble without unit tests, without automated UI tests. Design and analysis? Yes they are whole phases in Waterfall but in Agile you need to do these activities each sprint. Waterfall does all the analysis and design upfront at the point when you have the least information and knowledge about the product. With agile you need to do little bits of design, little bits of analysis and lots of testing each sprint.

Just watch your velocity gradually slow down the further you get into a project if you don’t do the design analysis and testing properly. Agile is not about going fast, its about getting the right features done at the right time. Maximising the amount of work not done is essential. That’s one of the twelve principles by the way.

So look into TDD, get some good automation testers or better still get the team good at automated tests. Have a build that runs the tests and integrates the code. Have nightly builds that can perform automated tests of the UI. Have a simple build and deploy process. Look into the practices that XP offers as Scrum doesn’t define any, XP goes into depth with the engineering processes.

4 SOLID Principles

Most developers have at least heard of the SOLID principles and a lot of developers even know some of them. Some know all of them (usually for interview purposes) but they so often fall by the wayside. I can’t stress enough how important and how much following these principles can help software development.

By the way please leave a comment if you think it would be worth while me posting more on each principle, they are highly available in books and online sources already

These principles are old, they have been around for a long time. Programming languages haven’t really changed that much in the last 30 years. They boil down to the same things, assignment statements, conditional statements and Boolean logic. The other good thing apart from making your code more testable and adaptable (an absolute necessity with Agile) is the common language and understanding between developers when discussing the problems they tackle.


5 Communication

Agile is about communication, working together to achieve a common goal. We’ve already discussed that its not about processes, not about tools. Developers, testers and business users (stakeholders ect) need to communicate, face to face is the best way.

Individuals and interactions of process and tools

Have you ever gotten annoyed because you got a text message and it didn’t have a (x) at the end? Ever taken an email completely out of context? We have all done it and the reason is face to face communication is the best way to interact with people. They way we communicate is as much non verbal as it is verbal. So get your whiteboards, post it notes and marker pens at the ready. Don’t leave a message to someone in Slack and then wait for a response, go and speak to the person.

I’ve literally been in a room and overheard this conversation.

Bob: Hey have you done that thing I asked you to do in Skype earlier

Jon: Nope, I was working on a backlog item in this sprint, what was the issue?

Bob: Well it was really important, we need to get a fix in before the release this week, it needed to be done by now, why is it not done?

I kid you not that these people were in the same room!

Please talk to each other, make your collaboration space an Agile friendly one, sit and work closely together, have whiteboards on hand. Talk to each other, speak to business users, get the PO involved in the development. Stop handing off code to testers, work together. You’re all on the same team with the same goal of getting the sprint objectives completed.

The daily standup should be so simple if you are collaborating effectively, you will know what each other are doing, you won’t wait until the stand up (daily scrum) to bring up an impediment?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s