Adventures with Agile interviews Alistair Cockburn

Alistair needs little introduction as the co-author of the agile manifesto, software
development expert and poet. Adventures with Agile (AWA) were delighted when we co-hosted Alistair's awesome "Return to the Heart of Agile" talk earlier this year at IBM's Southbank studio, which you can watch back here. 

Ahead of Alistair's Advanced Agile Master Class in London next month, we asked the AWA community what questions they had for Alistair. Please continue reading below for Alistair's insightful answers.

1. Do we need a better Roadmap to Agile?

For some years we’ve used Scrum as a Way point, however it’s mostly interpreted as a formula to be followed as specified whilst the underlying principles are ignored. Dan North points out that we’ve got the priorities wrong. Gil Broza says we’ve forgotten the Agile principles. Given the experience we’ve now gained is Scrum the way to Agile?

and

2. In your talk at Adventures with Agile (AWA) earlier this year, you mentioned the difficulty that companies are having transitioning to Agile with their existing people, and I have found this to be true also. 

However, Agile is still gaining popularity and is used by most software producing companies (according to the version one survey), how do you explain why people cant do the transition with their own people, and how can they improve their chances of success?

A: I think those two questions are related. Actually, I’ll take the second one first…

Consider that two factors are in play in agile adoption: diversity in personalities, and the shu-ha-ri progression.

Diversity in personalities should indicate that not everyone will like this different way of working. Agile development calls for:

• increased personal communication,
• speaking and accepting bad news about the project or situation, and
• living with increased ambiguity, flux, uncertainty.

Not every personality will enjoy those, indeed, it is easy to imagine a large percentage of people find them very difficult. For me, the ordinary diversity of personalities indicates an upper limit to the acceptance of agile practices.

Imagine, also, the personalities and priorities of people selecting where to work. Those going for small companies and startup are more likely to be risk-tolerant, and hence more able to adapt to the agile workplace. Those selecting large companies and government agencies are quite likely to be people who just want a safe, stable source of income, and less interested in adapting to the three demands of the agile approach.

Now imagine you go into one of those larger companies and say, “We’re going to change the way things work here, make it different, unstable, ambiguous, you will need to offer out and accept bad news with equanimity, and trade internal information more.” That’s a big ask. To me, it is not at all surprising that large companies have trouble making the shift to agile – it is just going against the sociological / psychological norm.

Hence we see it is a reasonable strategy to open a new location, and say, “All people who want to work in this agile fashion, head over there.” Those who are inclined toward the new value system will head over, those who aren’t will stay where they are.

This is all natural.

Add in the Shu Ha Ri learning path. Scrum, as Crystal, and agile in general, was originally defined at the Ri level, that is, without much instruction. However, beginners naturally asked for more instruction. Bit by bit, over the years, Scrum became more and more prescriptive, until now it is taught as a very formulaic method, quite the opposite of what the inventors intended 20 years ago. But that is the nature of adapting a method to reach hundreds of thousands of people.

Is there a way out of this bind?

The Heart of Agile is my best shot at getting people to do something close to whatever the https://AgileManifesto.org intends just from a natural and intuitive reading:

• Collaborate – Do I think everyone knows how to collaborate, and knows how well they are doing at it? Yes, I do. It should be pretty obvious.
• Deliver – More difficult is delivery, because delivery can actually be difficult, and there are nuances around the word delivery. However, yes, you really do know if you are delivering to real customers, and you know if it’s getting better or worse. So, deliver.
• Reflect – Most difficult of the four, because people are not used to pausing to reflect on the situation. But still, with only a small amount of coaching, people can easily get the hang of doing this every week or month.
• Improve – People think they are improving, but without delivering and without reflecting, they don’t really know. Delivering and reflecting give them an idea of whether the “improvements” are actually making a difference.

Those four are simple enough, and rich enough, to serve as new guide posts in the path to being more effective.

In the Shu-Ha-Ri progression, I hope not to have to expand those four into Shu-level instructions. But at https://heartofagile.com, I am creating the FAQ section so that answers can be given at the Ha level, not the Shu level.

What does a Ha-level answer to a question look like?

A Shu-level answer to a question is to recite a recipe. For example, in answer to “What do we do at the daily Scrum meeting?”, the official answer is “In the daily stand-up, ask the following three questions: (insert here the standard three questions from the Scrum guide)”

A Ha-level answer gives a list of possibilities. Here is one from https://heartofagile.com/daily-stand-ups-too-long/

• Our daily stand-ups take too long, what can we do?

• Ideas:Your Ideas Here:
  • Call them “Daily Stand-on-one-leg Meetings” and see if that helps
  • Put an alarm clock in the middle, which rings after 8 minutes
  • Rotate time-keeper assignment, no discussion goes over 2 minutes
  • Only open topics, don’t try to close them. Have the “person who cares” become the note-take for who should get together afterwards to close the topic

The point with a Ha-level answer is to not pretend there is only one technique, but to show there are multiple paths, and to encourage the reader to experiment and practice with them.

