This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first six parts of this series here:
In Part IV (Key Players) we discussed that an important role that someone on projects at your organization must play is that of a leader of the development resources, or Development Lead. People staffed in this role, whether the sole proprietor of a startup or a technical leader assigned to a project such as an architect or senior consultant, are tasked with more thought collaboration and less reliance on technical savvy in an organization.
There are five key skills that help a development lead shine in agile organizations.
Predictably, it’s important that people tasked with leading the development activities of projects at agile organizations be competent at refactoring. The ability to bring experience from real projects (sometimes failures bring more experience than wildly successful ones) and to apply this to a rapidly changing codebase is increasingly important, because on an agile project the design of key modules and patterns is going to change somewhat regularly. Experience with modern source control solutions; modern architectural patterns and their tradeoffs, refactoring features in IDE’s like Visual Studio, Eclipse, and Resharper; and some competency with the technologies involved are all good ingredients for refactoring success.
It’s also important to have a Development Lead who is aware of their shortcomings. A lead who solicits input from other team members on their own, and who offers more of their time to do reviews of design and code is the type of person we’re looking for. A person with great technical skills will produce functional code. A person with great technical collaboration skills will produce a team of producers of functional code. A goal for Development Leads should be to create a culture of “sustainable autonomy”. Developers on their team should be able to prioritize their own bugs, gather their own requirement clarifications, and assign themselves to new work as other items are finished without constant oversight by them. Though junior developers on an agile team may require more oversight, this should be the exception, and not the rule. Development Leads may take the drivers’ seat in making some of the initial process and technical decisions at the beginning of a project or sprint, but the changes that occur when the theoretical gets concrete (as most agile projects are light on up-front technical decisions, preferring decisions made at the latest responsible moment) should be team driven. Doing this diversifies some of the leadership skills across the team instead of centralizing it on one star player. It’s still important to have one technical final arbiter of decisions at which the buck stops however.
Written, presented, and oral communication
This one’s pretty self explanatory but it’s so important it really has to be worked on to be harnessed. A development lead should work to be better at conveying information, in a variety of formats, to a variety of audiences, and then gathering and interpreting feedback from that conveyance. This means good grammar, spelling, email voice/attitude consideration of audience, and even selection of media. This is a foundation upon which the other skills needed by a solid Development Lead rest.
It also bears repeating from the Key Players post that communication with business resources is of the utmost importance to Development Leads. A good lead has an ability to provide the right analogies and information to convey ideas without being overly technical, and makes business people feel excited when discussing ideas with them instead of intimidated. Business resources should feel like “this is the person who’s going to turn my ideas into reality” instead of “this is the person who’s going to change all my ideas to fit technology limitations”. People on both the business and development side of the fence live day to day with the reality that at times software vision must bend to the unfortunate compromises of technical limitations, but a good development lead puts energy on what can be done instead. You want a person who sees the process of cultivating a project out of agile processes to be one who sees the cup “half full”. This doesn’t mean being a well-to-please, but rather someone who works tirelessly to find an acceptable level of functionality to solve the business problem within technical constraints.
This ability to compromise also extends its benefit when a Development Lead must consider budget and schedule constraints when weighing tradeoffs of technical decisions. Every time dependency injection, testing approach, partner integration patterns, or any other aspect of the design of the software is on the table; a good lead considers the true weight of each factor (and not just their own position) for all involved and strives to make the right decision for users of the software and the business. This more often than not means accepting a difficult technical limitation in favor of meeting a requirement or a deadline. It is still important in these situations to document the limitations imposed by weighted decisions both to keep track of addressing them later and to prevent accusations of ignorance should the limitations become politically stressful for the customer or organization.