Last summer we began transitioning to an Agile workflow. In the fall my group implemented scrums and sprints. As the lone writer, I had already been regularly attending developer meetings. I didn't really see the difference except for the frequency and length of scrums versus meetings. However, several things became apparent including that our productivity has improved. I started reflecting on what exactly it is about Agile that makes our team more productive.
It dawned on me that the effectiveness of the scrum meetings is largely due to the approach Agile takes on deadlines. Instead of some vague, out-there-in-the-future delivery date, we have a two (or four) week expiration date for the work we're doing right now.
Most of our guys lean towards being B-type personalities: folks who tend not to notice a deadline until it's immediate. Not to say the developers and testers always put things off to the last minute, but rather that they're generally in the habit of taking it slow and easy until the deadline is nearly upon us. This habit leaves very little time before a deadline for full testing and even less time for completely updating documents.
But in an Agile sprint the deadline is always just a few weeks away. Suddenly the delivery date isn't an intangible concept, but a real and immediate matter. After several sprints, the developers are beginning to understand that the deadline must include QA and Doc completion.
With this pressure of a looming deadline and better understanding the Definition of Done, we're finding an amazing degree of reliability in our own team. No longer is there the impression of indifferent coworkers failing to take things seriously until the time is critical and everyone is under stress.
The immediacy of the sprint deadline is ensuring that everyone feels a sense of urgency for deliverables. And that makes the whole team more productive.



06/13/2009 04:23

You've pointed out a major benefit of Scrum: short-circuiting Parkinson's Law - Work expands so as to fill the time available for its completion.

A few others are avoiding "analysis paralysis" and multitasking. Assuming that work is waiting for the worker, not the other way around, multitasking ALWAYS delays the completion of every task ( Multitasking will succeed in making tasks start earlier, but increasing work in process is not the goal - completing tasks is.


Your comment will be posted after it is approved.

Leave a Reply