PROBABLY IT’S TIME TO SEND SOME SOFT SKILLS EMISSARIES TO THE PIONEERING LEAN-AGILE-SCRUM COMMUNITIES

Cartoon courtesy of Thomas Karlsson, <br>Agile Coach at Softhouse

Cartoon courtesy of Thomas Karlsson,
Agile Coach at Softhouse


If you yourself aren’t involved in big-time software development or don’t, say, have a serious client or close friend who is, you may not be aware of some of the latest organizing concepts in this highly influential technology sub-specialty.

I’m referring particularly to the kind of ideas that often travel under one (or all) of these identifiers: lean, agile or scrum.

You’ll get a far more nuanced introduction to these buzz words and the sacrosanct workplace practices they represent from people who closely track them. Sinan Si Alhir, who blogs here, is a worthy example. Consider this enthusiastic sentence he uses to introduce the agility model to his blog readers:

We live in a VUCA (volatility, uncertainty, complexity and ambiguity) world where we are challenged to be thriving on chaos in an age of discontinuity — where the past is plagued with incoherence & inconsistency, the present is plagued with chaos & ambiguity, and the future is plagued with unpredictability & uncertainty!

Alhir also has an excellent PowerPoint presentation I’d recommend to any newbie to the lean, agile, scrum scene. In it, he provides us such tidbits of context and history as these:

Lean has its roots in the Toyota “just in time” production system of the late 20th Century. The idea is to identify value and strive for perfection in producing it. Si Alhir recommends James Womack’s and Daniel Jones’ book, Lean Thinking, as good background reading.

Agile practices stem got their start in the design of high-performance fighter jets. Chet Richard’s book, Certain to Win, is a go-to source for details on agile approaches. Since these ideas are from the military’s neighborhood, it’s no surprise that they are usually described in slam-bang fashion: Observe, orient, decide, act.

Scrum refers to a way of designing the work. In Si Alhir’s words, it refers to “a simple team-based ‘inspect and adapt’ framework to organize work around ‘complex’ systems and products.” Its insider’s vocabulary is well stocked (and stoked!) with terms like ScrumMaster, Burndown Charts, Daily Scrum Meeting and Information Radiator.

I like the sound, the vitality and the no-nonsense character of all this because much of it closely tracks with the dolphin thinking qualities I’ve been advocating now for about a quarter-century.

For example, I’ve been telling folks that there is a kind of automatic problem-solving quality residing in our heads that, if we can activate it, will leave us reluctant to go to conventional workplace meetings any longer. Why? Arrogant as it sounds, in 95 meetings out of a 100, once you activate these thinking qualities, you will know a lot of that what needs to be done next not long after you walk in the door, if not before.

You might want to ask, “Why not go anyway and share your insights?”

Because the dolphin thinker quickly comes to realize that business meetings are mostly attended by three kinds of people: those who don’t want the problem solved, those who don’t want the problem solved on any terms but their terms and those who don’t want to hear any possible solution until they have had a chance to explain—and often argue strenuously—why they don’t think there can be one.

Dolphin thinkers would much prefer to invent new circumstances where old problems simply can’t find their way back in. Rather than attending meetings, they would much prefer to be busy instituting change.

This explains why dolphin thinkers have so often kept themselves in the background unnoticed, knowing that “Whereof we cannot speak, thereof we should remain silent”?

“You have read Wittgenstein, I see,” I can hear you saying, dryly.

Not really that much. I often find the enigmatic Viennese philosopher virtually unreadable. I think many individuals who have picked up a copy of his Tractatus Logico-Philosophicus will agree with me.

But I like his whereof/thereof quote. And I like his comment that his philosophy is intended to “show the fly the way out of the fly-bottle.”

I don’t yet know enough about the progress of the lean-agile-scrum movement in software development to know whether this is actually turning out to be a dolphin-thinking-like idea or not.

My suspicion is that the “push for speed” ambitions of this movement without concomitant attention to some of the so-called soft-skill needs of the workforces involved in the end often leads to the same old, same old.

If that is the case, then there is a set of ideas that travels under another four-letter buzzword that I heartily recommend be added to the mix.

Nevertheless, I get excited when I come across folks who are saying things like this: “Simplicity‒the art of maximizing the amount of work not done‒is essential.”

That’s from The Agility Manifesto. You can read all 12 of its principles here, and if you are involved in training, coaching, leading or seeking to influence teams responsible for producing complex outcomes in fast-changing environments, I’d really recommend it.

Comments‒‒
From Brian Branagan, bbranagan@yahoo.com:
Thanks, Dudley, for opening the conversation about the need for bringing “soft-skills” to those working with Agile/Lean/Scrum methods for delivering value to customers. I enjoyed reading about “The Agility Manifesto” since I’ve been introducing these practices to teams for over 10 years.

In addition to the books Sinan Si Alhir recommends on his site, I highly recommend that “emissaries” bring along the “Language of Business” skills you describe in your book, Evergreen: Playing a Continuous Comeback Business Game, and a knowledge of Clare W. Graves work you describe in LEAP! I also recommend Dr. Fred Kofman’s Conscious Business and Denning and Dunham’s The Innovator’s Way.

I’ve relied on these books as a resource to deal with the breakdowns I’ve encountered after introducing Scrum methods to teams.

The first breakdown was with the Daily Standup ritual where a team stands around a board with three columns: Work to be Done, Work in Process and Work Completed. On the board, there are Post-its describing tasks that take anywhere from one day to three days to complete that are moved from the first column to the third column over the course of a focused two-week period of work called a Sprint.

In a Daily Standup, each team member declares their progress. They commit to doing something by a certain date, they assess their progress for work they are doing or they say they have done something. If anyone needs help, this is the place to ask for it.

Sounds simple enough, right?

What I saw occur in the first few iterations were people who had difficulty in declaring commitments, making assessments or making requests as described in Evergreen. I realized that this is a core human skill that is probably not taught in computer science classes. I was able to provide some one-on-one coaching to team members so that they could move from needing to be seen as an Expert to becoming recognized for their ability to be a Learner.

The second breakdown I saw was between the Scrum team and the stakeholders of their work. It was not uncommon for a “Shark” stakeholder to demand the team take on an additional work item in mid-Sprint. Sometimes this could be handled by simply substituting it for a task of comparable size that had not yet been started. There were other times, however, when the stakeholder said that that was simply not possible.

This is where the “Language of Business” skills described in Evergreen and Dr. Kofman’s book can be useful so one can stay engaged with a frustrated person without being overwhelmed by their negativism. I’ve found Denning and Dunham’s book and their Eight Essential Practices for Innovation to be very helpful here, too.

Again, thank you for opening up new possibilities for bringing your ideas into new worlds of work and life.

Bookmark and Share