Scrum and the Business Implementation

In my latest post in the Scrum series I finalized the picture of the parts required to produce a shippable product. However, the project doesn’t end there. One more step is requried and it is the business implementation of the system.

In the consultancy business where I work we develop custom systems for customers, to support the customers’ unique business processes. If we’ve done everything right, the system developed is based on the correct processes, has the right users stories implemented and has the right quality thanks to testing. That’s the end of the project, isn’t it? Not quite. There is one important step left: the business project to adopt the system and take it into active use.

Handling People

When the development is done, the technical part of the project is largely over. What remains is the people part, to get the users confident with the new system. That can be at least as challenging as the technical development of the system. When thinking about a user that has a hard time to start using a system, I first imagine an old lady, close to retirement that has no incentive to learn anything new. There’s always a few of them at each office. Fortunately, they are easy to spot and handle. With some gentle support and time to sit down and talk to them (maybe about the good old days with green-text-on-black systems) they often weaken up.

The ladies that dream of retirement can be handled. What scares me are people that actively tried to sabotage the deployment of a new system. There can be various reasons for it, but there’s always one common factor in it: loss of power. The old, manual routines are perhaps complicated and only a few employees master them. When the new system now handles it automatically, those employees special status vanish. They are no longer experts.

What’s even worse to those employees is that the roles sometimes are completely switched. The young employees that they could pushed around because they lacked the experience with the manual routines are more computer literate and quickly learn and master the new system. The young employees become the new experts.

The feelings around this can go very deep. When people loose power, they loose their professional identity. If the work is important to them, it can even threaten their very deepest, personal identity. Anyone having their identity threatened turns defensive.

If the threat is a new system – then they by any means try to spoil it.

Plan the Business Adaption

To overcome the risk of key personnel sabotaging the adaption of the new system a plan for the business adaption is required. Projects that have a plan for the business adaption rarely fails. The plan doesn’t have to be very extensive, but is has to be there and it at least has to contain a strategy for risk mitigation.

The inclusion of the business implementation in the project can make the entire difference between a successful project and a fiasco. If the business never starts using the system it doesn’t matter if it is a brilliant piece of software.

Adding the business Implementation to the Picture

It’s time to finalize my picture of the scrum project, by including the business implementation.

The scrum loop is now embedded in several layers of preparation, evaluation, feedback and governance. Nevertheless it is still there, at the center of the project. It is the scrum team that produces the actual software. The other layers are just there to ensure that the scrum can focus on what they do best: producing great code.

This post is part of the Scrum series.<< Test and Verification in ScrumHow we do Sprint Retrospectives >>

Leave a comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.