This post is the third in a series that began here.
It did not take very long for one of our projects to see its first curveball. As our client fell behind on providing information that was necessary for us to progress, we were in danger of running out of work. In our traditional waterfall model, that meant that we were stuck in a common position of having to pull the dev team off the project and delay the progress of the project—pushing the project day-for-day until we have what we need to move forward.
I must admit, it didn’t even occur to me to handle this a different way until someone said in jest, “shouldn’t this magical new process fix this?”
Yes, yes it should…
We got the team together and discussed our current predicament and asked them for thoughts as to how to proceed. After a surprisingly short period of time, one teammate pointed out that the information we were waiting for affected only minor details of the implementation. We could easily just implement it using what is currently known, use our best judgement for the rest, and after we present it to the client we can adjust with their guidance.
This procedure might sound familiar, if you’ve been paying attention.
With that direction, we were actually able to sand off another transitional rough edge; now we were spending less time waiting for our client to provide us with feedback so that we can start building and more time just getting things done.
Ultimately, the client’s review of what we had done revealed a small amount of rework. We sacrificed nearly a half day of duplicated effort to save us 2 to 4 weeks of delay and considerable frustration from the client. We decided that that is a pretty fair trade.
Along similar lines, we found some success on one of our projects when the client made the request for significant additions to scope. In the past, this was always something of an ordeal—even paid and clearly defined alterations to scope upset our little waterfall applecart resulting in frustration and difficulty.
In this case, the team worked with the client to properly add the new features to the backlog and order them appropriately. Because the team had already become used to ignoring the rest of our backlog until it became time to address it, it was almost entirely a non-issue. This was really gratifying to see happen, because this was a considerable pain point for the teams in the past. During the time I spent exploring the prior process, changes to scope came up regularly and with great vigor.
When I say “vigor” I mean “swearing and gnashing of teeth.”
In all, we found these cases (and numerous other smaller examples of the same) to be huge wins for the team. More importantly to me, these were huge feel-good moments for everyone involved in the migration to our new scrumesque manner of delivery. Good things are happening! Bad things aren’t happening! Benefits are being reaped in a huge, visible way! It’s a good feeling.