Agile is great. It seems that everyone is either adopting or talking about it (of course many of those will probably be perpetually adopting and talking). However not everyone is succeeding with Agile. One reason is that in order for Agile to work well you need highly experienced developers that are familiar with a broad range of skills and the processes involved in software development. These developers (often the most experienced) are in high demand and short supply. So what can be done to help ensure that your Agile team is successful even with fewer highly experience developers? Use tools to export the highly specialized knowledge that those developers bring to the table, and to bridge the gap between the most and least experienced developers on your team.
Recently I read a good post on Brad Appleton’s Agile Configuration Management Environments (ACME) blog . It takes the definition of business agility and maps it to the definition of software development agility by including the people factor. The definition in that article and other tenets of Agile, indicate that success is not only dependent upon team size, but that experience and range of skill set are critical as well. Consider two of the many principles set forth in the Agile Manifesto .
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
__
“The best architectures, requirements, and designs emerge from self-organizing teams.”
These notions indicate that there will be late breaking changes in scope and they rely on the notion that teams can self-evaluate and adjust. In order to effectively adjust, developers must draw on experience collecting requirements and design to anticipate where the requirements are “squishy”. Similarly, self-organization requires the ability to look at a situation, evaluate, and adjust to create a better outcome than would have occurred otherwise. The likelihood of success in this model is significantly improved through experience. So the best self-organizing teams are those that consist of individuals who have experience working with other teams. Someone might even maintain that in order for an Agile team to succeed it’s members must have experience with unsuccessful software projects.
One issue is that experience alone does not guarantee that a developer will encounter all the responsibilities in the software development lifecycle. It is quite common for developers to naturally gain experience in requirements gathering, design, and testing throughout their project history – even if the sole focus of responsibility is supposed to be pure programming. However there are areas such as release management and automated testing, which the standard developer encounters much less. These areas are considered to be more specialized, often due to the specific toolsets involved and the detailed understanding of the development infrastructure required. Subsequently companies end up with armies of developers, but only one or two people who can exercise, troubleshoot and enhance their development infrastructure. In effect the demography of the corporate software organization is at odds with the needs of the successful Agile team.
Depending on the makeup of the software development organization and complexity of the development infrastructure, it is important that the build-test-deploy processes are encapsulated in a reusable application for the entire team. ElectricCommander and similar applications traverse the skills gap by capturing the knowledge associated with build-test-deploy and bundling it up behind a BGB (big green button). Each particular developer doesn’t have to remember the login credentials for each build server, remember which of the automated tests require a special setup script because the test is out of date, etc. Just as the build scripts or make files themselves are meant to roll up the complexity of the build process into individual targets, applications such as ElectricCommander also roll up the complexity of building your software, running the test harnesses, and deploying to environments into singular processes.