Scrum and Agile have been key capabilities of mine since 2007. (Learn more about me at Bruce Bartram, Certified ScrumMaster®.) Over that time Scrum and Agile have benefited my clients, teams, and me across four performance areas.
First, products have been delivered up to 250% faster. I attribute this to the Agile value of customer collaboration and the Scrum incremental approach. On several occasions a customer has wanted a one-size-fits-all solution when the immediate users needed only a thin slice of the requirements. Collaborating on an easier, high-value solution has allowed my teams to both follow several of the Agile Manifesto’s principles, and quickly deliver what the customer really wanted.
The Scrum incremental approach has enforced visibility to the customer of what the product looks like after short iterations. In some cases my teams have been able to shorten these iterations to nearly optimal levels (more on that later).
Second, customer satisfaction ratings have increase up to 50%. This is primarily due to the quicker delivery described above. In addition, I have recently been convinced of how critical it is to preserve engineering quality. The Scrum framework upholds a development team’s desire to build in quality, and possibly push back on excessive feature work in each iteration. Together speed and quality drive up customer satisfaction.
Third, ROI’s or business values of delivered increments have been nearly maximized (e.g., sustained 100% revenue recognition). Earlier I mentioned that my teams have shortened iterations to nearly optimal levels. The Agile principles enable a tight synergy between business need and solution delivery. As a team understands the business, and vice versa, delivery should match the business cadence. For example, if 100% revenue recognition for a series of months requires a cadence of faster output during a high-volume season, then the development team should match this with shortened iterations.
Fourth, managed services have learned that they can accurately quote increments and achieve agreement that they delivered what was promised. A Scrum Product Owner’s pre-defined release can be a convenient package of work for a Statement of Work (SOW). Building on a shared understanding of Definition of Done (DoD) for the increment goals, a managed service should be able to confidently quote the release package. Because the DoD is developed collaboratively with the customer, there should be minimal disagreement that they delivered what was promised.
I am looking forward to advanced learning opportunities around Agile and Scrum–Agile transformation for one. I have attempted some Agile transformations with limited successes. But recently I learned that this first requires a cultural transformation involving everyone in an organization, especially executives.
After some thinking, I now understand Agile and Scrum transformation primarily as an acknowledgement (and high level of comfort) that there are profound unknowns in most software development initiatives. To assist in forming this acknowledgement, I will lean heavily on the Agile value of “Customer collaboration over contract negotiation.” I favor this particular value because all the planning, process, tools, and artifacts of Agile seem to depend directly on how well a customer culture accommodates them, and cultural transformation seems to depend directly on healthy collaboration with customer stakeholders.