High energy teams are not exclusive to agile. One of the principles of agile approaches that has a strong contribution is time boxing, as everything in agile has a fixed duration: the number of weeks for the iteration/sprints, the duration of the daily scrums, planning, retrospectives, etc. Time-boxing establishes cadence and, after two or three iterations, the team learns how much output they can produce. In addition, having short term goals keeps the teams at a constant high pace and productivity. Many project managers today see the traditional waterfall approach as a dinosaur, a dysfunctional approach that should be avoided. This is simply not true, as waterfall is not only a valid approach but the only option for certain types of projects that don’t fit agile. The implementation of COTS (commercial off the shelf software) relies heavily on scheduling, as training sessions need to defined, rooms booked, etc. There is no way out: you need a schedule, and a detailed one. This just can’t be done using agile. Using waterfall is not equivalent to a low-energy team. There are no “sticky notes”, colourful project walls and you don’t feel proud to be a pig (yes, in agile being a pig is a good thing) and you can call non-team members chickens. While not as colourful, a waterfall project can be high energy and lots of fun. Cadence is one of the strategies that turns a waterfall project into a high energy team, and is defined at two levels:
• A weekly cycle for execution: in essence, this is similar to a weekly sprint, without the rigour of planning and retrospective that agile has. The weekly cycle starts with the gathering of information on actuals at the end of the week, usually Friday afternoon or Monday morning.
The PM updates the schedule with these actuals and assesses the situation of the project: is the next milestone (always the next milestone) still on track? Then the PM meets with the team with the schedule visible to everyone, so the team can visualize the situation, come up with ideas to bring the milestone back on track if needed. Adjustments to the schedule are done “live” by the PM in front of the team so, at the end of the meeting, everyone leaves with a clear idea of what needs to be done this week to stay on track. After the meeting the PM makes final adjustment to the schedule and generates the weekly status report, which becomes a by-product and not the main purpose of the weekly cycle.
• Milestones that keep the team at the right level of effort, not too distant that allows for slacking for a week or two after a milestone is achieved, similar to what happens in college after mid-terms. Milestones should not be to close either, because if the team achieves a milestone every few weeks, they become meaningless, losing the power to motivate as a visible and common goals. Research done a few years back by the PMO Executive Council identified 40 drivers of excellence in project management, and the number one driver was “Obsession with the achievement of milestones”. As a side note, “Following Project Management Practices” was the last on the list, still important, but not as much as other drivers. There is no “rule of thumb” to define the number of milestones or the interval between milestones, but there are some “old dog tricks” to plan milestones:
o Make your milestones aggressive but achievable, and always protect the milestone with a buffer or contingency.
o Spread the effort in a way that the early milestones are easier to achieve, because the project is still ramping up, resources are not all on board, etc.
The middle section of the milestones should be very demanding for the team, as this is the time to make progress and plow through work. The final section of the milestones should be easier to achieve, as the final stretches of every project always discover new things and, there is less room to maneuver as you approach the final milestone. In particular, the first milestone needs to have a high degree on confidence. Why, because it will become the prophecy for the team on whether they can achieve the milestones or not. As Seneca, the Greek philosopher said “Whether they think they can or cannot, they are right”. Cadence is a fundamental principle of project management which, as discussed earlier, comes “built in” in agile approaches. When using waterfall, cadence will be a result of planning, for milestone definition, and a project management plan for execution. So you decide: tango or cha-cha?
