There is a very wide spectrum from the mythical evil-waterfall-monolith to a perfectly lean and utterly agile continuous delivery of value. In fact, scratch that, it’s not really a spectrum. It’s not even a consultant’s two-by-two matrix. It’s a complex multivariate systems-view that is needed, and fighting religiously for absolutes doesn’t help improve any of the real trials and tribulations on the front lines.
Come on – Don’t try to enforce one-size-fits-all agile or lean or kanban. Instead, create your own adaptive center of excellence from any approaches & tactics, new or old that can provide insights into the variety of techniques that can be adopted for each situation.
For example, a really well-formed support team could move to kanban and get rid of most of the scrum ceremonies. Likewise, not every multi-scrum-team product needs a cadence of Program Increment planning – but (be honest) some do.
The bigger the organization, the more important it is to be practical in your approach to change you’re passionate about. Self-check: Are you asking for a change that makes the organization easier to work in, better at serving the customer, or more sustainable as it grows? Great! Don’t let fundamentalism get in the way of the spirit of agility and the purpose of your organization.
….Especially if you are an enterprise that is “mid-transformation”.
In fact, rather than worrying about drastically changing to a new and elaborate process with all the answers (which will definitely FAIL), there are just a few underlying principles that will help evolve an enterprise toward lean agility:
1 – Each time you make a business decision, make one that makes it faster to validate your assumption than if you hadn’t made a decision at all.
Anytime you make a decision, make it easier to recover from it as an organization if you are wrong than if you had done nothing at all.
2 – Challenge the biggest assumption first, working to disprove one hypothesis at a time
3 – Each time you touch code, leave it simpler to understand and easier to change than if you hadn’t coded at all
4 – Create an environment of psychological safety for your people
5 – Do no harm to the user