This post is an assemble of notes from sessions at Agile 2008, including Paving the Way for Agile Testing, Expanding Agile Horizons, The Five Dimensions of Systems by Mary Poppendieck, Natural Laws of Software Development – Deriving Agile Practices by Ron Jeffries & Chet Hendrickson plus keynotes from Uncle Bob Martin (Quintessence) and Alan Cooper (The Wisdom of Experience).
There is plenty more to consider than what is written here to on the topic of quality, of course, but these stood out for me in the sessions I attended.
Do the Engineering Fundamentals
Of all the things I heard at the conference, these were repeated again and again, in varying contexts. Why? They are proven to work. Bob Martin argued that these should be embodied in the Agile Manifesto by adding a 5th Value: Craftmanship over Execution. He argued that those who work in software development need to take more pride in their work, and insist on doing the things that must be done produce quality work.
Refactoring
- Allocate time in advance for refactoring
- Need to ensure customer understands need to to increase technical debt, even though refactoring may not have “business value”. You either make small ongoing payments to keep debt manageable or face huge debt later. May want to have customer sign off on this.
Test-Driven Development
- Kent Beck’s definition: First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find.
Continous Integration
- Without CI, small releases are difficult to do, integration problems aren’t found until much later.
Acceptance Tests
- These describe what the stories should do, with real examples that can be executed in code.
- Need to be automated, becomes more critical after each successive iteration.
- Acceptance TDD – acceptance scripts written ahead of the code, written by testers and devs, FIT / Fitnesse recommended tool
Need Technical Leadership
From Lean thinking: have a development manager, someone who is a technical leader who is responsible for successful engineering practices. I see this person overseeing the use of the engineering fundamentals listed above. There needs to be leadership in our teams, from both a technical and management perspectives.
Definition of Done is Foundational
Everyone on the team, as well as the client, needs to agree on when a story is considered complete.
- Define your Definition of Done (DoD) before the first iteration
- A definition might include:
- Unit / integration tested
- All acceptance tests pass
- No increase in technical debt
- Example definition at Menlo Innovations:
- Developer asks the QA/HTA pair for a “green dot”, but before asking, all unit tests must pass, code must work on machine other than developer’s own
- Keep the definition visible for the entire team
- Only a strong DoD (with many automated tests) will be maintainable
- Maintaining a definition of done begins by first building trust. Trust might be demonstrated by granting full access to modify docs and code, providing the tools and support the team says they need. “The first thing to build is trust” – Brad Appleton
Specialized Testers Can Ask Questions that Need to be Asked
- Actively seek out defects
- Provide feedback, saves time
- Test-specific knowledge and techniques, can help others to test better.
- Good at asking questions during iteration planning
- Can offer feedback on documents and unit tests
- Can assist customer in translating requirements into acceptance criteria, writing acceptance scripts
At Menlo Innovations, QAs spend their time (in order of time spent):
- Asking questions
- Understanding user needs
- Understanding development implications
- Do some testing
Interaction Designers Can Turn Raw Data Into Useful Requirements
Alan Cooper argued that interaction designers (ID) bring an essential element to the team’s success:
- Interaction designers can make sense of human behavior in the same way that a programmer can make sense of a computer’s behavior.
- Their key contribution is translating research into actionable sketches and narratives that programmers can use. Their work frees programmers from communications failures, management misunderstandings, and wasted work. Those sketches and narratives are like user stories except that they are more accurate, more precise, more detailed, more correct, more complete, more readable, and more understandable by managers as well as by programmers.
- Research shows that users don’t really know what they want or need. Where interaction designers can deliver significant, unique value is in their ability to distill useful answers from the distorted, raw data extracted from, or contributed by, humans. Interaction designers use ethnographic research, user models, scenario construction, role-playing, and other specialized tools for the distillation process.
- “The operation was a success, but the patient died”. It is not uncommon to have a successful, Agile development project that still fails to satisfy the user.
Other Tidbits
- A method to prioritize bugs: place bugs in one of 4 quadrants: likelihood of occurrence vs. importance to client.
- To verify a build:
- Generate a list of questions, like “Can a user log in?”
- Answers not provided, as they may change
- Questions generate conversation