The agile movement came out of a desire to improve the way software was developed. The agile manifesto is clear in this intent:
“Working software over comprehensive documentation”.
Frameworks such as Scrum were invented to bring something more tangible to the Manifesto’s stated intent, almost as a compromise between rigid process and free flow. It has and continues to be highly successful in helping software teams to organise themselves and their work to enable valuable products to be developed. Scrum will continue to do this.
In an agile environment on-going inspection and adaption is intended to support continuous improvement, which is why Scrum has specific events to support it. By inference there is always something better that can be done – better, not good or perfect. Nothing is sacred, therefore a team may inspect and adapt so that Scrum is no longer recognised, using something more relevant to the team and the specific environment in which they work.
Does it need a name? I don’t think so, unless, of course, you want to package it up and sell it as the new best thing to solve all the problems in the software or business world.
Where the commercial or operational parts of the business begin to see the impact that agile has on software product development, they begin to want a bit of the action. The consulting industry is very kind in the way it responds and with little self-interest invents new models and is always keen to maintain a sense of irony. Consulting businesses easily lose the intent and appropriateness.
Terms that focus upon Agile, Scrum, Kanban, Lean, or any other tool, methods or framework miss the point entirely and become a method to ease the sale of new services. The intent should be, let’s apply some of the learning from the agile movement to help our businesses “respond to change, rather than merely follow a plan”. If we do this, we help the whole business to become more agile, achieve competitive advantage and take steps to be better each time.
If you have seen the benefits of using agile ways of working in development and you want to change the way other parts of the business work, these are some simple points of guidance:
- Identify the reason that change has benefitted you already. Lean and agile principles of collaboration, visibility, honesty, integrity, value and flow are what make the difference.
- Understand how your business works. It’s too easy to assume you know and with a little effort you will find out what really happens. This is truly where external consultants can help by bringing objectivity and impartiality.
- By all means look at the various “scaling frameworks” with a view to understand their intent, rather than following blindly as a panacea for all your woes.
- Place the emphasis on your business objectives and outcomes and not on the tool or method. Phrases such as scaling agile, scaling scrum, agile in the enterprise place the emphasis in the wrong place. “Our Better Business Initiative” (or something more palatable to you) will make your intentions clear.
