Champion Technical Excellence

Agile developers are dedicated to technical excellence, not because of aesthetics (although that may be a rationale for some), but because a dedication to technical excellence delivers customer value. Project managers must be champions of technical excellence; they must support and advocate technical excellence while maintaining a watchful eye on other project objectives.

Championing technical excellence is critical both to creating the product customers want today within the established constraints of time and cost and to reducing the cost of change so the product remains responsive to future customer needs. If APM's core purpose is to create innovative products, and if competent individuals are a key part of delivering those products, then it's impossible to support a principle that advocates technical mediocrityeither explicitly or, as is usually the case, implicitly.

Few products today, particularly industrial products, are one-shot wonders. Products evolve over time, improving constantly. For example, the Boeing 747 passenger jet has been in existence for over 30 years , but the 747400 planes rolling off the assembly line today are much different than the 100 series planes first put into service in January 1970. Technical excellence is key to product evolution.

In discussing the Toyota lean product development system, Michael Kennedy (2003) laments that in too many organizations project management has become focused on administrative excellence rather than technical excellence. He goes on to state that one of the four pillars of the Toyota system is an "Expert Engineering Workforce," which encourages both technical excellence and individual responsibility.

Some critics consider agile methods to be ad hoc, undisciplined, and, ultimately, technically inferior. They are wrong. First, for traditionalists, who thrive on process, procedure, and documentation, the informality of agile methods is interpreted as undisciplined. Nothing could be further from reality. Discipline is doing what you said you would do. Using this definition, many organizations with elaborate processes failthey have volumes of processes, procedures, forms, and documents that are systematically ignored. Agile organizations have less-elaborate process structures, but they tend to follow the ones they have.

Second, the difference of opinion isn't over whether technical quality is important but over how technical quality can be achieved. Critics say, "Agile development ignores design." What they are really objecting to is the lack of extensive up-front design, believing that it is the only valid design process. Agile developers believe that iterative, emergent design and frequent feedback yield superior designs. So again, it's not a question of design versus ad hoc development, but a disagreement over design approach.

As a software development consultant, I've never encountered a successful software company (although my sample size is limited) in which the team leaders and project managers were not technically savvy. Whether a company is building electronic instrumentation, jet engines, or pure software products, project managers need specific technical expertise to adequately manage projects. Championing technical excellence requires that the project manager, and team members in general, understand what technical excellence meansin the product, the technology, and in the skills of the people doing the work. They must understand, within the context of their specific product, the difference between excellence and perfection . No company can afford to produce a perfect product, but building a product that delivers customer value and maintains its technical integrity is essential to commercial success and the technical team's satisfaction.

Some practitioners operate on the premise that project management practices are generic and can be applied across any project. They may argue that someone with good project management skills doesn't need deep domain expertise. While this premise may be true in some domains, in general it doesn't apply to product development where technical, scientific, or engineering skills are paramount. "Project managers who don't understand the technology they are managing can lose the confidence of their teams, particularly teams that are proud of their technical ability," says author Eric Verzuh (1999).

Some project managers, in particular those isolated in project management offices, also bandy about the notion that product development and project management can be separatedagain, believing that the project managers can somehow glide along above the work of product development, monitoring and controlling without getting their hands dirty. While generating an iterative feature plan and gathering the requirements for a product feature are different kinds of activities, they are each so dependent on the particular type of product that separating them is a sure path to failure. The fallacy that project management and product development can be separated may have roots in the widespread use of serial lifecyclesPlan, Design, Build, Test. From this perspective, planning, designing, building, and testing an electronic instrument may not seem very different from doing the same for a motorcycle. However, employing a feature-based approach rapidly points out the need for an integrated approach to the two activities.

One of the reasons project managers (in their role as decision makers or influencers ) need a technical background is that while technical excellence is a laudable goal, there may be considerably different approaches to achieving that excellence. Should the software team focus on refactoring, automated testing, and simple design? Extensive front-end modeling? Or some balance of the two? Project managers need to be involved with the team in debating and deciding on the technical approach to development, as well as keeping the team aware of the business objectives as technical issues are decided. The project managers may not make the decision, but they should be knowledgeable enough to steer the interactions between team members, make sure project data (e.g., architectural platform constraints) are fully understood by the team, and keep the team on track in making timely technical decisions.

Furthermore, project managers must champion technical excellence because therein lies the key to adaptability and low-cost iteration that drives long- term product success. Project managers are jugglers, always keeping multiple balls in the air. They must be aware, for example, of the point at which their team starts tipping the balance from technical excellence to perfection. They must be aware when the product manager pushes too hard for speed and features over adaptability. Helping project teams find and maintain these balance points is nearly impossible unless the project manager has the necessary technical background. The project manager doesn't have to be a technical guru, but he has to know enough to recognize and converse with one. That said, if the project manager isn't a technical guru, he better have one in the form of a chief engineer or developer.