Is your goal to preserve and protect or change and convert?
Going from a traditional software development approach like waterfall to an agile approach like Scrum, Kanban, XP or Lean, will be stressful and risky. The dangers aren’t hidden in the agile approach you select. The dangers lie within the people you assign to the project. It’s not their fault though. It’s yours!
Your company surely struggles with the forces of maintenance versus the forces of change. Every enterprise company does. There are employees who are tasked with maintaining the status quo, and there are those tasked with driving change. Both types of people are essential to your company — and they will clash.
When a process works well, it needs to be preserved and protected. When the process no longer meets the needs of the company, it needs to change regardless of how long it’s been in use or how successful it’s been.
To meet both needs, companies employ two types of people — those who preserve and protect the status quo and those who change the current state and convert it into something new. Sometimes companies expect an employee to fit into both roles. This rarely works because the required personas are vastly different. Let’s examine them.
The Preserve and Protect Persona
This persona loves repetition — determine how to execute a process well, document it, and do it over and over. Repeatability is the daily bread and butter of every company. They establish policies and procedures expecting that everyone will conform. This creates uniformity that’s intended to deliver predictable and repeatable results (a.k.a. profits).
This persona isn’t opposed to change. However, the employee will insist that change be disciplined, structured and measured. This means that changes must be well thought out, documented and vetted prior to implementation. Changes must also be properly adapted to existing procedures and interfaces. Lastly, changes must be implemented in small doses so that there are no unintended consequences.
The Change and Convert Persona
This persona loathes repetition. The employee’s goal is to make things better by introducing changes to existing policies and procedures. The changes may be driven by cost efficiencies, competitive pressures, or new business opportunities. This is how companies strengthen and evolve.
This persona thrives on change. The employee is willing to take risks to the point of trying something new in a production environment, even as an experiment, so the results can be evaluated. While such actions can be disruptive and stressful, they hold the promise of rapid process conversions that are responsive to rapidly changing business needs.
The Persona of Agile Developers
It should be apparent that software developers and their managers who follow a traditional approach like waterfall tend to have the preserve-and-protect persona. (Isn’t that why you hired them?) They are trained to follow a process that contains structured documents, reviews, approval cycles, sign-offs, etc. There is even a change-control process that the business must follow to request something new.
Agile software development shuns most — but not all — of the formality and controls associated with traditional approaches. Rather than start with controls (phases, gates, reviews, approvals, etc.), agile teams prefer to start simple and add controls only if needed. People must be willing to embrace major changes to the way they operate at the outset. Then, they must accept additional changes as the team seeks continuous improvement.
An agile development conversion is disruptive and unsettling by definition. Are you prepared for the disruption? If you’re serious about being agile, get serious about dealing with disruptive change.