Mobilizing the right team for executing a project successfully using Agile methods is important. More importantly, Agile method needs experienced coding hands, because of its emphasis on liberating the programmer from manager's command. A project following Agile methods does not have any project manager. The scrum master's role is limited to asking three questions only, that too far open ended. In such a situation, the developer is entrusted to compose the work performed, the work to be performed (in the guise of will be accomplished till next scrum), and estimation of effort. It's true that only the individual can specify how much time he/she would take to complete a specific task, because only the individual knows how much he/she takes to complete similar tasks. In other words, how much time he/she had taken in similar type of tasks in the past. In other words, how much experience he/she can leverage this time. More the experience, better would be the estimate, better would be the productivity.
The proponents of Agile methods counters that such a developer profile is something that everybody asks for. It's not uncommon. While such counter statements are true, the fact that Agile Programming does not have any room for junior coders is true as well. So much that the project following Agile Programming with a bunch of junior coders (and no project manager) is susceptible to failure more often than the traditional one.
The good news is, there is a way out. Tailoring the Agile methods a little bit would make a tremendous impact on achieving right mix of the team, and would help in shaping the path for individual development for the junior coders. Here is how.
Pair programming allows two developers to develop application while working on a single computer. In a project team that follows Agile methods, each pair can be comprised of a senior coder and a junior coder. At the beginning, the senior coder will act as the driver to get the work started, while the junior coder will be the observer. By junior coder, I am indicating to a person who has been trained on the necessary skills to perform the job of programming, like programming language, but not necessarily has any experience of doing similar project before. For the first week, or may be for the first two weeks, the senior coder will be the driver. Subsequently, they will start interchanging the roles. While the junior coder works like a driver, the role of the senor coder would be more like a navigator instead of an observer. This would ensure that the progress is happening in the right direction, with right quality, and adequate learning for the junior coder. This would also address the question that critiques often raise: Productivity. With two senior coders programming in pair, the productivity cannot be more than the aggregate of what they would have been accomplished in isolation. If fact, it would be far less. With a mix of senior and junior coders in the pair, the probability of accomplishing the comparable output would be higher. This is because the junior coder is always coding in presence of experienced reviewers. When it comes to the tasks like effort estimation, it would be always the senior programmer who would do the estimates. This would ensure the accuracy of the estimates stay within the tolerable limits. Also, the senior programmer needs to factor the productivity level of the junior programmer.
There is a small drawback though. The codes produced by the experienced coder will not go through proper review. For this, the team may adopt a process of peer review across pairs. Peer review, in general, is part of the traditional way of software engineering, but will become very effective in quality assurance in such a situation.
To summarize, it's possible to induct junior profiles in the project team while following Agile methods. Pair programming would be the way to achieve that. Introducing peer review across pairs would ensure that the quality of the work products are not compromised. Such a tailored process would pave the growth path for the junior developers.
