What is an agile developer and what traits aid being good at developing in an agile manner?
One of my favourite questions in interviews for a technical candidate is “what do you think makes a good agile developer?”. I usually like to offer a follow up of “What skills do you think you need when developing in an agile process compared to developing in a Waterfall process?” to try and coax out an answer.
So far I’m yet to get an answer that has really resonated with me. I’m not sure there is a correct answer and I don’t actually have a predefined answer for the question - I ask it without a specific expectation of what should be answered! I think it’s a good thing in an interview to listen to what is being said rather than trying to match responses to a set of answers.
I do have some idea of the kind of things I would answer to the questions, however.
Won’t somebody please think of the pedants?
As you might have noticed, I’ve not written agile in pseudo-proper-noun “Agile” format. You may be aware of the mantra of “agile is not a noun“ which really makes a lot of sense when you hear about “Doing Agile” and the way in which the meaning has become lost.
So for the pedants out there, when I say “agile developer” I am using “agile” in its adjective form: a developer who displays agility. Not “Agile-developer” as a noun itself, which I guess could just be someone who works in an agile process.
What makes a developer agile?
In Dave Thomas’s article on agility, he defines “how to do something in an agile fashion”:
What to do:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
How to do it:
- When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.
This is a great way of explaining to a developer how you want them to approach work as a member of your team.
I would then take that a little further and say there are disciplines that an agile developer needs to use on a day-to-day basis, such as:
- TDD with Refactoring
- Loosely coupled code structuring
- Working with continuous integration
This, however, just explains what an agile developer does; it doesn’t really explain what makes someone good at doing this. In my opinion there are certain characteristics that suit working in an agile process: Anyone can work in an agile process, but some are better than others at working in this way.
So what makes a “good” agile developer?
As I said at the beginning, I have never really set out exactly what I think these are, so in this article I am setting myself the challenge of doing that. Here goes.
1. The ability to quickly understand a subset of existing code for a specific purpose.
I honestly think that of all the abilities that a person can have, this is the one that really helps in an agile process. I think of it a bit like an archery target - you want developers to be able to quickly focus in on the centre point of an area of code and understand it for the current iteration of work (User Story for example), but also be able to scan outwards from the centre to gain less detailed understanding of surrounding areas.
2. The ability to have short, targeted discussions with team members about moving the code from point A to point B.
I’m sure we’ve all had discussions that go off on tangents. And tangents of tangents. Time within a team can very quickly disappear in these cases. I’ve always found the best team members are ones that can have short discussions and gain a quick understanding. And in an agile fashion can iterate off of that understanding by having further short discussions later if needed.
3. The ability to learn new skills and technologies quickly to an appropriate depth and breadth and iterate on that learning over time.
The adoption of new technologies that make your project or process better is very important, so having team members who can quickly evaluate these, gain a good understanding and vision of how to use them within your project is a very useful skill. If they can also gauge the depth and breadth of understanding required based upon time, importance and longevity then this can save time and be iterated on later.
4. The ability to have a good understanding of what goes on around you in the team without needing to dedicate specific time to it (peripheral vision).
I’ve found this to be a really important skill for team members to possess. No matter what sort of agile process you are running, there is generally a necessity to foster a team ethic where the team must work together and succeed or fail as one entity rather than individuals. For me it is imperative that team members are aware of what the team is doing so that should their assistance be required they can do so without massive amounts of context switching. Some agile processes utilise daily standups to try and enforce this, but in my experience there are some developers who have this peripheral vision and are aware just from snippets of discussions (whether audible or written) roughly what is going on and even how it relates to what they are currently doing. I would actually go further and say this is what makes them truly part of a team.
5. The ability of having general commercial awareness.
This one may be slightly controversial - but I feel an important one. When working on a product in an agile process, some understanding of the commercial aspect ensures that time and effort is targeted in the best way possible. Yes, process can assist with that - i.e. if the Product side of the business is well integrated (Product Owner etc.) then hopefully developers have some understanding of why the work is required - but there is still an individual level of this skill which helps. The best developers have an inherent understanding and that helps their decision making.
And that’s it.
There are many other skills that can make developers “good”, the obvious one is being able to write good code - but this article was talking about specifically what makes a good agile developer. Sure, you need people who can write good code but you do in a Waterfall process as well. The same applies to having experience with specific technologies that you are using. I want to consider what makes that person who can write good code or has matching technological experience suitable for working well in an agile process. Besides, as a team you can implement things into the process to aid with this - TDD, Code Reviews, Katas etc.
These are just my opinions and based upon my experiences and knowledge. There are other subtleties that should probably be considered, such as different types of developers within a team (e.g. characteristics such as being able to bash through problems quickly while leaving devastation in their wake, or those who can think more moves ahead than others and therefore spend less time actually writing code). When hiring you could have a different agenda depending upon the current makeup of your team, which could prioritise different personalities. Besides, how you can actually determine whether someone possesses the above skills is another question entirely!