Agile and me
Millsap presents three (3) realisations about software development:
- Change is unpredictable, inevitable, multidimensional, complex, etc.
- Responsivess to change is an advantage
- Traditional design-build methods were not working for me
He refers to Extreme Programming Explained: embrace change by Kent Beck with Cynthia Andres. The two (2) core ideas in the book are:
- Satisfy the customer through early and continuous delivery of valuable software
- Working software is the primary measure of progress
He was inspired by The Goal:
A Process of Ongoing Improvement by Eliyahu Goldratt. He puts the following equivalences:
A Process of Ongoing Improvement
|Optimizing Oracle Performance||Database Application optimisation|
|Extreme Programming Explained: embrace change||Software Development optimisation|
The Art of Winning an Unfair Game
|Baseball club optimisation|
He says does Agile for the following reasons:
- Better net profit, cash flow, and return on investment
- Higher quality
- More fulfillment
- More enjoyment
Not because it’s easy.
Five Practices from XP
The first practice is Incremental Design:
The question is not whether or not to design, the question is when to design. Incremental design suggests that the most effective time to design is in the light of experience.
There are two (2) approaches to design and construction:
- Traditional Design-Bid-Build in which the design was air-tight so that construction could proceed without any further guidance from the architect.
- Architect-Led Design-Build in the architect remains involved throughout the project through information and cost feedback loop.
These correspond to, in the software development world, to ‘Big Design Up Front’ and ‘Incremental Design’ respectively. The former is the factory mode of production, while the latter is craftsmen based.
The second practice is Rapid Iteration:
Working software is the primary measure of progress.
Millsap says that the worst software in the world is “…90% complete, but nobody can run it yet.” The remedy for this is the feedback loops mentioned above are actually delivered software that generates feedback about usuability and performance. These are used in the next incremental design to get closer to the goal. Yet there is a working version of the application that may not have all of the functionality, but can be used by the customer.
The third practice is Test-First Programming:
Continuous testing reduces the time to fix errors by reducing the time to discover them.
This works as follows:
- Add a case
- Add a test
- Run all tests. Only the new test should fail because the code does not implement the feature yet.
- Write code
- Run all tests again and all tests should now succeed.
The fourth practice is Pair Programming:
Silence is the sound of risk piling up.
The fifth practice is the Ten-Minute Build:
Practices should lower stress. An automated build becomes a stress reliever at crunch time. “Did we make a mistake? Let’s just build and see.”
How Agile has helped me
Big Spec == Big Mistake. The specifications do not clearly convey the customer’s intent nor is a viable basis for a test plan.
Maintain only the code and the tests as permanent artifacts. Generate other documents from the code and tests.
Regression Testing == Awesome
Incremental Design == Better Design
Build something valuable that runs, and release it.
What I want is not what I imagined.
The key benefits are:
- Usable software earlier
- Experience informs the design
- Better design in the end
What has not worked
The most damaging thing to a project is the absence of the CRACK customer (Collaborative + Representative + Authorised + Committed + Knowledgable).
Another problem for a project is Too Many Customers. Great Design is also about No.
There is also the Cultural Mismatch problem:
agile is about decentralization of responsibility, accountability, …
centralization + agile == hypocrisy
agile requires openness, honesty about where failures are
The Talent Mismatch problem:
undisciplined + agile == chaos
participants must actively design, optimize
key skill: project factorization to produce running, valuable software every n weeks