28th February 2017

What everybody ought to know about Agile

You have a great idea for a new web-based product/service. It’s going to be huge. So you put together a list of requirements and an outline brief for a shortlist of agencies and freelancers to get some ballpark costs for the development of a minimum viable product.

Before long, you find yourself sat amongst a group of agency types, throwing around words like ‘Agile’, ‘Scrum’ and ‘Sprint’. You find yourself wondering… what do these terms mean? More importantly, how are they going to affect the development process of my product?

‘Agile’ is a collective term for a number of different ways of working when developing software. The Agile Manifesto focuses on 12 key principles.

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximising the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organising teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Where it falls down

Looking at these principles, you can probably guess that Agile is very well suited to bigger projects. Projects with multiple iterations and development cycles which may span months or years. This makes it perfect for ‘product’ companies, where the focus is one main project, or a group of related projects as their main goal. Think, Facebook, or a similar product focussed company.

However, when it comes to client-agency relationships, some of the Agile principles are harder to apply. You and your business, as the client, have different goals to that of the digital agency or development team who work for you. It’s up to the agency to focus on your project for allotted time you’ve paid for their services. Meanwhile you’ve got a business to run, and other things to focus on. The requirement for constant communication and user acceptance of every little feature in development might not work for you – and that’s ok!

Common sense

For a team of seasoned developers, some of the Agile principles should simply be labeled as common sense. For example, principle ten – Simplicity. A developer unnecessarily complicating your codebase is wasting your time and money. They also risk exposing your project to the security and maintainability issues that come with a bloated product.

There is absolutely no good reason to over-complicate something that could be simpler – Agile or otherwise.

Placing trust in your developers is also extremely important (and obvious). If your business has a team they can trust and are happy with their work, they are going to produce better outcomes.

If your business doesn’t trust your development team… why do you work with them? Of course it’s daunting placing your projects fate into new hands, but if the trust isn’t there, you’re simply making more work for yourself by managing a team that should be able to manage themselves. If you find yourself in a position where an agency has given you reason to mistrust them, it may be worth your time, money and sanity either approaching them about the issue or considering finding someone you can trust.

 Striking a balance

Are we saying that Agile won’t work for Agency-Client relationships?

No. But we want to emphasis that the relationship should be beneficial to both parties. If a development house or agency insists on using techniques and methodologies that don’t work for you first and foremost, everyone is going to suffer.

The key is to strike a balance and use Agile methodologies to your advantage. Adopting Scrum or XP because it’s the ‘in thing’ to do serves nobody. Careful consideration of all the project variables – budget and resources, timescales and your intended outcomes – are key to determining the best approach. Is daily collaboration more beneficial for you in place of a comprehensive functional specification at the start of the project?

Remember, the way you work with your agency or team should be a two way street. A conversation at the beginning of the project to define the relationship and your objectives is worth it’s weight in gold compared to a development cycle that is awkward and unworkable.