The Agile industry or Agile community has collectively /
organically solved many of the early problems of ‘doing Agile’. For example, in
2003, scaleable elastic infrastructure was a dream, DevOps as a term
did not exist, neither did Gherkin, JIRA, Rally, or many other tools now readily
available in the marketplace.
We now know that Scrum works and has been proven to
work, we know that XP design, code and test practices are essential for high quality
code and its longevity. We know that BDD combines both the
definition of the system and the testing of the system into a single activity.
We can create dynamic, containerised CI development pipelines
that measure code quality, vulnerabilities, build quality, build times, and we
can integrate our automated tests into multiple suites to optimise our
development pipelines.
We’ve learned how to become far more objective
about product development, we have tools for automating the Product Backlog and
providing full end to end traceability and auditability to understand the
commercial impact of product decisions and development.
We have strategies for rapid customer feedback in
the development cycle and post-production in order to optimise products and
services for improved customer experience.
What we haven’t collectively learned yet is how
to consistently enable companies to adopt agile practices, behaviour and ultimately culture without either temporarily impacting their performance in a negative way, requiring large budgets for the transformation, or diluting the Agile adoption.
This dilution is becoming more prevalent,
to the point where in some companies Agile is just a part of a wider portfolio of work that does
not directly correlate to improving the goals of the business. I fear this
latter outcome is what is now becoming ‘mainstream Agile’.
A Word on Scaled Agile Models
I think that the Scaled Agile methodologies are
useful if taken as pattern libraries to be used selectively as the context
allows. Being a trained practitioner in both the SAFe & LeSS methods, my personal preference
is for LeSS as the originators intent was to take the
good parts of Scrum into the wider enterprise, vice finding a means of
‘managing’ multiple Scrum teams. The best part of LeSS for me, is that we are
encouraged to only put in place the structures / components / activities that
are required for that context and the problem you are solving.
At times, scaled methods such as SAFe prescribe too
many artifacts and almost remove one of the key philosophies of
Agile, which is getting people to think and work differently.
Prescriptive approaches rail against the point that all contexts differ, and
therefore different solutions are required.
Our people, markets, products, services, finances, operations,
and location are all unique – so how can one scaled model meet the needs of
every company? We need to learn from the models, and treat the various
structures and processes as a toolkit with which to succeed within our own
contexts. i.e. understand what others have done and use our brains to find the most appropriate solutions for the challenges we face.
Showing the full SAFe organisational structure
often puts people at ease as they can see a seat for themselves in the future…
However, if you then find that the role is superfluous to your context, it is
far more difficult to remove people than it is to add them.
Finally, the Scaled models focus on what the final
‘view’ of operations/ development should look like, not on how to get there… I
asked Dean Leffingwell about how to approach a SAFe change implementation to which he responded “train
everyone up and get started…”, I got the same answer from Bas Vodde. I understand that the point is to get started and change your business, but there really isn't much guidance in these models for effecting the change.
We need to use our brains far more, encourage
others to do the same, and learn more about culture and organisational
dynamics, which means a shift to new skills and learning for anyone wishing to
help companies successfully become Agile.
In the next blog in this series, I
hope to introduce the concept of patterns and pattern libraries and then describe a number of successful change patterns that I
recently presented at Agile:MK.
Comments