Managing Complexity and Uncertainty

Categorizing software development projects according to their complexity and uncertainty, you can adapt your process by adding practices according to each project's profile.

Projects can be put in a four-quadrant graph similar to the Boston Consulting Group's Boston Matrix, using complexity and uncertainty as the two primary attributes that influence the type of process:

• Dogs: simple projects with low uncertainty
• Colts: simple projects with high uncertainty
• Cows: complex projects with low uncertainty
• Bulls: complex projects with high uncertainty

with as complexity drivers: team size, mission criticality, team location, team maturity,
domain knowledge gaps, and dependencies
and as uncertainty drivers: market uncertainty, technical uncertainty, project duration,
other projects'dependencies on that project, and scope flexibility.

Start with a core set of common practices:

• aggregate product plan: vision, plan, strategy, markets, platforms
• A/B/C list: prioritised features (A-must, B-should, C-might be completed)
• quality agreement: quality targets for the release
• continuous integration: configuration management and build at least nightly
• expert-user involvement: (former) customer, expert tester
• project dashboard: product status info with plan, quality metrics, risks, updated at least weekly
  

Add practices according the quadrant:

ColtsLow Complexity, High Uncertainty Cope with uncertainty: short iterations daily stand-up meetings automated unit tests	BullsHigh Complexity, High Uncertainty process ceremony as with cows agile steering as with colts iterations shorter than cows, longer than colts efficient communication channels
DogsLow Complexity, Low Uncertainty Sufficient with just the core practices	CowsHigh Complexity, Low Uncertainty Deal with complexity: rigorous requirements management functional spec for interface definitions detailed project plans with critical path identification subprojects coordinated by a team of leaders

From: Context-Adaptive Agility: Managing Complexity and Uncertainty, by Todd Little, IEEE Software May/June 2005

Are you applying the right level of ceremony and agility according to the complexity and uncertainty of your project ?

Customer Test Driven Development (CTDD)

Test Driven Development has many advantages. Not only at unit test level, but also at functional, system and acceptance test levels which benefit from increased communication and collaboration.

Test Driven Developement (TDD) is a widely accepted agile development practice. It forces the programmer to think about many aspects of each feature before coding. It result in a safety net of tests, ensuring that refactored code maintains it functionality. TDD far outshines code produced in a traditional manner in quality and robustness.

With Customer Test Driven Development (CTDD) you drive projects with tests and examples that illustrate the requirements and business rules.

Customer tests are anything beyond unit and integration testing, they may include functional, system, end-to-end, performance, load, stress, security and usability testing. They show the customers that the delivered code meets their expectations.

How CTDD works

• split features into small, manageable chunks, known as 'stories'

• for each story, as a customer ask when you know this story is complete, in the form of tests and examples

• write tests that, when passing, prove the code meets the minimum requirements

Bring hidden asusmptions to the surface by writing customer tests before coding the features. It enables conversations between customers, testers and programmers. Customer tests don't replace direct communication between programmers and customers, they enhance it and document the story requirements. Commitment to early test automation, makes us talk to each other when we need to - before and during coding.

Make writing tests in advance a team goal for a few iterations, until it becomes a habit.

Are you stuck in a traditional waterfall process ? What if you write customer tests ahead of development ? It can change the team's culture just a bit, so that it may be open to more practices that will improve development.

From Using Cutomer Tests to Drive Development by Lisa Crispin in Methods & Tools Summer 2005

Book tip: Test Driven Development, by Kent Beck
This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings.