Critical Path Newsletter
Keep non-developers in the loop
In a perfect world, the specs would always be complete, clear, and perfect the first time, and no client would ever change her mind. Documentation could write their manuals from them. QA could create perfect test plans the first time.
In case you haven't noticed, we don't live in a perfect world. Even the best requirement documents have holes; even the most decided of customers may change her mind about what she wants.
There's nothing wrong with that. At Macadamian, we value agility and flexibility. It's more important that a client gets what she needs than she gets what was written down on a piece of paper six months earlier.
But there’s a reason that many projects start out as a vision on paper. That paper represents a plan that communicates the understanding of the project to various different teams, allowing them to work together better.
Unfortunately, if one part of the team changes the plan without communicating that to the rest of the team, then that spec suddenly becomes a liability. For example, let's say that the project manager has a meeting with the client in which the two decide that the UI should be sky blue instead of cerulean. The client gets what she wants and the developers don't have to try to figure out what 'cerulean' is. Great change. The project manager fires off an email to inform the development team and goes for a Tim Horton's run. Everyone's happy.
Right up until QA logs a bug against the UI because it's not cerulean.
Think of all the time wasted here: the QA reading the spec, writing the test cases, testing, logging the bug, then the developer reading the bug, responding to it, then the QA reading the developer's response and responding to it. It's a time-waster for both QA and development. We estimate that a single unnecessary bug—depending on complexity and obscurity—can cost up to a day of QA and developer time.
It also creates antagonism instead of teamwork between QA and development, with QA grinding their teeth about being out of the loop and development hitting the ceiling over unnecessary bugs. It's not teamwork.
In this example, where did communication break down? Was it QA for not being up to date? Was it the developer for not telling QA that the requirements had changed? Nope. What cost QA and dev that time was the project manager not CCing QA on that email that informed development of the change.
As a project manager, it's up to you to set a good example for your team. If you want your developers to coordinate effort with QA to put the quality of the application first, you've got to make that effort yourself. That means informing QA when requirements change, and adjusting your attitude to make it more professional toward non-coding teams like QA and documentation, encouraging teams to act together.
Here are some concrete things you can do to ensure that your project's feedback loop includes everyone:
Include QA in weekly meetings/daily scrums
Even if you're not discussing QA specifically, everyone benefits from QA being included in weekly meetings (and daily Scrums, if you have them). QA get a heads-up on issues that require a spec change and may identify areas that need additional testing. For example, sitting in on a weekly meeting, a QA notes that because of a new Windows Vista UI design standard, a subset of functionality now has to appear in a popup window, so he writes a test case specifically to test it.
QA will also benefit from this, becoming more technically minded and more familiar with the internal workings of the project as it progresses.
Make an effort to include QA in the Feedback Loop
At Macadamian, every project has an email mailing list. These were originally for submission of code patches and reviews, but over time, a lot of communication started to flow through the mailing list. Having the QA be part of this list ensures that they are aware of all the changes that flow through the list.
Put requirement changes in the weekly status
If you send a weekly status report, include a section called "Requirement changes" or "Spec modifications." Send this to the whole team, as well as the client/stakeholder. This will get everyone on the same page, clearing up any confusion. A hint: this is a good place to use a project mailing list.
Wiki-fy your specs
People love wikis. Developers are much more likely to take five minutes to update a wiki spec than take twenty to contribute to a Word doc. It's more consistent with agile methodologies, for one thing, providing "just enough" documentation on the fly. And using the wiki means that there is a delta of changes available at any time. On our wiki, there's a feature that allows anyone to ‘watch’ the page and get an email whenever that page changes, which is extremely valuable for notifying everyone when the spec changes.
Also, you can actually make QA responsible for some documentation updates. Up to a certain technical point—depending on their technical level—QA can update the specs, which keeps QA in the loop and relieves developers from that responsibility.
For example, QA could be involved in documenting changes that affect UI and Architectural overviews, but might not be able to handle network protocols or APIs. But you have to ensure that everyone knows who is responsible for documenting what.
Wiki-fy change requests
Several projects at Macadamian have used the wiki to track change requests. They simply create a table of all change requests, who requested them, and their status. As the project manager evaluates changes, she updates the status. The developer updates it again when the feature is implemented. That way, changes are documented for everyone to see.
Include QA in stakeholder meetings QA are trained to identify holes in requirements, potential risks, and issues. Not only does having them attend meetings with stakeholders keep them in the loop, it also can help root out required changes and clarifications in stakeholder requests.
Consistency is key
If you’re going to adopt any of these methods, make sure you’re consistent and that everyone on the team knows the procedure. You don’t want to get into a situation where everyone thinks it’s everyone else’s job. Not to mention that if you constantly change the way you document, things will fall through the cracks.
The Loop
Keeping non-developers in the loop not only makes life easier for them, but it results in fewer non-bugs that development has to deal with and can ensure that you collect better information from your stakeholders the first time.