An organization’s switch to Scrum is really a journey, not a destination, so it’s hard to tell when you’ve arrived. In the beginning there will be many dramatic changes and over time the pace of process improvements will slow but because an essential component of Scrum includes continual inspection and adaptation, the journey should continue ad infinitum. There are signs however that than organization is benefiting from the switch to Scrum; here are five of them:
(1) There’s improved visibility into the product development process.
I once heard a senior executive exclaim “We are being held hostage by Engineering!” It seemed an overly dramatic statement at the time but I came to understand her frustration. Software projects were given to Engineering to be estimated for time & cost and once the project was given clearance to start, the whole thing turned into a black box. The Developers were designing, then coding, then re-designing, then coding, then some testing, then re-coding and testing because requirements changed and so on with little to show for all the work and hours racked up.
The frustration of that senior executive came down to this, she simply couldn’t figure out how to provide clients with delivery dates and feature sets because estimates from Engineering couldn’t be pinned with any certainty. After that organization switched to Scrum the regular delivery of completed work provided the visibility into progress and enabled prediction of when clients could see the finished product. Now with satisfying clarity, it was known what features were just finished, what was coming up in the next sprint, along with reasonably accurate completion dates calculated using measured team velocity.
(2) There’s less ‘Product vs Engineering’ mentality.
I’ve worked in several software development organization and it has always amazed me how the “us vs them” attitude exists between Engineering and Product Management. Just to be clear, both parties can exhibit this attitude. One of the best parts of Scrum is that Product Management, in the role of Product Owner, is closely tied to the Engineering team. No longer are they “tossing requirements over the wall” and coming back after the estimated project duration to see the final product. Every day, they are in the trenches with the Developers hearing about the progress and problems and being immediately available to clarify requirements or make decisions that keep the team moving forward. This close relationship, where they are interdependent, is what erases the “us vs them” mentality as they all succeed or fail together.
(3) The business responds quicker to market needs.
Not much is faster than the “speed of business” where an organization has to frequently change course to address market needs, client demands or discovered defects. Before Scrum, Engineering resources would be tied up in projects for unknown durations and there would be a great deal of negotiation for the reallocation of resources to address emergent business needs. With the short sprint cycles under Scrum, the latest needs (enhancements or issues) wait only a short time in the queue versus having the team finish projects before becoming available. Yes, there can be immediate needs that disrupt a sprint but that is a rare occurrence with most business needs simply waiting for the next sprint.
(4) Product development throughput is higher, much higher.
Before the switch to Scrum, the individual Developers were pulled in multiple directions for various projects, research efforts and called upon to provide technical consultation. This meant that whatever progress was made was inhibited by having to share their time with all the additional work they were tasked with. After switching to Scrum, they are part of a team effort that works on what the business has determined is the most valuable at that point in time and ideally, nothing else. This singular focus enables the team to complete more work and at the end of the sprint be ready for the next set.
(5) Project risks are known earlier.
In the classic Waterfall model, projects go through standard stages of Design, Coding, Testing and Deployment. There can be more stages based on the organization but in general these four represent the essential parts. Risks associated with integration, compatibility, support, workflow or basically how the product will work cannot be known until later in the development process because there’s little to see early on. Under Scrum, because small parts of the final product are completed and delivered each sprint, issues that would otherwise be hidden until later will be exposed. Knowing about such issues or risks early on allows the organization more time to find better solutions. This foresight and ability to maneuver around obstacles sooner just wasn’t possible before using Scrum.
For any given organization there will be various signs the switch to Scrum is being successful but my personal favorite was when a senior executive was heard to say:
“We’re not going back [to Waterfall].”
Now that’s success you can measure.
© 2012 William Patrick Swisher