Agile + Scrum — a convenient fiction
Enabling agile software development in command-and-control style companies.
Agile + Scrum is a convenient fiction.
Software development is creative and non-deterministic, and is full of:
known unknowns
unknown unknowns.
Command-and-control-style ("C2") companies cannot handle that:
Internal and external deadlines that must be met!
They must be in control of "What?" and "When?"
Plans are communicated down the hierarchy.
Progress is reported back up the ladder.
Agile software development
Agile development follows a set of principles that guide software development to successful outcomes:
Scope is not fixed.
Progress is incremental.
Teams are highly autonomous.
Experimentation is encouraged —
Even though most experiments fail.
Work is iterative; there is no "Do it right first time!"
Continuous feedback and adjustment eventually wins.
There are at least 2 problems with this approach in C2 companies:
Many CTOs fear appearing incapable without predictable control over the development process, which is inherently non-deterministic.
C2 companies cannot swallow Agile without choking.
Scrum as a wrapper
Scrum is a framework that can be used as a wrapper for agile processes to make them palatable for C2 companies.
Crisp, military cadence of sprints.
Metrics can be generated, tracked & gamed.
Efficiency can be measured and misinterpreted.
Scrum can make everything appear orderly and under control.
The CTO as a buffer
However, it does not have to be a complete illusion — Scrum is quite a fine method, if you have to use it.
There is an art to managing Scrum successfully to achieve good outcomes in a command-and-control company.
As a CTO or Engineering VP, you need to buffer the dissonance between the top-down diktats of executive management and the creative engineering process.
This means that the way you represent the process outwards is not the way it's experienced from the inside:
Outwardly, you deliver the outcomes the company needs, representing Engineering as a well-oiled and reliable input-output machine.
Inwardly, your engineering organisation is an island of agility that is insulated from the command-and-control culture.
How can a CTO or VP of Engineering do this?
Interop API — Insulate the Engineering department from the command-and-control culture, allowing it to function in a truly agile way. Translate the top-down instructions into Scrum or Agile constructs, and vice-versa (see Bets).
Alignment — use your leadership and communication skills to ensure that everyone is aligned, both within the Engineering department, and with other departments. Knowing what matters to other departments helps make better decisions at all levels.
Bets — Call upon your experience to make reasonable bets about 1. the best direction to advance, and 2. what is likely to be delivered and by when.
Risk Mitigation — Foresee, identify and monitor risks, and act early when things start going wrong.
Practical Advice
For practical ideas about reducing the dissonance and risks in order to succeed with Scrum + Agile in a C2 organisation, see these 3 articles:
I love the fact that you call out explicitly the idea of a Bet (known cost, expected return, likelihood of return).
This is a concept I've been working with since I read Thinking In Bets by Annie Duke!
It's definitely a generative concept that might help with the other side of the CTO role that you mention here, for example: product portfolio management.
How are you thinking the CTO should explicitly manage these Bets?
As I say: Bet is the technical term, it has a specific meaning and a math associated with it.