As organizations examine the need to stay waterfall or go agile, they can’t help but also examine the current skill set of their developers and really look hard at what costs may be involved to make the jump to agile development. Can the current development staff make that move? What training will be involved? What percentage of the core staff will not be able to make that move or will strongly resist? What will the cost of new hires be? Every CTO and CFO will be asking themselves these or similar questions if their company is seriously considering this type of organizational change.
That said, what are the key skills or characteristics needed for agile developers? What will the CTO or development manager be looking for in existing staff and new staff hires when the change is in progress? In general, the following eleven skills are important ones to consider when staffing or evaluating current staff for a move to an agile development and project culture….
Keeping the system in a running state. Finding errors is actually the developer’s single biggest time waster. When several changes happen and then something goes wrong, it’s hard to determine what changes caused the occurring errors. By making incremental changes to detect errors immediately, this saves a lot of wasted time searching for the causes of errors.
The inherent ability to minimize complexity and rework. This is actually more an attitude than a specific skill set. It provides an alternative to the common extremes of hacking – which can end up causing significant rework – and over-design – causing potentially much more complexity than needed and thus inviting risk and increased costs.
Programming by intention. This old programming technique made popular in eXtreme programming is easy and provides for cohesion, encapsulation and clarity.
Commonality and variability analysis. A straightforward technique to identify the concepts in the problem domain. This provides a model to further the proper use of object-oriented modeling.
Separating use from construction. This process eliminates the situation in which integrating new code into established systems exceeds the cost of writing the code in the first place. It actually forces abstraction and encapsulation on the developer. It provides discipline for hiding the specific implementation being used.
Encapsulating. We are often guilty of making choices that turn out bad and require costly rework or we overbuild resulting in unnecessary complexity. If we encapsulate our code and designs we can more efficiently make changes when we understand what is really needed.
Defining tests up front. The ability and forethought to define tests up front increases understanding and can help prevent many errors that otherwise may find their way into the code.
When and how to use inheritance. Inheritance has a long heritage of improper use. Knowing how and when to use it is a key skill in the agile development world.
Refactoring to the open-closed. Refactoring can mean fixing code. It can also be used to improve designs that were good when they were written but decayed because of new requirements that came up. This technique improves the design of quality code as more knowledge about the system’s needs become available.
Determining needs vs. capabilities in interfaces. Interfaces require a different method of design. Instead of designing from the perspective of what we have, we need to be designing from the perspective of what is needed.
Continuously integrating. Finally, continuous integration is a low cost method of detecting errors quickly. And, it is essential if you’re writing tests up front as described above.
Summary
I’m sure this list could go on and on – this one hits on just eleven key skills. Readers, please feel free to add to the list and discuss what other important considerations there are as an organization considers a move to an agile development model, both from a personnel perspective and from an organizational perspective.
