The last post on quality of design and development seemed to get a lot of traffic (hopefully for the right reasons). The "Q" word being such a loaded proposition I wanted to now go a little deeper into how agile practices and quality are inter-related.

Click "read more" for the goods...

First off, a sprint, as defined in agile practices, is a time-boxed collection of requirements delivered at a precise level of expectation. Moving AOL Programming to agile will have a significant impact on the quality of experience for a few reasons:

1. Since the focus of a sprint is on fewer high-quality features than usually contained in a waterfall release (where features are piled on at one time), there can theoretically be greater attention to detail in the execution. Conversely, a sprint that ends in a backlog of bugs from the preceding sprint has to be classified in my view as an unsuccessful team effort. In assessing the team's performance, the Program Manager and Tech PjM should consider how much was baked into the sprint, how clear the expectations were, and what the core competencies of the team itself actually are. In the end, buggy work could not have been effectively resourced or managed or too much may have been attempted in the time alloted. I want to repeat this because it is an important idea: a successful sprint is relatively bug-free in code AND design. Don't let anyone tell you anything else. The focus that agile provides and the open and lean real-time collaboration is what allows quality to happen.

2. UI and Web Designers are working on "just in time" design and not conceiving an entire system all at once. Therefore, they have more time to get their interaction design parts right on the prioritized features and to then actually work on the implementation itself. My experience with prior processes often seemed to be to spec out all of Western Civilization, only to find out that Rhode Island was actually deliverable in the end. Untold hours of product and design scrubbing through screens to be made months in the future yielded very little except paychecks for disgruntled employees. Many of us have been there in our careers in any company. Again, in theory, those days should be over now with agile. Yeah!

3. Quality is as much about what you are doing as how you're doing it. In other words, Quality is not only in the execution but in the integrity of the original idea that has the team mobilized in the first place. Ensure that what the team is working on in the sprint maps directly back to unmet consumer needs as identified in your initial strategy phase.

To summarize: Lean teams focusing on the excellence of fewer features is the key to Quality.

Some folks in my wonderful photo team provided feedback that they should have been in the last post on quality (or this one for that matter). My next post on the "Q" word will be on the content we put into our products, separate from design and development. Don't worry gang, I'm getting to you. ;-)

Related Links: