Many agile organisations adopt agile with evangelical zeal because they are not very agile in the first place. The benefits can be felt immediately as stakeholders are engaged and teams take direct control over development.

After this initial success teams often become stuck and stop making progress. More often than not they are overwhelmed by legacy systems and manual processes. Agile ceremonies such as stand ups and sprint reviews are not enough to overcome the constraints imposed by poor design, dated technology and inefficient development practices.

This explains why the pursuit of “technical excellence” is part of the agile manifesto. It's a recognition that you cannot expect to succeed on ceremonies alone.

Scrum is based on a set of project management techniques that exclude any technical activities. Adopting these techniques without a robust set of technical practices can give rise to what Martin Fowler termed “flaccid scrum”, i.e. a partial and ineffective implementation.

What do we mean by “technical excellence”?

“Technical excellence” is one of those slightly nebulous phrases with many different interpretations, but in an agile context it normally refers to removing constraints. This generally involves three broad dimensions: the techniques in play, the individual's technical skill and the way people behave as a team.

Firstly, “technical excellence” requires the adoption off a set off techniques that help you to produce better software faster. This usually includes those practices outlined by extreme programming, such as test-driven development, continuous integration and collective code ownership.

Secondly, it requires a particular focus on the craft of software development. Good software design needs a clear understanding of the tools, languages and environments that you are using. It requires a simple approach to design coupled with a ruthless attitude towards review and refactoring. In this sense, "technical excellence" requires a personal commitment in that developers must be committed to self-improvement.

Finally, there is the behavioural element off learning how to be a member of a team. There's nothing particularly new here as Gerald Weinburg was writing about the importance of team dynamics and “egoless progamming” in the early 1970s. Developers need sufficient maturity to work together, trust each other and learn how to use each other's skill to build great software.

The need for technically engaged leadership

The agile manifesto talks in terms of “continuous attention” to developing the right skills and attitude to succeed. Organisational agility can become constrained by a lack of technical agility. If we improve the technologies and processes that teams use this will allow them to deliver better software faster.

Leaving this to teams to find their own way is a cop out. As an excellent NASA paper on technical excellence points out, "technical excellence" requires a combination of personal accountability where everybody understands their responsibilities and organisational responsibility in terms of providing the right training, tools and environment.

Most teams will struggle to adopt continuous deployment if they have to develop the necessary tooling from scratch. Jumping into test driven development without support can become a counterproductive mess that slows down development. It's down to the management to recognise this and provide the necessary expertise to support teams.

Continual growth and learning

This should feed into the development off an engineering culture that promotes technical excellence through shared experience.

Larger agile organisations generally introduce mechanisms that allow people to meet and exchange experiences. Spotify call these "chapters" and "guilds", other organisations talk in terms of “communities of practice”. It all amounts to the same thing, i.e. embedding the sharing of experience and reducing isolation.

Other styles of organised initiative can include “brown bag”, “show and tell” or “doughnut” sessions where developers meet to give short presentations on something that interests them. Code clinics can provide a non-judgemental place where developers can bring issues for feedback or to work collaboratively. Cross-team code reviews can help to break teams out of their immediate silos.

It can be difficult to maintain the enthusiasm for this kind off initiative over the long term. Initial enthusiasm tends to give way to the realities off time-pressured software development. The same “lurkers” tend to attend every time and it can be hard to reach those “dark matter developers” who often make up the bulk of programming teams. The point is to harness whatever latent interest there might be and give it the opportunity to express itself - over time it will start to influence the wider organisation.

Flexibility and pragmatism

Writing perfect code is all very well, but it's meaningless unless you ship. Hence the agile manifesto's focus on working software.

This necessarily involves a degree of pragmatism. "Technical excellence" isn't always about writing really great code or producing solutions with no compromises.

The reality of commercial software development is that deadlines and budgets will force some level of compromise and create technical debt. Teams should put themselves into position where they are able to make the necessary choices. Good software design should allow flexibility while good process should make it easier to adapt.

Filed under Agile and Development process.