As custom software contractors, we get the chance to work on a wide variety of projects in a wide variety of situations. Several years ago, a client brought me in to help a team on a project that had been in progress for eighteen months. It was a small talented team. We had good management support, good tools, and a good work environment. We all had a good grasp of the technologies we were using. We also had the best espresso machine I've ever seen in an IT department.
The problem was that we didn't have any working software. We had requirements documents and assigned tasks. We had a schedule in MS Project. But our team hadn't provided any business value. We dropped features, and we were still missing deadlines. When we did implement features, they were always what the business needed. We rarely demoed the software to the stakeholders. In other words, the project had classic waterfall process problems.
What We Did
The problem came to a head when we missed an important deadline. At this point, everyone on the team knew that something had to change. I went to the project manager and proposed that we switch from the waterfall methodology to the Scrum process. I remember him asking me if I had ever heard of teams radically switching their process in the middle of project. I had not, but I thought it was worth a shot.
The first thing we did was to take a week to train the rest of the team on the Scrum process. It was an odd feeling to suspend development on a project that was already late. But the project manager and I were the only ones who had any knowledge of Scrum. We were convinced that we needed to be on the same page if we were going to succeed. As a team, we watched the Pluralsight videos introducing Scrum. Next, we setup a new project in TFS using the Scrum template. Then we converted our unfinished requirements into user stories, organizing them into our product backlog.
The next Monday we started our first sprint. It was immediately obvious that there was newfound focus. Before the change, the team put a lot of effort toward secondary features. After the change, we were all working on high priority items. By the end of the first sprint, we had something that we hadn't had much of before: measurable progress.
The team thrived in the new process. After a few sprints, I asked them if they liked the change. Each member of the team said they liked it. Within a handful of sprints, we finally achieved the goal of every software project, software that provided business value.
One of the unexpected results was how much the stakeholders liked the change to Scrum. One executive told me that while he didn't know fully what Scrum was, he could "feel the difference." He also mentioned that once we switched, he felt that the stakeholders had more meaningful interactions with the developers. We were finally implementing features that worked the way the business unit wanted them to work.
The improved interactions were one part of the overall communication improvement facilitated by the switch to Scrum. The project planning meetings gave the stakeholders a place to express their desires for the software. The sprint demo meetings gave the developers a chance to show the users exactly what the software could do. The product backlog and the sprint burndown email communicated to everyone exactly how much progress the team had made and what work we would do next.
These communication tools helped to improve the collaboration between the stakeholders and the team. This resulted in software team delivering the right software sooner. This reinforced in my mind the fact that good communication is vital to the success of a project.
Another lesson that we learned was that switching to Scrum didn't reduce our planning time. To do Scrum right, you have to be very detailed and diligent. The big difference is that your effort is more focused and productive.
The other major lesson I learned from this project was that a team's methodology has a major impact on the software that is delivered. Process matters.
Each team is different. Each company is different. Think about your process. Look for ways that it is hurting you. Look for ways to be more efficient. Don't just do things because you have always done them that way. Make improvements.