indeed end up with bug-filled behemoth.
When evaluating your product, it's not sufficient just to look at it. We need to dig a bit deeper. This digging deeper part is bit of a blind spot for many agile teams. Before you wrap up your product review, do the following:
- Ask testers to speak to functional quality .
Is the product full of bugs, or is the functional quality good and improving?
- Ask developers to speak to code quality .
Is the code in good shape? Well designed? Easy to change and to add new functionality? Or is the rush to finish features compelling us to take shortcuts?
- Ask UI designers to speak to user experience .
The product may look OK, but how is the user experience? Is it easy for users to accomplish what they need to in the system? Does the product have the look and feel and general quality of experience in line with your company's standards? Or, are we just adding many crappy features into the product?
- Ask the product manager to speak to benefit and releasability .
Since we don't get value from software until we release and people use it, it's important to speak to how close we are to being ready to release. As anyone seasoned in software development can tell you, finishing all the features we planned on doesn't necessarily mean we're arriving at a product people will use and value. The product owner should talk about what is necessary to build towards a releasable product. This may involve adding more features, changing some features already built, or removing features that aren't really important.
- Use simple, subjective assessment.
Don't get too rigorous about your measurement of quality here. Adjectives and subjective evaluations are pretty good ways to describe where you believe you are.
To make things quick, I've been using a fist-to-five approach. For example, ask testers, "How do you feel about the functional quality of the product after the work done in the last cycle? Give your evaluation on a scale of 1 to 5-5 meaning fantastic, 3 meaning so-so, 1 meaning not at all acceptable." Since most people have five fingers, this approach works pretty well. I ask the question, and then ask everyone to give his rating by raising a hand with some number of fingers up. When the team sees a disparity between different members, we know it's time for a conversation.
The last thing you might do to end your cycle's evaluation phase is a process retrospective or reflection session. This is where we look back at how fast we're moving, the quality of the product, and the general health of the team. Looking at all those things lets us answer the question "What will we try to do differently?" The answer to that question usually will be changes to the agile process-the specific ways we do things.
The retrospective is much more productive when done on the back of a healthy pace and product evaluation.
If you're engaged in agile development, look closely at how you evaluative the results of your cycle. Do you look thoroughly at pace, product, and process? If not, you may not be getting the real benefit of short development cycles.