Iteration review
The
iteration review provides a visible and honest demonstration of the team's progress to the
customer. It presents an opportunity for the team to obtain feedback and seek acceptance from the customer on the iteration's
user stories. It provides closure for the iteration.
We use
1-week iterations and our iteration reviews typically take 10 to 15 minutes. Here's the basic format:
1. Gather the team and the customer together, plus any other interested stakeholders.
2. State the iteration goal.
3. Briefly introduce each user story in the iteration. If any changes occurred during the iteration, explain what happened and why.
4. For each user story, read the index card, explain any details, demonstrate the functionality, and execute the acceptance tests to show that the user story is done. Provide a summary if a user story was split or concessions were made (following agreement with the customer) during the user story's implementation.
5. At the end of the iteration review, ask the customer if they accept the iteration's user stories.
Tags:
extreme programming,
iteration review
Links to this post
Respect the iteration timebox
The iteration is a fixed timebox. And the iteration review provides an opportunity to seek acceptance from the customer. It provides closure for the iteration, which can then be reflected upon in a retrospective. To maintain rhythm, it's important that the iteration review is held at the same time, on the last day of the iteration. Don't delay or postpone it. Respect the timebox.
Obviously the aim is to get all the agreed user stories done in the iteration so that they can be demonstrated in the iteration review. But shit happens. What can you do?
Don't start a user story that cannot be finished in the iteration. It's better to descope the user story from the iteration than to partially complete it by the time of the iteration review. Always obtain the customer's permission to descope the user story or talk with the customer to see if it can be spilt into smaller user stories, one of which can be done in the time remaining.
If it looks like a started user story can't be finished in time, don't push to get it done. It's better to let a partially completed user story
slop to the next iteration than to risk delaying the iteration review. Leave it. Back out the code and demonstrate only the completed user stories in the iteration review. Don't count the partially completed user story towards your velocity for the iteration.
Tags:
extreme programming,
iteration review
Links to this post
How do conventional IT projects work out?
Like this!
Links to this post
Planning and plans
Plans are of little importance, but planning is essential - Winston Churchill
Plans are nothing; planning is everything - Dwight D. Eisenhower
Links to this post
Build it in
It's worth being test-driven and working from the outside-in, starting with automated acceptance tests. And it's worth getting done in the iteration, which means performing any supplementary testing, e.g. ad-hoc testing on a per user-story basis in the iteration. This means that testing responsibilities and skills are an intrinsic part of the team and are colocated.
Why?
There are many reasons. Here are some ...
1. You build quality in rather inspecting for it afterwards. And building it in produces a higher standard of quality than trying to retrofit it afterwards.
2. By not having
trailer-hitched testing, the lifecycle is shortened enabling you to deliver more quickly.
3. Performing ad-hoc testing, iteratively within the iteration, means you avoid tail-end crunch that usually results in cutting the amount of testing or slipping the delivery date, or both.
4. Testing within the iteration and resolving defects as they occur keeps the defect count low.
5. Keeping the defect count low means that defects can be managed more collaboratively within iterations. Write the defects on index cards and use face-to-face communication to shepherd them through to resolution. This is a more effective way to get defects resolved. Bug tracking systems provide an auditing process that is required when you have defects ping-ponging between separate development and test teams. By not having
trailer-hitched testing, you can eliminate this waste.
6. Automated acceptance tests provide less expensive regression testing. They are quicker and more exhaustive than manual regresison testing. (That's not to say that you won't require some eyeballing using ad-hoc testing, but this can be minimised and focused to test the things that humans do better than machines)
7. Creating automated tests in a test-driven fashion means your automated regression tests grow in sync with the code.
8. Automated acceptance tests can be run regularly through
continuous integration, which means regressed code can be caught early and fixed promptly. This reduces the feedback time for defect resolution.
9. Automated regression testing through
continuous integration, that's executed automatically on every code check-in, gives you confidence to make changes and move forward quickly.
Using FIT or FitNesse ...
10. Automated acceptance tests are easily understood by business people because they're written in plain English using business domain language and are formatted in tables.
11. Designing automated acceptance tests facilitates the collaboration between the customer, the developers and the testers necessary to reveal the details of the user stories.
12. Automated acceptance tests provide executable requirements.
13. Automated acceptance tests are less ambiguous because they capture the details of a requirement as concrete examples of required behaviour rather rules stated in a requirements specification document, which can be interpreted differently by readers.
14. Automated acceptance tests provide a single source for requirements and acceptance tests, therefore eliminating duplication and the divergence between a product requirements specification and the acceptance test cases.
15. Because they're executable, automated acceptance tests either pass or fail. There is no interpretation of results requiring a tester to determine whether the system satisifed an ambiguous requirement statement in the specification document.
Tags:
automated testing
Links to this post
Elephants and quality
Paraphrasing Jerry Weinberg:
Organisations that produce software for internal consumption have little competition, so they simply stagnate. Whether or not their stagnation matters depends on what their organisation defines as 'quality'. If the organisation gets the value it needs, and doesn't know any better, the stagnation continues. Once the organisation becomes dissatisfied, however, a crisis begins.
What causes an organisation to recognise that the status quo isn't actually good enough? Does it have to be an external stimulus, someone on the outside looking in, or perhaps someone new to the organisation?
What then pushes an organisation to seek improvement and take action?
Paraphrasing Jerry some more:
Organisations lock on to a particular level of quality, and change is prevented by the conservative nature of culture, which is primarily manifested in their satisfaction with their current level of quality and the invisibility of their own culture.
Is this blindness? Ignorance? A lack of ambition? Or submission?
Links to this post
BAKER'S DOZEN: Statements from an Agile subculture
At my current client, I've sown an Agile seed in a command-and-control environment. The organisation's culture is predominantly process-heavy, document-driven and full of waste. Nevertheless, my seedling grows. Nurturing it every day, I was inspired to write these statements as I witness the emergence of an Agile subculture.
1.
Create A Shared Vision that will guide your decisions.
2.
Focus On Purpose, Not Process. Concentrate on building product rather than serving process. Build product to satisfy customer demand.
3.
Think Big. Start Small. Get something small and hard-hitting out there early and build on it quickly with regular releases. Arrange work as a pipeline that delivers value to the customer in a continuous flow.
4.
Keep Things Simple. Simple rules lead to complex behavior. Complex rules lead to stupid behavior. Work by principles and not by prescription.
5. Deliver on time and on budget.
Fix Time. Fix Budget. Vary Scope. And never compromise on quality. It'll cost you more in the long run.
6.
Working Code Beats Everything. Running tested software is the best measure of progress. It focuses everyones attention. It provokes more meaningful feedback. And you learn more about what you're building.
7.
Work From The Outside, In. See everything from the customer point of view first. Understand value from the customer perspective. Be customer-driven. Ask the customer what they want next. Let the customer pull you ahead of the competition.
8.
Make Small Decisions to keep moving forward. Small decisions can be made quickly. Small decisions are reversible. If one doesn't work out go back and change it. If you need to make a bigger decision, make it at the last responsible moment when more information is available.
9.
Let Details Emerge as things come into focus and you get feedback. Worry about details when they really matter.
10.
Make it run. Make it right. Make it fast. Develop software iteratively. First, get something working. Then perfect it afterwards through successive refinements. Build quality in, don't inspect for it afterwards.
11.
Let Things Evolve. Fail fast to get feedback early. Inspect frequently and get feedback often. Learn and actively seek continuous improvement.
12.
Build Small Teams that can adapt and respond to change quickly. Work with passionate and versatile people who are self-disciplined and who motivate themselves to do good work.
13.
Be Effective Before Efficient. Don't get so busy that you lose your ability to be effective. Include slack in your capacity to give you room to maneuver and respond to change.
This post was also inspired by
Getting Real written by the guys at
37Signals.
And it's now available as a
poster at
our shop.
Tags:
agile
Links to this post
Modelling and models
The value is in the modelling and not in the model. You model to explore and understand something better. The value is what you learn from the modelling experience. The model is a side-effect of the modelling and not the result. Don't waste energy trying to keep it in-synch with the source code as you move forward.
Tags:
agile,
modelling
Links to this post