3. Many coaches seem to have achieved the Ri level of agile and lean practices, but not many have achieved the ‘heart of agile’ as described in your talk at AWA. How would you see the transition to this level from RI and what steps might a coach take to achieve that?

A: It is worth stating that radical simplification of a complex topic is difficult and fraught with error. To take something as complex as agile development and select four words to make a good set of basics to focus on is not at all obvious. I would not expect many people to have accidentally selected the same essence for agile as I have. The Heart of Agile is my personal selection of which basics to focus on. I did see, once I published it, a number of agile experts say, “Oh, that’s it! Thank you for finding a good simplification of agile.” I’ve been testing it for over a year, in different situations and combinations, and it seems to hold.

To make the transition from Ri to Heart of Agile (Agile no kokoro), a practitioner, manager, coach, needs to go inside themself, and find the presence of these four verbs in all their coaching, to isolate them from any particular brand or methodology they are using, and to look for unnamed opportunities to increase collaboration, delivery, reflection, improvement outside the already named mechanisms.

My hope is that removing technique names from the essence will free people up to be more naturally themselves when collaborating, to look at the quality of their collaboration directly, separately from their codified behaviors; to discuss all the different ways and values of delivering (for information, for comfort, for revenue), and to amplify their retrospectives to get better ideas for improvement. I find when brainstorming with people about each of the verbs, that they come up with many more ways to improve than they had previously seen. And anyone can do that, not just coaches or managers.

4. Is there a way to quantify the cost (emotional and economical) of achieving the cultural transformation that agile is. I.e. going from the current organisational state to the wanted organisational state? And the purpose of the answer would be to be able to reason and compare the changes in production capability.

A: Not that I know of. I’m not a quant person, so I don’t fuss about these sorts of numbers. What I get impressed by is when a CEO or director says, “I would never go back.” That’s not a question of percentage points of improvement, that is “never go back,” from someone who has lived both sides.

5. What is the future for agile, and how do you see agile being applicable for teams beyond IT?

A: I am not a futurist, so I can’t speculate as to what will happen. What has already happened is so far beyond my speculation from 10 years ago, I can’t even imagine.

However, I can say something for agile outside of IT. For agile to make a jump into a new field requires two things:

• A recognized expert in that field must present it in the natural idiom of that field. Not an outsider, not me, not any of the manifesto authors, we are all too tech, but someone with the right reflexes, twitches, and recognition in the new field must be talking.
• That person must recreate all the stories we tell about agile as stories within that field, with a translation of our tech terms into language recognized by the people in that field.

That means, quite specifically, that none of we manifesto authors will lead the dissemination of agile into marketing or construction, but a marketing or construction person must find us, recognize him/herself in us, and recreate what we are advocating afresh, to their marketing or construction colleagues.

6. We know how you love answering questions through stories based on your experiences. In relation to getting back to the very heart of agile, which is your favourite story, and why?

A: I am always struck when I meet someone who says they have been doing something that has worked for years, and they are confused by all the Scrum rules they are told to follow, and in the discussion, it turns out they have always been super-focused on the quality of trust, of communication, of community, in their teams, totally naturally, just by their personality and view of the world. (Most often, but not always, they are women. Perhaps that’s not a surprise.) And when we examine their situation before and after Scrum got introduced, we see that communication and collaboration dropped after Scrum got introduced, because people get all into the rules of the rituals, and forget about the actual communicating, the actual trust-building moments, the actual collaboration.

This, to me, is always a vote for the Heart of Agile verbs, rather than a process-process, as Scrum has become.

7. What’s the one piece of advice you would offer to a CEO about to embark an a large scale agile transformation.

A: Obviously, I would say, focus on Collaborate, Deliver, Reflect, Improve. See for example 

The reason to focus on these four verbs is to open the mind as wide as possible to different avenues for improvement. My goal is an improved organization, not one that is agile-by-name. Improvement will come when collaboration improves, when delivery improves, when the quality of reflection and improvement initiatives themselves improve.

In addition, keeping the verbs generic should reduce some of the I’m-fed-up-with-Agile backlash. I hope. But let’s see.

8. Which readings would you suggest to someone experienced in lean/agile, that want to deepen their understanding of lean/agile theory and mindset?

A: The book Agile Software Development: The Cooperative Game, 2nd ed (by me), contains all the theory I had gained from 1991 through 2006, so 15 years worth of study, in as readable a manner as I could arrange. Crystal Clear: A Human-Powered Methodology for Small Teams is more readable, more actionable, with a recap of the theory.

For two more difficult articles, the interested reader should go through a paper I was invited to write in 2004: “The End of Software Engineering and the Start of Economic-Cooperative Gaming” and the most difficult, I’m afraid, a roll-up of everything I’ve learned about the theory of software development over the last 25 years: “Elements to a Theory of Software Development”

That last one is dense and difficult, but then again, it is a summary of 25 years of learning.

Your chance to learn with industry guru Alistair Cockburn

Test and challenge your existing agile skills and mindset on this fun and interactive 3 Day Advanced Agile Masterclass in London next month. 
Register now & get 15% off your booking.

This post first appeared here.