Monday, July 14, 2008




Smooth oscillations in team performance by:
  • Eliminating waste, and
  • Improving continuously




Soluble Code











Test-Driven Development







Design Improvement





Synchronized Teams







Friday, July 11, 2008

Sustaining Capacity in Maturing Agile Software Teams - Part 3: Recognizing Entropy

The visible and tangible differences between traditional phase-based development and agile development are much more obvious than optimizations made later within an agile practice. The next round of improvements can be harder for agile teams to embrace than the original effort to embrace agile development.

Each successive improvement is increasingly subtle relative to the previous improvements. Product development organizations usually have to first start seeing signs of emerging entropy before they have the necessary context to consider new, subtle improvements.

When a product development organization starts sensing entropy, its first decision should be to decide when it needs to act upon it, rather than to decide to presume to begin to act upon it immediately. Acting too early can mean that the team might be acting without sufficient context and understanding of the sources of entropy.

If the team recognizes frustration with its current ability to perform, and if it has some shared understanding of its constraints, then it can potentially begin to remove the constraints immediately.

The following are common issues for agile teams, and represent areas where bottlenecks and entropy collect:
  • Code. Code is often written merely to work and to execute, without consideration for the waste incurred by forcing teammates to decipher code in order to get at its purpose, and to work with it. Code is one of the primary means of communication on an agile team. It must be written to communicate to other programmers on the team, and must quickly generate understanding.
  • Design and Architecture. Systems and software work but are not readily understandable and adaptable by all members of the team. A small set of well understood and familiar patterns are often over-used. Object-oriented design fundamentals are often esoteric and impenetrable during the building of a first or second-generation product. Developers come to understand their significance often only by introducing design friction that is only seen in retrospect as a series of violations of software design laws and principles.
  • Tests. Initially, teams tend to craft tests as quality assurance efforts rather than design, specification, and documentation efforts. Tests should be easy to scan, enabling developers to get an immediate understanding of the system and the impact of the work they need to do, as well as an understanding or where to find their work site (or sites) within the code and supporting artifacts. Tests are the most important form of documentation on an agile team.
  • Development and QA Test Synchronization. Without greater synchronization between development and QA testing, valuable input often comes too late in a development or release cycle to be effective. Test design and test architecture are valuable inputs to development, and software design and architecture are valuable inputs to QA testing. Teams often loose unrealized capacity by not pursuing means to do more development and testing in parallel.
A software team continues to adjust and refine its practices based on the friction it faces and the observations it makes. Entropy still collects.

A critical mass is inevitably reached and the team makes course corrections that are often broader than the iteration-to-iteration practice and tool calibrations.

Thursday, July 10, 2008

Sustaining Capacity in Maturing Agile Software Teams - Part 2: Entropy

Teams that have adopted an agile approach to software development adopt new disciplines in an attempt to reach a level of productivity and effectiveness above their achievements with previous approaches or methods.

There are common practices and disciplines found on most agile teams, including:
  • Developer testing (unit testing, and possibly Test-First Programming)
  • User stories (analysis and scoping)
  • Time-boxed delivery cycles (iterations)
  • Continuous Integration
  • Automation
  • Collaborative work
  • Deep customer involvement
  • Rapid feedback
Agile teams use these skills and tools to deal effectively with the inevitable change that is part of software development.

Previously, the team may have obstructed necessary change because of an inability to use effective counter measures that accommodate the business and the team in adapting to new opportunities and new constraints.

Counter measures often produce inherent bottlenecks that point the to the need for subsequent optimizations. Bottlenecks manifest in the following ways:
  • Code mass growth. By adopting developer testing, the team has volunteered to double the amount of code and systems artifacts that it maintains. It maintains this added code without increasing the team's resources, often gradually degrading the team's capacity.
  • Design rigidity. The team uses traditional software designs that aren't optimized for the rate of change that the surrounding business and the team itself has become acclimated to.
  • Growth constraints. The pace of an agile team and the incremental successes that allows for advancement of a product drives a need to grow the team and its people. New people are brought in to naturally increase capacity, but it takes longer than expected or desired to become meaningful contributors to the effort.
These constraints are symptoms of the entropy that subsequent optimizations should address.

Without addressing the production entropy, it will ultimately constrain the business's ability to take advantage of new opportunities, which will ultimately lead to decreased throughput and entropy in the business.