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:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players
Part V: Sprint Execution
Part VI: Key traits of Customer Champions

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.

Refactoring

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.

Mentoring

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.

Compromise

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.

Pragmatism

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.

Category:
agile, process improvement

Join the conversation! 4 Comments

  1. I can’t believe you mentioned Fowler’s article on source control! It was very disappointing. He starts by labeling source control systems as inferior simply because he and the people he works with are not familiar with them. And then goes on to issue a blanket recommendation of distributed source control systems without a word about the overhead of merging, the experience level and the learning curve it requires from entry- and mid-level developers. I understand it was written from Fowler’s personal experience, but someone so prominent in the IT industry should know better. People who read his books will quote, make decisions and get in trouble based on this post for years to come.

    Reply
    • I’ll have to disagree. I think Martin’s opinion on source control is pretty current, and he’s discussed the experience implications in other posts and twitter updates of his. He seems to regularly pick stances that divide opinion, and has done so here. I’d be more concerned with someone who reads a post of his and makes a decision solely based on it, than on Martin posting his opinion. Though I guess that’s the risk of him being such a respected industry contributor – many folks take his word as gospel.

      Reply
  2. […] Part I: Introduction Part II: Vision and Risk Part III: Backlog Management Part IV: Key Players Part V: Sprint Execution Part VI: Key traits of Customer Champions Part VII: Key traits of Development Leads […]

    Reply
  3. […] Management Part IV: Key Players Part V: Sprint Execution Part VI: Key traits of Customer Champions Part VII: Key traits of Development Leads Part VIII: Key traits of Schedule […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: