I have spent more than 25 years working in the IT business. During that time, I used the traditional Waterfall Approach that I learned at Ball State. From time to time, I would inherit projects that were in various states of disarray. These “In The Ditch” (ITD) projects didn’t fit a Waterfall model, no matter how hard I tried. On each project, we would come up with a different technique that would help get the project back on track. I have found that applying these techniques works when projects are not in trouble. Over the 25+ years of my career, I have not seen any formal approaches for ITDs.
A few weeks ago, I attended training provided by Ripple Rock to become a Certified Scrum Master. Prior to the class, I did what most geeks do: I read a couple of books on Scrum. In class, Bob Sarni confirmed indirectly what I read in the books. In listening and practicing Scurm in class, I realized that Scrum can be used in ITDs even though the original project was Waterfall.
This is the first of three posts that will outline how I apply Scrum principles in a project using a waterfall approach. The first two posts will be be geared toward keeping projects on budget and schedule. The third post will focus on the ITD, and how you can get it back on track. I can’t take credit for all of the tricks that you will read. Most of the tricks below are borrowed from a tribe of people that I have worked with for 13 years. As I am proceeding through these posts, I will use waterfall terms, and will put the applicable Scrum terms in parenthesis. The diagram below describes the Scrum process.
The first opportunity traditionally happens when you enter a testing phase. The type of testing phase does not matter, as the processes are basically the same. The steps that are usually followed are:
1) Defects (tasks) are prioritized in a defect list (sprint backlog).
2) Defects (tasks) are estimated by developers (planning poker).
3) Defects (tasks) are then identified as candidates for a release (sprint).
4) Developer and QA tester (product owner) collaborate on how to correct the defect.
5) Defects (tasks) that are fixed (developed) and do not pass the testing process are returned for inclusion in a future release (sprint)
6) Regular defect meetings (standups) are held to discuss what the status of each defect is.
While these steps were identified during an ITD, I have found these steps can keep a project from becoming an ITD. In my experience, developers aren’t really fond of this approach. They don’t like daily meetings, especially if they are going to be held accountable. Nothing is more effective in getting work done than to ask a developer what he got done yesterday, and what he is committing to complete for today. Being optomistic is inherent in the makeup of a developer, so initially they tend to over-promise and under-deliver. If you are patient, the developers begin to get it.
Try this next time you get in a testing phase. It works if you stick with it. Part #2 will follow in a couple of days.
Thanks for coming in today.