Does your new project team have the following challenges?
- A deadline and expectations with no reliable estimates or task breakdown
- Few or no requirements
- No repeatable life cycle to manage work now and in the future
- Bugs and rework from previous projects consuming resources
If some of these resonate, here are five steps that can be implemented immediately to get your project up and running. They describe proven steps for all of our clients in the same situation over the past 28 years.
- Define or learn a simple, repeatable life cycle to keep organized
- Elicit and write some requirements to set goals
- Derive achievable estimates to stay sane
- Assess and mitigate risks to save time
- Aggressively and efficiently find defects to save more time
If you make a mistake in one of these steps, it’s OK. After one iteration (for example, two weeks) you can systematically improve performance.
1. Define or learn a simple, repeatable life cycle to keep organized
Kids, doctors, athletes and musicians are taught to develop routines. Routines enable key skills to be implemented, practiced and become, well, routine. Success is then the result of how good the skills are within each routine and how well the routines are implemented.
A great project has routines defined to give them the result they want. One simple routine is Scrum (or any of the Agile methods). It doesn’t come with great skills, but those can be readily added.
2. Elicit and write requirements to set goals
Eliciting and writing requirements enables a team to set goals and become clear on what they need to investigate. A project with no requirements is either a valid research project, a hobby, or a hope using someone else’s money until the money runs out.
Scrum provides a very basic focus on one type of requirement, the user story. When done correctly, this is a good starting point. However, there are other types of requirements that exist, such as quality attributes, exceptions, constraints, functional, interface and system requirements. A few days spent on requirements saves a lot more than a few days later.
3. Derive achievable estimates to stay sane
Teams that struggle usually have deadlines, not estimates.
Estimates are used to set deadlines, or to validate and assess the risk of existing deadlines. They are also used to set priorities and have meaningful discussions with stakeholders. Teams that have no estimates, or at best “some numbers,” might have little or no basis to know whether they are way ahead or way behind — every day is interesting.
4. Assess and mitigate risks to save time
There are many problems that can be foreseen and mitigated and many that cannot. Great teams assess and mitigate the ones that they can so there is more time to address the ones they can’t. Really great teams learn from their risks over time and refine their routines to avoid them all together.
5. Aggressively and efficiently find defects to save more time
Defects consume team resources, and this directly impacts the current deadline. Like risks, not all defects can be predicted or found early, but many can. Great teams perform thorough peer reviews (a.k.a. inspections) on selected project artifacts and code to clean them up before they are used.
For example, the backlog of user stories is not just groomed, it is peer-reviewed thoroughly and quickly for defects. This prevents the team from wasting two-week blocks of time guessing on what to code and provides QA with clarity on what to test.
Inspections are performed on selected code and test cases. Defects are found by the team, usually at a rate of one defect per minute. When this is not done, the team’s time is consumed fixing old stuff and responding to customer complaints. A team that has 10 percent rework compared to one that has 60 percent has a lot more time to do real work.
After the work has been cleaned up, test the system in the real environment to avoid disaster. There is nothing worse than the system working great on the lab machine, but not in the customer’s environment. Inspections are used to clean up the defects that can be found prior to system testing. System testing finds most of the remaining defects.
New projects are by nature messy, usually overwhelming, and full of unknowns. Applying some straightforward practices enables a team to spend their focus on the hard stuff, not managing chaos.