My First Agile Project Part 6: The First End Of Our Project
Welcome to Part 6 of my team’s first adventures with Scrum. If you want to start from the beginning, see the table of contents at the bottom of this article. Each part stands alone though so don’t worry.
In this part of the series, I’ll talk about what we did when we approached what we thought was going to be the end of the project. As it turned out it was only the first deadline that we would miss. Near the first deadline we went off of doing Scrum sprints and planning in favor of fixing bugs as they came up in testing. This cost us a lot of team cohesion and focus. Read on to hear about what led us to missing the deadline, why we went off Scrum and how we got back on the right path. As usual, I hope our story helps illuminate some decisions teams make with the best of intentions that can lead to unforeseen negative consequences.
During our Inception Phase the vendor whose billing system we were working with came up with a development model (basically a complicated spreadsheet) that was a SWAG at how long they thought this project would take, based on how many people we had on the team and a rough estimate of how much work we had to do. The model showed we would need 9 month-long development sprints and 3 integration testing sprints. As we neared the end of the development sprints, we knew we would need more time so we said at first we would take the first testing sprint and finish up the last development. Of course we needed more than that sprint so we pushed back testing another sprint leaving about a month for final testing before go-live.
The idea with leaving the integration / User Acceptance Testing to the end was that we thought unit testing and developer testing would be enough to flesh things out during development enough that we would just be squashing bugs during the final sprints. There were a couple of reasons this didn’t work like we thought it would but that’s a bigger topic that I’ll be going into in more detail next time.
Going off Scrum
Once we came to what we thought was going to be the final push to going live, we decided not to do structured sprints and just hit the bugs that came up in testing as fast as we could. We didn’t think we had enough left to justify doing a sprint. So for a few weeks we just followed the testing team, trying to take care of bugs as they came up. The more we went along though, the more apparent it became that testing was uncovering a lot more work than we thought it would. I don’t remember when we finally admitted that we weren’t going to make the deadline but it was after we should have admitted it. We were in denial.
After the first deadline passed and we were still working hard, as well as uncovering lots of work still to do, we should have gone back to doing sprints. I think we were still partially in denial as a team, thinking we would finish up soon and be able to go live. Team denial is a strong force and I think the only way to get around it is to make sure everybody speaks up. The whole team wasn’t 100% in denial about the amount of work we had but each person’s low level of unease should add up. We all had thoughts, we just didn’t listen to each other enough and put things together. It’s everybody’s responsibility to speak up and if they have reservations about something on the project they need to make sure everybody else is listening. If we had really been paying attention to our data conversion team, for example, when they said they weren’t comfortable with the initial deadline we would have pushed it back before hitting it. And we should have been more honest about the amount of work we were still uncovering. It’s been almost 6 months since the first deadline passed and we’re still finding things, which tells us something about where we really were back then (luckily now the new findings are going on the post go live backlog).
Loss of Team Unity
Since we thought we would be going live “any day now” and we weren’t doing sprints, we lost some of our cohesion as a team. One good thing we did was keeping our morning Scrum meeting, although it morphed a little. When we were going to be hitting bugs in preparation for go-live, we decided a sit-down meeting that might last more than 15 minutes was appropriate since we would be discussing bugs more and making first passes at solutions during the meeting to expedite the work. These meetings meant we all still knew what everybody was doing, but not keeping a taskboard or doing demos ended up being much more important to team unity than we thought. It’s a subtle thing that didn’t really realize until recently but looking at everybody’s work as a team effort and showing your stuff at the end of the sprint really pulls people together. By this time we all had areas of expertise in the product and we were working largely on fixes and additions to those things independently of each other. We still worked together a lot but had we not been a close, friendly team I think we would have drifted apart a lot more.
Sprinting Again
After a few months of what I called wandering around, instead of sprinting, fixing bugs and taking care of issues from testing, we’ve recently gone back to sprints. We’ve all been broken of our delusions about going live “any day now” and know it’s going to be some time still. I think it’s a testament to our team that we’re not all disillusioned and we still have our team morale. We’ve gone back to 2 week sprints, which helps planning meetings not take all day and gives us much more flexibility. Before we went back to sprinting, we had a big meeting with our vendor to work out a plan and a new model for completing everything. This model showed we were going to be at this for quite awhile longer. Once we started sprinting again however, we blew this model away with what we were getting done and the finish line looks closer than ever. Going back to the Scrum processes we liked has really re-energized the team. It’s very tempting to try something different when things get tough but we should have resisted the urge to move away from Scrum. Not doing sprints when you’re about to go live and are squashing the last-minute bugs is fine I think but we shouldn’t have left the path as early as we did. We’re all glad we’re back on now though and moving forward faster than ever.
Next time, I’ll be talking more in depth about testing. Why unit testing isn’t enough, how we did user acceptance testing, and why we should have started our testing team going much earlier than we did. Stay tuned and thanks for reading!
My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes