Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Paving the path of Scrum Adoption: (1) going upstream

8 years of playing the game of Scrum. Often injected with eXtreme Programming. A cobblestone path to reflect on.

In general, organizations have primarily used Scrum to add predictability via empirical control to the by nature uncertain IT and technology aspects of software development. Despite the great results, like Agile overtaking waterfall and the gorilla position of Scrum, there is room for improvement.

One major improvement lies in better embedding Scrum in organizations, anchoring it, growing beyond grassroots enthusiasm.

The Upstream Adoption of Scrum

Unfortunately the wide spread of Scrum implementations holds no guarantee on the stickiness of each transformation. Even successful migrations to Scrum sometimes seem to degrade over time. Because high excellence is not the norm.

One (major) reason that causes people and organizations to struggle with sticky Scrum is the lack of upstream adoption. Often it is even a major impediment on playing and benefiting from the game of Scrum.

Workfloor people don’t always have control over the formal delivery and release obligations. Often we have to operate upon compliancy expectations and ceremonial rules that have been designed and are being maintained beyond the actual experiences of building products. In many cases they have grown out of key with the rapid evolutions that are so typical for today's markets, external circumstances and internal organizational evolutions. So the least that every Agilist will do, is behave as a facilitator to a development team in mastering a project and development rather than managing it as a traditional command & control-like dictator. I refer to this as our Scrumitude: iterative phasing with end-of-iteration demo’s, mastering a Team into Sprints and self-organizing capabilities, removing impediments over being prescriptive, establishing a close relationship with Business, promoting on-site cross-functional team composition, using visual information radiators for transparency.

This appears to be very fruitful in circumstances that are not too inviting to be very outspoken on doing something called “Scrum”, or evangelizing on its advantages as part of a deeper transformation and thinking. And, after all, doing it in this ‘stealth’ mode results in on-time and on-budget delivery and higher satisfaction. To many people's surprise. Because IT projects are not known for that. And it often makes work fun again. Try setting a KPI on that!

Scrum is in a vast majority of these cases experienced as great, lives up to a sense of common sense, and it is appreciated because it thrives on and creates much enthusiasm. No surprise that this is exactly why downstream adoption, i.e. by Teams, end-users and business representatives, is generally huge.

One would expect that great results, good figures and increased productivity lead to upstream success. Experience however contradicts this expectation. Even when given the chance to explain newly gained successes, the foundations of Scrum and its essential contribution in achieving success seem too hard to capture and to accept for many old-skool commandistos when not clearly communicated and agreed upon, thereby appealing to a sense of innovation and urgency.

  • The first upstream obstacles are lower level to middle management. They like to operate below corporate compliancy radars. They have often created unique work-arounds for existing impediments, thereby acquiring them a cannot-be-missed position. They have developed the fantastic skill of pretending to be compliant with actually non-feasible standards. These management layers are less beneficial on the ‘success’ because they object the transparency and visibility that Scrum brings. After all, what's the use of work-arounds if the impediments themselves are exposed and subsequently removed?
  • The more upstream levels in general don’t care about the name or the details of the applied development processes. They just want to be assured of a corporate feel of security, preferably expressed in large process books and guidelines, so they can focus on the figures. Which is fine, by the way, it's what they are good at! When confronted with the issue of applied processes, in the best case they will tolerate a deviant process. But that is a highly unpredictable and unreliable base for deeper transformation.
The success of ‘stealth’ Scrum is doomed to be very limited. Because it disguises the essential differences. Because the real, adaptive power of the Scrum framework is totally underused. The framework is just used to get some control over the chaos that is being imposed on us. It is less intrusive, but the leveraging of lasting advantages and benefits is not achieved. Although rapid evolutions are everywhere and the way we are used to dealing with them has become overly complex, resulting in considerable competitive disadvantages. Although IT is urgently expected to take up a new role and new responsibilities in being accountable for (contributing to) business results. Although the importance of flexibility and innovation are rapidly growing. Although we need... Business Agility.

What we need is active and explicit upstream support and promotion. Think about operational IT management, sales divisions, delivery managers, product departments and hierarchical CxO management. To be avoided however is the desire for some magical, off-the-shelf implementation of thè one-and-only (silver bullet?) solution to all problems.

It will take a sense of urgency, that we need to change. That we can no longer expect any comfort from predictions. That comfort will have to come from real information and real data instead of static documents. That traditional formalism has not resulted in improved execution. That requirements change, unexpected requirements appear, priorities shift. (Fyi. This a summary of conclusions by Gartner)

About the author


Leave a comment

Your email address will not be published. Required fields are marked *.