Agile is a software development methodology rooted in the agile manifesto. Its core purpose is to reduce time spent writing detailed and prescriptive project plans, and to deliver working software more quickly.

It has rapidly become a comprehensive management solution for software teams and creative agencies, and what is good about agile is that it’s flexible enough to be adopted to the specific needs of any given team. There are few hard and fast rules in agile; it is a methodology.

But despite this, agile still remains the hard-sell. It can be difficult to get buy-in from the team or management. Here, we try to dispel some of the prolific myths about agile software development.

It’s too hard

Working in agile requires a shift in mindset. Or rather, a tweak – depending on how you implement it. This doesn’t necessarily mean it’s hard, but it does mean learning something new. And since when did programmers have a problem with learning something new?!

There’s too much to learn

Following on from the last point about difficulty, agile can indeed be a rabbit hole. But you don’t need to scurry all the way down to the bottom. You could start introducing agile into your team by writing your technical specs as user stories, or by breaking your project down into shorter “sprints”, rather than lengthy “phases”. Experimenting with these foundations will help you to develop your understanding further.

It doesn’t work

Sometimes, the naysayers are correct. Agile doesn’t always work. Or, crucially, agile may not be necessary for a particular project. Agile lends itself to teams of developers working continually on something like a web or mobile app. For quick turnaround, low budget brochureware websites, you can get by without agile just fine.

Clients don’t understand it or want it

Because agile is very different to the more traditional “waterfall” approach that has a clear beginning and end, it can be difficult to communicate the process to clients. Typically, the client will have a more clearly defined role in the process, and it will be costed differently. For example, you may charge for sprints (typically every two weeks), rather than the more traditional deposit and final payment on delivery model.

My team is the wrong size

There has been some discussion on agile development team size, and the consensus seems to be less than 10. That being said, dev teams above this size may be broken into multiple smaller teams, making it much easier to manage.

It’s too risky

There are risks when trying something you’re unfamiliar with, especially in business. Anxiety around project delivery, team cohesion and client relationship are all valid concerns, but each of these can be worked through if your team applies itself to implementing agile.

It’s difficult to quote cost

Because agile utilizes sprints there is generally no fixed fee. When embarking on a new project, you must communicate and agree with your client on a “shared vision” which you will work towards. Obviously you must take budget into consideration and build your development plans around this, but agile is inherently flexible and as such, it means you should not commit to a fixed cost at the beginning of the project.

My team is not prepared for agile

It’s quite likely that they’re not. The agile approach takes work, and it’s not the default process which we seem to have adopted in the web design industry (having organically grown out of print). But we have to admit that we have largely sleepwalked into the unstructured processes that many creative agencies and development teams use. Even if you and your team do not feel ready, you can introduce agile practices in baby steps and develop over time.

Always be open to learning as you go!

Like? Share!