As we were in the middle of developing the newest version of our VitalSite product last fall, we weren’t making the progress we wanted-even though the whole team was running full tilt and putting in its best efforts. We had always been a bit informal about how we developed software-somewhere between draconian rigid requirements and completely freeform cowboy (and cowgirl!) coding practices. The problem was that being in the middle wasn’t working. So, we looked at some of the newest practices in the industry.
We do weekly brown bag lunch “tech talks” modeled after Google’s tech talks. One of the things that caught our fancy was this one on Scrum by Ken Schwaber:
Scrum is like Lean for software development-how do you simplify a complicated process and focus on the stuff that delivers the most value? We decided we’d bring in a certified trainer and Pete Behrens of Trail Ridge Consulting took up the challenge and made his way to Iowa repeatedly over the wintery months to immerse us in Scrum.
The first two-day session was intense. It was more or less an indictment of traditional development processes (and what we had been doing). It felt like we took our entire software team, dunked them in ice water and said, “no, do it this way.” If you’re familiar with quality guru W. Edwards Deming‘s red bead experiment, he points out that “All that happens comes from the system, not the workers.” In other words, even if your team is well trained and doing its best as quickly as it can, if the system is flawed, your output will be too.
So scrum is about fixing the system.
If you don’t write code, it might not be apparent what’s different about this, so I’ll pull out what I love about it:
- Prioritization. Scrum forces you to strictly and clearly prioritize what you want in your software. Rather than starting with your wish list (and we have a big wish list!), you start with what adds the most value most quickly. Everything winds up in one list and one list only. Our clients, prospects and product team all provide input into the list (called a Product Backlog).
- Sprints. You have to take things in small bursts that are aligned with real value to end users. These bursts, called sprints, are three weeks long. At the end of each sprint, fully functional code is released. There are no half-done projects.
- Commitment. The software team commits to a certain amount of work in each sprint, visibly, for all to see. At the end of the sprint, they show it to the entire company to demonstrate the progress they’ve made.
- Collaboration. Multidisciplinary teams are brought together, daily, to make sure they’re on track. There’s no lone coder with fuzzy scope-everything is visible to everyone all the time. Our product team meets every morning for five minutes to touch base, and, between sprints, spends one day to reset and review.
- Respect. The business requirements are prioritized at all times, so there’s never a question of what is the next most important item. Business owners (say, overzealous CEOs like me) can’t arbitrarily insert new stuff in the middle of a sprint. This, with the commitment of the software team, builds dual respect for each others’ needs.
There’s a lot more to Scrum than I can cover here, but I can tell you a bit about the results we’ve seen so far.
- Since adopting Scrum, the first two releases of VitalSite 5 have been on-target, meeting both scope and deadline requirements (5.0 in January and 5.1 in May).
- Software development is accelerating each sprint – we’re approaching twice the speed we had last year.
- There’s much more collaboration between disciplines
- The morale of the software team is higher
- Quality of the software we’re delivering is better
We’re still early in our adoption of Scrum, but I have to say that so far, we’re true believers.