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).
