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 3^rd 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.

Filed under Agile, General, Scrum | 3 Comments »