Behavioral traits of an Agile Developer

07 Aug, 2008

Last month, I was going through Lean software development by the lean software gurus Mary and Tom Poppendieck and I could easily associate most, if not all of its principles with our day to day working in Xebia. It really gets interesting and fun to read about something when you are already practicing it. In the process, it reinforces your beliefs on the principles. Although the book was easy to follow and examples easy to associate with, I could not get a clear idea of the term ‘right people’ mentioned at many places in the book. I always wondered about the definition of ‘right’ the lean-principles talks about.
I understand recognizing and hiring the right people is an organizational level decision, so Agile principles may not talk about it. Moreover, it’s not only Agile based organizations who look for the right people. It’s equally true for any other non-agile organizations also. In a situation where there is a scarcity of good people in the job market, sometimes companies go for an extra-mile to get good candidate. Although the need of recruiting right people is universal, the definition of it generally varies from organization to organization and from one role to another.
The behavioral traits for a ‘right’ person for other ‘type’ of industries are mostly well defined and well known. For instance, I know what kind of people NDA (National Defense Academy – India) looks for, or what attitude is desired from a person selected for Hotel Management service industry. But talking about Agile, it’s still vague what attitude in a person makes him a good fit or a bad fit for an Agile team. In his article ‘The Shiny New Agile Architect‘ the author described the characteristics of an Agile Architect. On a similar line, I believe some characteristics can be identified for an Agile developer too.
So, having spent around a year working in agile projects let me try to compile the list of behavioral traits which I find makes a good (potential) agile developer. Here are some of them:

  • Incremental and Adaptive: The very basic requirement for an Agile project and hence its team members. For a software project to be iterative, its people should be adaptive and continuous improvers. If a person is not adaptive, he would always be reluctant to start on a task till the time when he has a clear picture of where to finish. And this is generally not the case with Agile projects, wherein you may not have a clear final picture when starting a task. An adaptive person would start (or at least try to start) with whatever maximum information present at that time, and then would make changes to it incrementally, adding more and more features as more information start coming to him.
  • Proactive and sense of Ownership: It is one of the biggest differences I noted while comparing the way of working in agile and non-agile projects. In the waterfall model, it’s the technical leader who would assign task to team members and the decision of what to assign and to whom is also made by him. To make his life more complex, the ownership is also bestowed on him for all the tasks, and it is part of his job-profile to keep a track of tasks being executed and completed.
        However in Agile projects, a developer picks up his task from the sprint backlog. No one, not even the scrum-master keeps an eye on the tasks done by others. It works on the pull system (also known as the Kanban system) wherein you pull a task from the sprint yourself and take complete ownership of it. It’s not only limited to picking up the tasks from the sprint backlog, other tasks like increasing the test coverage, refactoring code for simplifying the design, documentation and so on are pro-actively done as well. No one waits for any instructions from anyone to pick up such things, which is generally very uncommon to find in a non-agile project.
  • Multi-skilled: This is complementary to my 1st point ‘incremental and adaptive’. The basic feature of Agile development is that it is driven by the customer. The more multi-skilled and cross-functional a team is, the better it would be able to service the changing requirements of the customer. Leave apart the skills in technology; a developer may be required to do non-technical tasks at times. He may be required to talk to the end user to know their feedback or understand their experiences with the other systems, may be required to collaborate with the testers at the client end, may be needed to collaborate with the hardware guys to ensure the timely shipment of the needed hardware etc.
  • Communication skills: Again, it can be clubbed together with the 3rd point, but I just wanted to stress more on it. Someone may argue that good communication skill is needed in non-agile projects as well so what is so special about it. Well put plainly, it is needed more in agile projects. In waterfall model, client communication may be a secondary or ‘nice to have’ skill from a junior software engineer or senior software engineer and is a ‘must have’ skill for a technical leader or project manager role. On the other hand, given the flat hierarchy of an agile team, it becomes an indispensable skill from an agile developer. All activities, both team activities and client communications require good interpersonal skills from an Agile developer. Team activities include for example daily stand-ups, planning meeting, retrospective and design discussions. Client communications generally consist of prioritizing the backlog, transforming a business case into a user story and the like.

I agree that the above list is not an exhaustive one and I believe there would be many others behavioral traits which can be identified for an ideal agile developer. I look forward to have inputs from anyone of you who has recognized any other ‘must have’ behavioral traits.

Newest Most Voted
Inline Feedbacks
View all comments
13 years ago

Dear Ran,
thanks for this overview. A very useful list for coaching and assessing teammembers.
One of the first good-agile-developer-traits that comes to my mind is: teamplayer. In my opinion a teamplayer has some characteristics which are key for a succesful agile way of working.
First of all, working in agile team means to have an eye on the competencies of your colleagues when filling in your role. Sometimes this means doing things you would not prefer to do, but improve team performance a lot. Another thing is to be able to accept critism or ‘suggestions for improvement’. A team can only improve if they identify impedements and tackle them. The last thing I recognize in a teamplayer is his responsibility for the teamspirit. A happy team performances better.
I realise one can argue that this teamplayer trait is already covered in your set of traits, but I think it relevant enough to make a trait on his own.

13 years ago

Hi Ran,
What I’ve learned in speaking to customers that are practicing Agile is that developers are problem solving at a much higher level, they’re solving business problems. Agile seems to provide a much higher level of job responsibility and job satisfaction. They’re talking to the person who is going to be using the feature. They understand what they have from a real-world business need, and figuring out how to solve their problem. For any body who is expecting to be handed a spec, an already designed system, and told just to “code it,” those developers don’t usually work out as well. According to customers, the developers doing Agile are smart, motivated, driven people and don’t want to just be handed a spec. They seem to get a lot more productivity out of that and they believe their company goes further. Their boss would rather be working for smart, driven people who are looking up and out vs down and in. They typically work in dynamic and open environments, where there’s a lot of collaboration, and a lot of “I need you to fix this problem,” it’s not that the manager “needs something that looks like this,” it’s “I need you to figure it out and fix it.” The people working in that kind of environment tend to be creative, problem solving people that are great to work with, enjoy their job, and are never bored.
The biggest problem in going Agile for many is taking developers who are in that “Give me a spec and I’ll code it,” box, and either breaking them out of their shell because they have the ability, but were just not used to the Agile way of thinking.

13 years ago

Very Interesting post! Thank you for such interesting resource!
PS: Sorry for my bad english, I’v just started to learn this language 😉
See you!
Your, Raiul Baztepo

Explore related posts