Regardless of whether you are doing iterative development or use waterfall methods, you may be struggling to get agreement on whether a delivery team is on track or falling off expectations. This blog covers techniques that can help business and technology teams agree on how to track progress of a technology project.
The Black Box: is any comparatively small, usually black, box containing a secret, mysterious, or complex mechanical or electronic device.
One of the key complaints of a pure waterfall development approach is the reality that a project may not show any results (or provide any feedback) until the software is completely finished. In other words, the business really has no idea if the project will meet their needs or is on schedule until the software is delivered.
For example, we start a project in January. It may take through February for initial business architecture and design to be completed. It may take another month or two before software is actually being developed and delivered to the testing team.
The business may not get any visibility into working software for six months or more.
This is what I call the Black Box Effect. We need to find a way to eliminate this effect and have an agreed upon approach to determine whether a project is on track or not.
The benefits of an iterative approach
There are many reasons an organization may choose to move to an iterative development model such as Agile or Scrum. One of the more important reasons is to gain more frequent feedback on whether what we are building meets the real business need.
Are you tired of the business saying, “What did you do to me? I thought we were going to have this done.” And are you tired of hearing yourself say, “Well, I thought we were going to have THIS done!” If that’s the case, then you are obviously not in agreement and have a “visibility” problem.
Visibility isn’t a project plan!
Visibility isn’t a project plan that tracks progress. Visibility is agreeing that the business can get access to completed functionality. Visibility means the business can see how the software being developed will help them achieve their business objectives defined earlier in the process. If they can get visibility into that on a regular basis, then we can agree on whether we will be able to “high-five when the project is done.”
Not only do we need to provide the business visibility on progress, but we need to allow the business to re-evaluate their priorities based on the progress seen. Consider this a feedback loop, allowing development teams to constantly re-evaluate and tune their approach.
I use three key opportunities to provide visibility and get feedback from the business: QuickPeek, Showcase and Release.
At the end of each iteration, the team should be able to show software that has been developed and completed through unit-testing. The software may not have been put through functional testing or even integration testing, but it has been completely unit tested. There may still be remaining defects.
We encourage the business to review each iteration’s results and make sure we are on track with their expectations – even if the code is not yet packaged for deployment or completely system tested. Remember, the QuickPeek is typically informal and just to show the iteration progress.
Even in a Waterfall process, you should be able to start identifying key components being developed every two weeks that can be “viewed” by a business stakeholder for feedback. Maybe some deliverables will take a week while others take up to three weeks.
I believe you can introduce a QuickPeek on a regular basis without too much intrusion into your current corporate process.
When a release is going to take six or more months, there is value in planning a Showcase. This is a formal review of a set of features or system components. Functional testing is typically complete and it shows complete business scenarios or processes at work.
However, it typically is not ready to be deployed like a release.
The purpose of the Showcase is to demonstrate the functionality of a complete component to a wider group of stakeholders. It is also used to celebrate progress and create a common vision around the new solution.
Even in an Agile world, you may not be deploying a release until Iteration 10 or 12. Therefore, there probably is value in creating a Showcase around Iteration 4 and Iteration 8 to provide greater visibility and market the progress you have made.
Eliminating the Black Box creates Visibility
I hope these techniques can help even a waterfall shop create greater visibility and market the progress the team is making. Throughout the development process, it allows the business and I.T. to develop a common view of progress and decide whether adjustments need to be made to the final product.
Do you incorporate all of these techniques? If not, what are the obstacles?