Scrum: Back in Control

I was reading CIO magazine and came across a great article by John Troyer on how to get your project back under control. The article for the most part is great, but there are a couple of points that I'd like to discuss on the issue of using Scrum to assist in project delivery.

Scrum, due to its iterative nature, is an excellent development process for BPM projects that I use consistently at Renewtek.

Although John says that Scrum is one way to manage iterative projects, he also mentions "two significant drawbacks" with Scrum.

"First, there is a real risk of investing too much time in Scrum sessions. A good target for communication is 5 percent to 10 percent of the time. A project suffers when communication drops below 5 percent of the time, and the benefits drop off significantly around 9 percent to 10 percent.

Scrum sessions should take 30 minutes, about 6.25 percent of a day, which fits nicely into the optimum model — so far, so good. Theoretically, that should leave just enough time for other reviews and the management reporting that is necessary in an ideal world.

"However, it is rare to find team meetings that last only 30 minutes. It is far more common to find the entire daily allotment of 48 minutes (10 percent), if not more, consistently consumed. By the time the coordination, the other the necessary reviews and reports are complete, team efficiency and effectiveness will have dropped significantly into the unproductive zone, squandering the assigned resources."

According to best practice, Scrum meetings should be timeboxed to 15 minutes regardless of team size. This may sound like an impossible task, but each team member should only be asked three questions.

1. What did you do yesterday? 
2. What will you do today? 
3. Do you have any impediments? 

If you try to solve impediments during the stand up meeting, then you are doing it wrong. I realise that this falls below John Troyer's 5 percent communication, but don't worry communication occurs constantly with Scrum.

"Secondly, Scrum-based implementations are subject to the same risks already highlighted above. Each iceberg becomes its own little world, drifting away and subject to tactical adjustments. 

"These tactical adjustments are often the result of environmental shifts like a shift in management, a key decision maker becoming aware of some new buzzword or concept, or economic and political changes. More often than not, these adjustments dilute the strategic impact that the original, overarching project was supposed to deliver."

Scrum is designed to incorporate change, so tactical adjustments should be absorbed within the Scrum process. In fact, this should reduce the overall risk by minimising the rework from such changes and by providing more accurate costs and estimates to the business.

No process can reduce this impact to zero, but Scrum is a great way to minimise it. An organisation should also seek to use architectures that maximise reuse such as BPM and SOA.