If you'd like to discuss how I or a colleague can help you with Agile and automation adoption in your organisation (and avoid "the Agile Trap" discussed below) send me an email: daniel.a.prager@gmail.com
Introduction
The central thesis of my talk on Agile/XP Coaching for Automation Success (slides below) is that success in automation is 80% mindset, skill and culture and only 20% processes and tools.
My claim echoes the first of the four core values of the Agile Manifesto, that "we have come to value Individuals and interactions over processes and tools".
Backtracking a bit, why is automation a key to Agile success? Simply because in Agile (and its descendants, Continuous Delivery and DevOps) we seek to deliver quality software to our customers in a constant stream of small, continuous batches. To do so without compromising quality we
must constantly run test suites to quickly detect (and then remediate) any regressions. Running and re-running test suites is a task much better suited to computers than humans, who get bored by repetitious work, make mistakes, and are relatively slow and expensive.
Now, if you buy that argument, you may proceed to the head of the class and skip the rest of this article. Presumably, your automated test suites match the pyramid profile on the right, and you're good to go!
You have successfully made the argument that speed comes from quality, your developers understand that writing automated unit tests enables fast feedback loops and helps them sleep at night, and you are presumably delivering software into production every couple of weeks or faster. (For example Amazon, as of 2014,
deployed new code on average once per second.)
However, for most organisations, their testing profile looks more like the ice-cream cone situation on the left, and this has likely come about because the prevailing mindset and culture within the organisation is resistant to the logic and many successes of Agile software development, which is perceived as deeply threatening and irrational.
A precedent: the Copernican revolution
The situation is not unlike the stand-off in the early 1600s between Galileo and the Church. Galileo championed the idea that the Earth revolved around the Sun (rather than vice versa), a theory previously advanced by Copernicus. While not being burned at the stake, Galileo was forced to recant his claims and live out his life under house arrest, despite having convincing evidence (essentially incontrovertible scientific proof) for his claims.
Now, the important point here is that Galileo's Copernican view was deeply counterintuitive on a naïve reading, while the Earth-centric view is fairly intuitive: from the standpoint of most earthlings the Earth does feel immovable, and it is correct that the moon revolves around the Earth, and it appears that the Sun and planets similarly move around our fixed planet.
To appreciate that the Copernican model is superior requires an understanding of the limits of the Earth-centric model, and how the counterintuitive aspects can be reconciled.
Have human beings improved at integrating new(ish) ideas that go against the conventional, societal wisdom? It doesn't look like it to me!
* * *
Today there are many such mental shifts required to master Agile and Lean ways of thinking and acting. One example is valuing flow over busy-ness: the illusion that if we are busy at work we must be making a solid contribution. Henrik Kniberg calls this phenomenon
the Resource Utilization Trap and has made a brilliant 5 minute video to dramatise the common misunderstanding.
The
Agile manifesto lists four mental shifts out of the box, including the main subject of this post: valuing individuals and interactions over processes and tools.
Here's a critical mental shift I went through early in my software development career: the shift from manual testing after writing a program, to writing self-testing code in advance. Writing test code first is a bit more expensive in the short-run, after all you are writing more code, but it leads to better designs and pays off spectacularly as your code-base grows ...
My Story: How I Learned to Write and Love Self-Testing Code
When I switched from academia to software development in 1997 — making this something of a 20th anniversary blog post — I was appalled by the sheer amount of time I spent in the unsatisfactory activity of finding and remedying defects. Design and programming new features seemed to be value creating exercises, but owing to my imperfections as a programmer (and I am by no means a slouch) I was routinely spending about half my time finding and fixing bugs, both defects of design and implementation: i.e. the
crash the program type.
Worse, fixing one bug might break other parts of the program, and I wouldn't find out about this for a considerable period of time. This built up a background stress of not knowing whether the programs I worked on actually worked.
The less said about how I felt about finding defects in other programmers' code the better!
Now, being a hitherto competent academic I figured that there must already be a better way and started searching the existing literature, and soon discovered
Design by Contract. I immediately tried it out using my existing, mandated, substandard tools (
cough: Visual Basic 5 & 6) and was pleasantly surprised to find that the time I spent debugging plummeted by about 90%! I still made mistakes, but I could now find and fix them really fast. Because I made a relatively small investment in up-front self-tests, when something went awry the computer was helpfully pointing me to the location of the defect, often giving additional insights into the nature of the defect. As a bonus, the added discipline helped clarify the
design of my programs, making them more readable, maintainable, and well-structured.
In essence Design by Contract involves documenting assumptions with assertions (simple code that can be read by a human, and executed by the program). Here's an example, written in pseudo-code to transfer money between bank accounts:
define transfer-funds (from, to: Account; amount: Money)
require
non-negative-amount: amount > $0.00
sufficient-funds-in-from-account: from.balance ≥ amount
do
// code to transfer the funds
ensure
correct-amount-sent: from.balance = old from.balance – amount
correct-amount-received: to.balance = old to.balance + amount
end
In this example the require clauses tell the computer to halt the computation if a zero or negative amount is to be transferred, or if there is an insufficient amount of funds in the from account. In either case blame can be correctly levelled at the calling code.
On the other hand, the ensure clauses check that the correct amount of money has been subtracted from one account and placed in the other account. If one of these conditions are violated, the local code (shown in orange) is to blame: it didn't deliver on its promise.
The net effect of systematically following this discipline and more advanced aspects of Design by Contract is to make highly readable and code that is self-checking. Bugs are found fast, and usually easily remedied.
Do you notice that the code that does the work is omitted? With well-chosen assertions the job of the code is make sure the assertions all pass when given valid arguments. Interesting! The purpose or why is contained in what's expected (required) and what's done (ensured).
Occasionally there is a defect in the assertions themselves, but in practice these tend to be fairly straightforward to find and fix. Another objection that is sometimes raised is that these checks (especially the ensure checks) can be quite computationally expensive. While there is some truth in this, computers are now so fast that a lot of checking is quite affordable, and there are trade-off strategies that can be brought into play when these expenses become a problem: typically slower, more thorough checking against a test suite to flush out problems early, and lighter use of expensive self-tests in production.
Back to the story: I was overjoyed by my new practice of this more effective way of programming. I was having more fun, had become more effective, enjoyed the aesthetic improvements to my programs and had far more confidence in their reliability. [A few years later, when I learned about the similar, but different
Test Driven Design / Development (TDD) I was happy to find a second, related technique that gave similarly positive results. There are others in the family.]
But what was interesting (and again, appalling) was that my colleagues did not follow my lead. It was all too much trouble. The expression "bondage and discipline" may have been used. Sadly, this reaction is not unusual in the programming profession.
And don't think management was of any help: at the time they didn't "get it" either. Have you ever tried persuading non-technical management to permit
pair-programming (let alone
mob programming)? These qualitatively beneficial and (net) cost-effective techniques suffer from being counter-intuitive
and only make sense from a more sophisticated perspective.
Mindset, Skill, and Culture
So why can't people just see? When you find a better mouse-trap why doesn't the world sit up and listen?
I urge you to reflect on your own experiences of when you have been wrong. We've all been there! A tightly held belief that you've foolishly clung to, is ripped away ...
The problem is, none of us are omniscient, and there are other beliefs that we continue to foolishly hang onto, but which are they? When someone argues against your existing belief, how do you distinguish the sage from the charlatan?
Inevitably track record comes into play. If I have reason to trust someone's level of discernment I'll be more likely to contemplate their challenging idea. If not, not so much. A useful rule of thumb is that "extraordinary claims require extraordinary evidence".
Mindset
A very useful concept courtesy Prof Carol Dweck is
Growth Mindset vs Fixed Mindset. Growth and fixed mindsets are attitudes to one's ability to learn
something. A person with a fixed mindset believes strongly in nature over nurture: either I can or can't do that thing: learn to dance, do calculus, whatever. By contrast a person with a growth mindset believes that they can learn through study, practice and application.
The key point is this: if I have a fixed mindset about something I'll just believe that my level of achievement is basically set, so why bother improving and learning? That's why some Agilists have been known to refer to the growth mindset as the Agile Mindset. It really is a key to continuous improvement.
Skill
A growth mindset puts you in the right frame of mind to learn, but deep skill takes time to develop. Daniel Goleman (of Emotional Intelligence fame) makes the point that most amateurs learn until they hit about the 50 hour mark and then plateau, while world-class performers and athletes continue to learn and improve under the guidance of a Coach, who helps them mix things up and break through those plateaus to increasing levels of performance.
Pablo Casals, the great cellist, when asked in his eighties or nineties why he
still practiced for so many hours a day, replied: "Because I think I am making progress".
Of course, Pablo Casals owned a fabulous cello (the tool), but without his amazing skill very little of value would have emanated from the instrument. Forced to choose, I'd much rather listen to Pablo Casals playing an inferior cello than an amateur playing on a Stradivarius!
Culture, and the Agile Trap
We can see how coaching and deliberate practice coupled with a growth mindset leads to ever-increasing skill, but without a supportive culture you're dead in the water.
Increasingly I am witnessing what I call
the Agile Trap. Here's how it works: by introducing pretty basic Agile techniques from typically Scrum or Kanban, a team or teams will get an immediate 10% to 30% bump in performance. That's huge by normal standards, but well short of the Agile promise of
twice the value in half the time (a 400% uplift). The trap is to go, "Goody: let's push through 10% to 30% more work from here on, and slap ourselves on the back". The bad news is that even that uplift will drop off as people burn out.
The smart move is to reserve all or most of that capacity for continued re-investment. Learn UX methods so you're building the right stuff, and how to automate so that you're building it right.
Toyota has risen to become the pre-eminent car manufacturer based on a culture of innovation, experimentation, and continuous learning over
decades. My good friend, Sydney-based coach, Dave Martin expands eloquently on this point in his article on
Sustainable Pace for Organisations. Too many leaders announce victory before putting in the hard yards. They think that the end goal is all there is, and forget that the journey of learning and improvement is long and involved.
Real Learning and the 70 : 20 : 10 Rule
One of the problems that I've observed in conventional corporate training is that it seems to work as a check-the-box exercise, with too much weight placed on formal training, and insufficient attention paid to integrating and internalised new skills in the workplace.
The real test of what you've learned is to notice what happens when the going gets tough. Do you make use of the new skills, or fall back onto old ones? To truly incorporate new skills requires not just conceptual understanding — which we have seen cannot be taken for granted — but also repetition and habit-building. For example, it took me over a month to re-learn how to tie my shoes after
it was pointed out to me that I was tying them wrong. And to remain at the forefront of shoe-lacing tying technique — and in the spirit of continuous improvement —
I will need to learn how to tie my shoes again!
At time of writing the standard approach is to send employees off on a standardised two-day course and then expect them to return with skills raring to go. There are several problems with this model:
- Attendees usually only a retain a fraction of the material
- Contextualisation is left to novices
- There is typically little coordination between the follow-up activities and the training.
A superior model is to gradually integrate new skills into the workplace in smaller modules, with coaching support. The
70 : 20 : 10 rule is a rule-of-thumb for this: for every hour of formal training, plan on two hours of on-the-job coaching / mentoring on real tasks with the new skills, and then about 7 hours practice with lighter touch supervision to embed the skills.
This is the approach I have recently been taking as a consultant / trainer / coach, with promising results.
Conclusion
So there you have it. You can't buy automation (and Agile) success, but you can invest in it through training, coaching, bringing in people with the right skills and backing them to the hilt. Of equal importance is fostering a growth mindset with respect to skill and leadership, with coaching and mentoring for leaders and teams to support learning.
To have any longevity, organisations will need to develop and maintain a culture of excellence and continuous improvement, by becoming true
learning organisations. These entities will of course make full use of tools and technology, selecting and apply them intelligently and effectively by dint of their peoples' skill.
By contrast, organisations that try to buy the tools and processes while neglecting the human skill, mindset and culture will be as competitive as a monkey playing a cello!
We're on an exciting journey to change the world of work (and ultimately the world) for the better. And we're barely getting started!
