The problem

eXtreme Programming, and several other Agile methodologies, strongly emphasize the notion that “the team knows best, so all decisions should be left to them.” By “team” they typically imply software developers and QA – the technical folks. In some situations, this approach excludes project- and program-management, which are left to people who do the planning, and interface between the team (technical) and the organization’s management (business).

The problem I have seen is the lack of several important functions: master designer, guiding hand, and homogenizer / enforcer. The assumption that design efforts apply exclusively to the present iteration seems to discount any certainties that do exist with respect to the future of the product. In a world where software products are still extremely intricate and inter-dependent, sub-teams doing their own planning, design and refactoring invariably end up reinventing the wheel, and usually in different shapes that must later be resolved. The “guiding hand” complements the master designer in preventing pointless creativity, misunderstandings and loss of focus. Lastly, the “homogenizer / enforcer” function is about following design and implementation patterns, as well as proper code reuse, all of which creative, independent and trustworthy developers are wont to ignore or avoid.

I don’t think that Agile methodologies that lack these functions are bad or don’t work. Agile can still deliver well-behaving products, on time, and to customers’ satisfaction. However, products invariably grow and multiply and become technically obtuse. Properly fulfilling these functions ensures that their technical quality and cohesiveness will stay high, saves expensive resources, and eases transitions and hand-off within teams as well as during high turn-over times.

The solution

… is a variation of the old-fashioned “software architect”. Today’s architect spends the time writing phonebook-sized specifications that few developers read. In the XP environment, the architect should take care of framework design, application behaviour, consistency, interfaces etc. – leaving the team to take proper care of high-level design and implementation. The architect’s other tasks include the missing problem functions: accompanying and verifying team design decisions, reviewing code and ensuring that it follows group standards (anything from function naming to testing), directing refactoring approaches, ensuring code reuse, etc. The architect would have to be very technical, skilled in conceptual thinking, and a good people-person. In highly cohesive teams, the architect’s consistent dropping-in on developers can replace pair programming. In very large development groups, there should be one architect for every few teams, and these architects should be overseen by one master architect and be in constant communication with one another.

Background

Affinium Pharmaceuticals is engaged in structure-guided drug discovery. By utilizing proprietary knowledge and expertise in proteomics and chemistry, and strategic collaborations, it conducts scientific research and development to discover novel therapeutics. The Informatics Group assists drug discovery, whether internal or collaborative, by providing applications and tools for data storage, manipulation and analysis. The software development group within Informatics is in charge of software development for the entire company, and follows a special methodology, which is a hybrid of eXtreme Programming and Feature-Driven Development.