What does Agile really mean?

As a technical pre-sales specialist, Jake strives to slay jargon and buzzwords from conversations with customers. Here's his take on Agile and what you need to know about it.

Jake McKenna
Jake McKenna Technical Consultant & Software Developer

In the world of corporate buzzwords, Agile has become as firmly embedded as ‘blue-sky thinking’, ‘synergy’, ‘bleeding edge’ and ‘disruption’. Lots of people claim to ‘do agile’ or work in ‘scrum’ teams, but what does it actually mean?
I’ve asked many people what they think that Agile means, and many don’t know that the term Agile refers to the Agile Manifesto. This is a declaration written all the way back in 2001, and it says the following:

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

To me, this is a perfectly worded statement of how to do software development well, and I’d like to think we are expert disciples of it at Ghyston. Let’s break its main points down one-by-one:

Individuals and interactions over processes and tools

As soon as you have more than one person working on a software project, things get much harder. Unless you’re working on areas of code which are completely separate, you’re going to run into code conflicts, break each other’s code, and generally make each other’s lives more difficult. A natural response to this is to introduce processes and tools, and this can be a great thing. Git, for instance, makes it so much easier for multiple people to work on the same code at the same time, and code review tools help keep quality high.
However, too much reliance on tools causes strain. Anyone who has worked on a large project using Jira knows how comments on tickets can quickly create conflict where there should be none. And code reviews can get heated quickly when an in-person discussion could have been much easier. When we rely too much on process, the reason behind that process gets lost.
If you want to be truly agile, you need to put a lot of trust in your project team to do the right thing. And by putting trust in your staff, you empower them to make decisions, spot errors early on and take action. At Ghyston, we use a combination of strong hiring practices and training in best practices to make sure we’ve got the right people to do the job. We then put our trust in them to deliver the right thing for our customers – and we’ve found that it works.

Working software over comprehensive documentation

Let’s face it – writing documentation sucks. Once you’ve gotten your code to a working state, and made it clean, you don’t want to have to spend more time writing a description of what your code does; you just did that when you wrote your code! I’ve worked on projects before which mandated that every method (even a 3-liner) needed a Javadoc comment. The effect of this was to discourage developers from pulling out methods, and filled the entire codebase with long, difficult-to-follow functions. These kind of rules are just adding needless process to the agile development lifecycle.
We’re big advocates of Clean Code at Ghyston – we give a copy of it to every developer when they join. In it, Robert C. Martin (affectionately referred to as Uncle Bob) advocates that good code should require no documentation to understand how it works – it should be clear from the naming of the methods and the variables. If I need to read a comment to understand what it is your code is doing, you’re doing it wrong. One of our points of pride at Ghyston is that all of the code we deliver is clean and a pleasure to work in – which is evidenced by our customer’s in-house developers being able to implement new features much more quickly in code areas we have worked in.

Customer collaboration over contract negotiation / Responding to change over following a plan

One of the biggest issues with software development projects is scope. When you start a project to build a house, you’ve got a pretty good idea about what you’re going to want at the end of it – 3 bedrooms, 2 bathrooms, a kitchen, etc. You might decide partway through that you’d like a different colour of paint, or a different oven, but by-and-large you will get what you planned at the start.
Software is different, and this is where the agile method steps in to help. Often, when you start a project, you’ve only got a vague idea of what you need. If you try and scope out everything you need right at the start, you’ll often get things wrong – there will be features that you think are critical that turn out not to be needed, as well as features you missed that you can’t go live without. In a traditional fixed-price project, this results in the dreaded Change Request Form, and endless negotiations about what qualifies as a bug and what is a change.
At Ghyston, we prefer to work on a “fixed-price, fixed-resource” basis. What this means is that we’ll discuss your project in detail, and come up with a scope that we’re confident we can complete with a given amount of developer resource. That developer resource then becomes the fixed cost, with the scope being flexible – so when it’s discovered halfway into the project that there’s a critical feature that needs to be implemented, we can work out which features aren’t as important. This gives us the ability to properly collaborate with our customers, and deliver the best possible product within the budget. When change comes along, we don’t need to go back to the customer to approve the budget increase – we simply work out what is most important, and do it, straight away. More information about this method, and agile development, can be found on this excellent blog post by Atomic Object (they refer to it as Fixed-Budget, Scope-Controlled).

Jake McKenna
Jake McKenna
Technical Consultant & Software Developer

We think you'll also enjoy

Black Interns Pilot Initiative

We were one of the organisations taking part in the West of England's Black Interns pilot scheme this year which aimed to offer up to 50 paid internships in a range of companies to Black students living or studying in the region. Aseel Salih joined our team for a four-week placement as part of the initiative.
Learn more

Do we need to be accountable for the longer-term impact of technology?

We are excited to be shining a light on one of our recent projects that won Innovate UK funding for its three worthy goals; aiding the local economic recovery from COVID, reducing discrimination in AI, and combatting climate change.
Learn more

Do you need an extra pair of hands to deliver your 2021 technology plans?

If you are considering your options for delivering your ambitious 2021 plans then this blog post will help you identify when working with a partner could help and how to get the best out the relationship.  
Learn more

Subscribe to our newsletter

The latest news and industry insights, straight to your inbox