From Waterfall to Scrum
How do you scale your development processes?
Once upon a time Red Gate had a single development team. It was small enough to write software for a new product by doing a few iterations of the more traditional waterfall method.
We now have something like eight development projects, 13 products for continued development and new ones on the way, and nearly 40 developers and testers to keep interested. We need development processes that scale. So, we turned to Scrum, an agile process for complex software development.
Along with four colleagues, I recently attended the certified ScrumMaster Training course. We already have one Scrum team up and running and other teams using some of the principles. Now that that I’ve considered it further, I really believe that Scrum is a framework we can take advantage of. But, it’s not going to be easy to fit our current processes around Scrum.
Beyond “single wringable neck”
Red Gate project managers in the past have been the individuals responsible for building the right product in the right way. It’s a tough call delegating tasks, making project estimates, managing risk, helping to support the current product, researching for future releases, and above all, keeping spirits up.
Having been a project manager on both large and small projects and bearing the weight of being the “single wringable neck,” I am lapping up the Scrum approach. The roles are different; it’s the product owner who takes care of whether the team is building the right product. The team takes responsibility collectively for building it right. The ScrumMaster facilitates the team, but doesn’t manage the individuals; instead the team is self managing! This sounds amazing. Can it work here?
In the past year we have ramped up product management activities hugely, and it shows. Currently, project managers work together with product managers to get a project to the “greenlight” stage. With the work research product managers have done, we know a lot about the ROI, future plans beyond this release, and who we are building the product for.
At the greenlight presentation a panel (none of whom are on the development team) decides whether to take the product as planned into full development and agrees on deadlines for when it will make it to market. Product managers are still involved during development and help guide the team to making sure we are building the right software. They also make decisions about how features are implemented and the priority of work.
Focus and visibility
Using Scrum, a team should be able to demonstrate what tasks are done at the end of a Scrum sprint (typically three weeks). Following the planning stage at the start of the sprint, it’s inevitable that new tasks come to light, such as bugs or GUI tweaks. These are either handled in the same sprint or moved onto the backlog for the subsequent sprints.
There’s a lot more focus and visibility. It is easier to accurately predict how long the remaining work will take because the team is learning how much work it can handle during each sprint and how much extra work each task typically creates.
There is less frustration if the goal posts need to be moved during a project, and shifting of priorities for new designs or features is handled more efficiently. Since the completed sprints, the tasks in progress, and the backlog for the next sprint are visible to the product owner, swapping a feature priority on the backlog is perfectly fine. That’s not usually the reaction when projects are forced to deviate from the original plan!
I remember a situation on a major release where we planned several eagerly awaited features at the start and used a finger in the air to estimate when we’d be done. Developers started coding the complex problems but moved onto the next one at the point they had solved the difficult, most risky element of the solution. Getting them to finish any feature off so that we could test, run usability tests, and write documentation was nearly impossible.
The developers argued that by taking the complexity out of each of the features we were planning to implement, they were removing risk from the project deadline. But inevitably the software was shipped later than planned. Usability engineers weren’t able to put a working product in front of an end user until we were way into our development journey. As a result, the changes we made based on user feedback put us behind schedule. No one on the team, let alone the greenlight panel, was able to see any finished part of the product working.
Writing software in sprints, where you demonstrate finished tasks, however small, provides visibility that benefits everyone.
Who’s the owner?
At Red Gate, we want to provide an environment where people good at writing code, testing software, designing interfaces, and writing technical documentation can flourish and get on with what they are good at. The self-organizing Scrum team encourages this.
We already have individuals who would be able to facilitate teams in this way and make sure there is respect and openness. In my opinion, the biggest obstacle we face is how to make the product owner role work. It might be a case that the product owner is a combination of individuals, including a product manager and a usability engineer. They collectively are responsible for building the right product since they are the ones talking to end users, who ultimately determine the success of our products.
How are you doing it?
Are you dealing with development scaling issues? If so, how are you handling it? Would Scrum work for your organization?
Have you tried Scrum? If so, what has been your experience? What are the best and worst things about Scrum?
Post by Helen Joyce