Many of us have experienced the refreshing and self-reinforcing flow of benefits from introducing Agile to our software development organization through scrum. As I write this, I am smiling at the memory of light bulbs going off in some of our clients’ heads as they realized how scrum can cut through the ambiguity surrounding many traditional projects to provide a clear, frequently renewed, focus on value delivery and customer satisfaction.
Of course, in many instances that fresh feeling has turned into a little bit of a headache as we struggle with the challenges of scaling Agile. This really shouldn’t be too much of a struggle because we now have approaches such as the Scaled Agile Framework® (SAFeTM) and DSDM. But, the headache comes from the biggest challenge associated with implementing enterprise Agile for software development – the need to change the organization outside of software development.
Something as fundamental to scrum as daily builds requires a significant rethink in some organizations. I can remember, on one of my early scrum implementations, being told that the IT teams required three weeks’ notice to set up the hardware for a new test environment. Important though it is, this tactical level change is not what I am referring to in this article.
The key to successfully implementing enterprise Agile is to implement strategic change. Using SAFe as an example, at the team level, the scrum teams work broadly, as they always have, with minimal impact on the rest of the organization. A benefit and constraint with scrum is that it is possible to (and many organizations do) implement it almost in a “black box” that neither impacts nor influences the rest of the organization. But as soon as you recognize the need for and introduce the program and portfolio levels of SAFe, Agile, scrum and, even software development now require changes to the way the overarching organization arranges, prioritizes and funds its work.
For example, the PMO and the finance department both need to transform their processes to enable the establishment, operation and eventual shut down of Agile Release Trains. HR needs to transform its approach to training, mentoring and career progression to meet the needs of staff placed in new roles and cycling through different roles.
How Scrum Teams Can Help Facilitate Organizational Change
So, how can the scrum teams in software development help their organizations to make these changes? By sharing and fostering the use of scrum techniques throughout the organization. Who better to coach the teams being transformed in the rest of the organization than the software scrum teams themselves?
Do all elements of scrum need to be applied to all transformations outside software development? No. Product Backlogs (or maybe Transformation Backlogs?), Sprints, Product Owners (or maybe Transformation Owners?), Scrum Teams, Sprint Reviews and Sprint Planning Meetings are all pretty much essential. Daily Standups can be overkill on more strategic initiatives, but certainly some sort of progress and impediment reporting is appropriate on a regular schedule during the Sprint (weekly on a 4-week Sprint works well). Scrum Masters may also be a less important role and should perhaps be combined with the Product Owner, depending on the team.
For us here at DCG, this is no theoretical proposal. We use scrum techniques ourselves for implementing strategic initiatives. And, we use scrum in our consulting contracts to help our clients manage their own transformations. For example, for a client needing to introduce improved IT governance and measurement, we used an Agile approach to help the senior management team identify and prioritize a Program Backlog. We were happy when they concluded that the value delivered in the first six transformation Sprints was sufficient and that no further Sprints were needed.
If you’re curious about how to apply scrum as a framework for organizational change, start with our article, “How To: Enable Enterprise Agile Throughout the Organization.”