Nothing happening here. Check out Agile Anarchy—the tumblelog edition.

Scrum, enough already

Stubborn: Having or showing dogged determination not to change one’s attitude or position on something, esp. in spite of good arguments or reasons to do so. (dictionary.com)

Okay, I’m stubborn, or maybe I’m simply a slow learner, or an impractical idealist, but from any angle it’s becoming clear that it’s time to get real, and to recognize a sad, yet blatant truth. Scrum is no longer interesting. The potential of Scrum as a pathway to release and freedom has been irreparably damaged by the certification zealots and its main governing body, the Scrum Alliance where the ideal is effectively held to ransom by profiteers.

The more I engage in conversation about a framework and a set of principles that I find profound and inspiring, the more I realize that in calling it Scrum I repel more people than I attract. It isn’t the ideas that turn people away—not the values, the principles, or even my passion—it is the brand, and what it has come to mean in our community (and beyond), i.e. a coercive, prescriptive, inflexible process governed by hard-core fanatics resistant to change or improvement.

This may or may not be the truth. It doesn’t matter. It is perceived as the truth by a vast and growing body of intelligent practitioners. Scrum has become tainted by its association with certification — and now that it’s about to become encoded by the Scrum Alliance in some sort of ScrumBOK or Scrum Taxonomy document its fate as an artifact of old thinking is sealed. Such a document will become its tombstone.

But the refreshing news is that few outside of the inner Scrum certification circles actually give a damn today. It’s just not on most forward-thinking people’s radar any longer. The world has moved on.

I reckon it was was my trip to LSSC11 in Long Beach, that caused this jolt in my thinking, this awakening. The experience acted as a catalyst, fusing my conflicting perspectives into a cohesive whole. To my delight I spent my two days of (let’s be honest) conference-freeloading engaged with inspired and inspiring groups of people, seeking new ways of thinking about the world, exploring, laughing, leaping paradigms and manifestos, and not wasting time talking about whether Kanban is better than Scrum, or visa-versa — in fact hardly talking about Scrum, or Kanban, or Lean at all… or even systems or software. The conversations were about people, and collaboration, and organizational structures, and complexity, and brain function, and starfish, and exploration, and improvement, and love, and kindness, and compassion… and even supplication.

Formal conference talks have a place, but it is the foyer conversations that herald the future. Judging by the buzz at LSSC11 we are moving on from prescriptions and recipes to embracing new, unknown alchemic concoctions, eschewing the safety of control and coerciveness and risking the danger of release and chaos. There isn’t much of a place for brand names or methodology wars any longer. There are better ways to spend our time now, so rather than continuing to defend and rescue a corrupted brand name I think I’ll spend my time living my values, and engaging others through example.

Marriage, but

Marriage is a wonderful concept. It is a promise of love, togetherness, mutual nurturing and the creation of family. It exists in one form or another in all cultures, and it appeals to the majority of people in the world, each of us dreaming of a long-term mate, and the promise fulfilled.

And yet marriages fail. All the time. Why is this? Well, of course there is a myriad of reasons, but usually it comes down to the fact that the conditions—the rules if you like—for making marriage work are cast aside, or reformed to suit one or other of the individuals.  If we listen closely to the language of a particular marriage we may hear words to the effect of… “love is good and everything, but this honor thing doesn’t quite work for me”, “till death, hm, that’s an awfully long time”, “faithful really means just not telling”, “I see the value of the ‘in health’ thing, but this ‘in sickness’ part isn’t adding much to my personal happiness”, “can I rephrase that as ‘for richer or not quite so rich’? If you’re going to humiliate me by being poor you’re on your own”. And so on.

MarriageBut. It is the root cause of marriage failure: the inability or refusal to honor the contract. The contract is a very simple one, and there are many variations on the vows [ref], [ref], so we are not asked to say things we don’t believe in. We agree to live according to the framework, but so often when it starts to get difficult one or both partners start shifting the rules to suit themselves, undermining the foundation and ultimately causing the structure to fall apart. 

The pertinent question for this blog post is this: Does Marriage fail? I’d argue strongly that it does not. Marriage as a framework, as a promise is strong and robust. It has served humankind well for hundreds of centuries. There are tweaks and incremental improvements we can (in fact do) make, e.g. the removal of the words “to obey” from the woman’s script in many modern Christian ceremonies, but for the most part the framework has been strong for a long time.  

It is the instances of marriage that fail, the individual implementations. Few, after a failed marriage, would say that the concept itself is wrong. They may apportion blame to one another, or to outside forces (e.g. in-laws) but in the end they move on and often try a new implementation, learning from their previous experiences. 

Marriage doesn’t fail. Some marriages do. It is important to separate the model from the implementations. In this, and other aspects of our lives. If I build a house for myself using shoddy materials and poor techniques, is the concept of Home a bad one? When a government is run by disingenuous, dishonest individuals does it make the concept of Democracy a failure? I think most would agree that the failure is in the implementation rather than the idea.

Many are quick to knock the concept of self-organized business as a fad, or the Scrum framework as too rigid, and point to a few failed implementations to discredit the concepts. But in essence these concepts are good ones. They speak to the natural rhythms of our lives, and our very human need to collaborate and trust. Scrum, like marriage is a contract, rooted in sound values. Each is a promise of an improved quality of life. And yes, we’ll screw both up time after time. And still the ideas are strong.

The Youngest CSM

My seventeen-year-old son Ty recently participated in a two-day Certified ScrumMaster course. He is not a software developer, and has little interest in that craft. He is a high school student and a musician. Still, he enjoyed the training greatly and learned a lot. After he completed the course he —along with the other 15 participants— was awarded the CSM certificate. He is now more certified in Scrum than I am.

A few days after the course we were chatting about it, and after waxing lyrical about the trainer (Alan Cyment) Ty asked why I didn’t teach CSM any longer. I said it was a long story… and then went on to give a precis’d version, ending up with asking him if he now felt qualified to work as a ScrumMaster. Of course not, he replied, how ridiculous! Indeed.

No self-respecting developer or other professional really thinks the CSM has any true value beyond a certificate of attendance, I explained, it is the middle managers who write job descriptions, and the HR recruiters seeking “resources” that have made it so important.

Ty’s take on this was that Scrum trainers should offer a similar two-day course to these middle mangers and HR folk, to show them how foolish they are being. Nice idea. But who would show up? Managers are far too busy crafting detailed job descriptions, and recruiters too busy with making sure all the latest certification acronyms are entered in their filter systems.

Talking with Ty reminded me just how natural a way of working Scrum is. Ty is untainted by corporate America. He attends school, composes songs and plays in bands. This is just how I work naturally, he said (referring to his creative work), and expressed bafflement over the whole “waterfall” command-and-control thing that he had learned about. To him, it sounded like school.

For us old people who have been indoctrinated in Tayloresque and theory X management styles, who have had hierarchical, command-and-control, reward-and-punishment systems hammered into us for years, Scrum is no longer natural. So the teaching of Scrum is not a process of adding information, but rather removing it, stripping out all the nonsense we have accumulated so we can once again see the obvious simplicity of the ideas offered to us by the Scrum framework and principles. Self-organization, collaboration, trust, transparency, emergence… these are not new ideas, they are just forgotten ones.

Wouldn’t it be great if future generations didn’t have to go through that painful learning-just-to-unlearn process? I suggest that taking Scrum into schools will seed future generations with the right mindset for the new world of work which is emerging.

A growing number of organizations, such as World Blu, The Plexus Institute, Waking Up The Workplace, Heart of Business, TED, Holacracy1, The Agile Alliance, World Cafe and Open Space World (to name just a few) are guiding us towards a new future. This movement is too big to ignore, or write off as a fad.

Harnessing the way of working that kids and teenagers naturally practice could give the world of work just the tidal wave it needs to level the old mindset and prepare the ground for a new beginning.

Related post: Millennials and Scrum — Made for Each Other by Lyssa Adkins.

—
Note: the title of this blog makes an assumption. I don’t have access to the data to prove the claim, so it may or may not check out.

Scrum is not Project Management

Scrum, and the way of thinking that it attempts to socialize in the world of work, has nothing to do with project management. Anyone who is laboring under the misapprehension that Scrum is some form of “Agile Project Management” is seriously missing the point. There may be such a thing as “Agile Project Management”. I don’t know, and don’t really care. It is of no interest to me. My concern is with changing the way people think and act, not with force-fitting old ways of thinking into a new paradigm that cannot accomodate it. The result we are seeing is a half-baked compromise.

Organizations like PMI, Scrum Alliance, ICAgile and others who are trying to grab a slice of the Agile market are like parasites feeding off the souls of people who really care about change in the world. It is a tragic mess, made worse by those so-called Agilists who justify the behaviour, and even buy into it. Old habits die so very, very hard.

I am not interested in half-measures, or “corporate-approved Agile”. This strikes me as worse than useless. At least the previous command and control culture was honest. This fake-Agile is deeply disingenuous, pandering as it does to those in fear of real change.

I urge anyone who really cares about the future of business, and the health of human beings in the workplace to steer well clear of all these oblique, money-making, compliance-seeking efforts to tone down Agile and make it palatable to those driven to maintain the status quo. Seek something more noble. Please.

Don’t Have Meetings

Today, during a Scrum introduction workshop I came to a sudden realization that I didn’t want to use the word “meeting” when talking about Scrum. Meetings have such a bad rap in our industry, and rightly so. I recall hours-long, painful meetings where nothing moved forward, the louder people postured and argued, talked in circles and dug themselves in to ever-deepening trenches, while the quieter ones, stared at the table, or cowered from the conflict, wishing they could be back in their cubicle doing useful work.

Admittedly, Scrum has reduced this meeting overhead to a few key, timeboxed meetings but the legacy of “meeting culture” still hangs over us, heavily. “Scrum has too many meetings” is a common complaint… and then we discover daily meetings drag on for 40 minutes, retrospectives are unproductive, lack meaning or devolve into complaint sessions and planning meetings are controlled and directive, leaving team members sullen and brow- beaten.

It occurred to me in that moment that telling the workshop participants ”these Scrum meetings are essential” was likely to deflate them rather than excite them about this new way of working. Meeting culture has penetrated Scrum, as it must. Something so heavy and oppressive, so entrenched in our way of being will crush anything that tries to challenge its power. The Scrum Alliance introduced the term “ceremony” to replace meeting, but that’s almost as bad, and to some people even worse, carrying with it images of cults and cloaked figures preforming strange rituals. And using that term in the same sentence with “ScrumMaster”… forget it!

So I used the term conversation. Scrum has people, I said, and it has conversations. There are conversations to plan, conversations to align, and conversations to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection). Expressed this way I felt a lifting of interest, a lightening of the heart. I had essentially told this group of people “you never have to be in a meaningless meeting again”. And I believe that.

Let’s stop talking about meetings, and let’s stop having meetings. Nothing good ever came out of a business meeting. People in collaborative dialog though, now that’s exciting — that’s meaningful.

In Praise of Unpreparedness

It wasn’t intentional, but because I came into my Scrum training session yesterday with a half-baked idea for a game, the participants were able to experience first-hand the Scrum approach to working with customers (like me!) who don’t know what they want. From that realization came an understanding about the importance of collaborative dialog with customers. Through actually doing it the participants learned about the importance of requesting clarification on vague requirements, making offers, saying “yes, and”, self-organizing towards solutions, driving forward by hindsight, and emerging great solutions through a careful balance of action and reflection.

And I came to understand, once again, that I can be in disarray, and actually use that state to unearth wonderful learning moments. It is not the game we play that matters, not the well-planned exercise, the beautifully crafted set of slides, or the knock-out lecture. It is the response in real time to those things where the deeper value can be found. If I accept I have no knowledge of what will happen when I embark on a training unit, then I open a world of learning possibilities to participants (and to myself). On the other hand, if I have a defined outcome in mind, I close down all those other possibilities. I manipulate rather than guide.

This is something I have long been aware of, and trusted in, but my failure yesterday to effectively formulate a new game gave me a new depth of understanding of the value of this way of working. I inadvertently created an environment where the principle of emergent design became manifest. Yet while created by accident, it was subsequently fostered very deliberately. And a new interactive Scrum game was created.

In such moments the joy of Scrum training can be savored.

Beyond Estimation

Most Scrum teams these days are taught the estimation techniques described in Mike Cohn’s Agile Estimation book , namely the estimating of user stories (aka requests) in relative size using techniques such as planning poker, and the estimating of tasks in hours. I eschewed task estimates a few years ago, see Unearthing Impediments by Doing Less. More recently, perhaps over the past 2-3 years I have found less and less need for story estimation. I find the practice is time-consuming, creates unnecessary overhead, and adds very little to a team’s ability to make commitments, and meet them. On occasion it has caused irritation and distress in both team members and customers who simply do not see any value in it.

I am not against having a team experience distress, or breakdowns as a method of learning, but in the case of estimation I don’t find it worthwhile. There are better things to focus on, such as writing well-formed user stories, requests that have clear value and conditions of acceptance. The dialog around defining the conditions of acceptance tends to cause requests to become smaller. It is very hard to create and agree on a set of acceptance criteria for large or vague requests.

If velocity is important (and I’m not convinced it is) then it can be done through a count of completed requests. When requests are kept small they tend to be much of the same size. If they are not, it may indicate a lack of clarity both about what we are asking for (the PO) and what we are committing to (the team), so rather than slapping on a big 21, 34 or 55, it is better to spend a little more time, think a little differently and refractor the request down into a set of smaller requests. I always recommend to teams that they take on between 5-10 stories per sprint. Somehow this seems to work out no matter the domain or the length of sprint. Having smaller requests also aids the prioritization process as we learn what need not be done.

I have come to believe that estimation using any number system, whether it be ideal hours or relative points (which ultimately map to time) is compliance to an outmoded system, a way of appeasing old-school management who are unable, or perhaps more accurately unwilling to think beyond data points and (empty) promises.  There is still a mindset in the Agile world, as much as there ever was in the PMI world, that teams can somehow commit to both time and scope. Estimation, as it is commonly done perpetuates that myth, or at best does not challenge it.

A team should commit on gut feel more than on data points. We are feeling people as much as we are thinking people, ironically the former may be more important when working in the knowledge industry. At the end of each planning meeting the team members should ask the question, do we honestly believe we can meet the commitment we just made? If the answer is not a resounding yes, then reduce the commitment until it is. And no, this does not result in teams under-delivering. I have never once experienced that phenomenon.

Moving away from the obsession with numbers allows us to begin to trust our instincts, to draw on our individual real-world experiences and our “team intelligence” to give truthful responses to the “when will it all be done” question.
If you find your team is bound by Estimation Think, I challenge you to spend a few sprints not estimating, but spending the time instead to make the stories in your backlog smaller, each having a clear value statement, and reasonable conditions of acceptance. You may be surprised by what happens.

The Retrospective is Now

In her 1958 book “The Art of Making Dances” the dancer and choreographer Doris Humphrey offered the advice: “Never leave the ending until the end”. Since first hearing that advice in the late 1970′s I have found it to be appropriate in all creative endeavors I have undertaken. It essentially asks that we have a sense of the whole before filling in the detail. It is a very Agile-compatible concept. If she had been addressing a business audience Ms Humphrey may have recommended that we know why we are doing something before we undertake to do it. In other words, what value are we seeking… what story are we telling?

Traditional software development tended to leave the ending to the end, which is why we often joke about teams being 90% done 90% of the time, and why the shit inevitably hits the fan when we try to integrate all the disparate pieces.

Taking Doris Humphrey’s original insight, we can apply it to a different aspect of software development, an Agile aspect in fact. The retrospective. Reframed the statement might read: never leave the retrospecting until the retrospective.

In my previous post I decried the so-called Prime Directive, claiming it was condescending and superficial, and its use created the wrong kind of environment for real change to occur. The introduction of the Prime Directive seems to assume no work has been done on the journey to the retrospective, that all feedback, criticism, concern, all differences and disputes are bottled up and saved for a single meeting at the end of a sprint. If that is the way a team is taught to work, then I can see the need for such a directive. We could parallel this with a traditional approach to testing, where QA specialists try to test quality into a piece of software after it has been built.

If a team is given the opportunity to reflect each day, is guided towards a collaborative and trusting way of being, learns to confront the tough moments with courage and respect then the quality of interaction and collaboration is woven in to the fabric of the team, not patched on at some later date. With such teams the retrospective requires no directives, admonishments or rules of conduct.

In fact, without the necessity to take the lid off Pandora’s Box every two or three weeks the retrospective becomes something much more interesting and powerful. It becomes a moment of stillness and reflection, a time to breathe out, to say thank you. A time to be, and not do. Such a retrospective results in the team members feeling closer to one another as human beings. It is a deepening of the tribal spirit, the common consciousness, that intangible element inherent in all groups striving for a common purpose.

Seek small adjustments as and when needed, and you won’t have to worry about the big changes. They will take care of themselves. And maybe you will experience a shifting of self, from which place the real organizational change will emerge.

The Prime Defective

I decided I am not done with this blog after all, and will continue it in parallel with my Business Craftsmanship blog. Life is not a single channel, but rather a criss-crossing of streams.

Recently, and in a few different contexts I have been alerted to the Retrospective Prime Directive, and just as when I first came across it a few years ago I find my response the same. I am irked. So I decided to think about why.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

I find this to be vapid nonsense, and actually quite insulting to one’s fellow travelers. In the pursuit of some kind of new-age political correctness this statement manages to be both patronizing and phony, and at the same time contain so many “given that” clauses as to be utterly meaningless. If you redefine “best” in any way you choose of course I always do my best. But taking it to its logical extreme, if I abuse someone, am I doing my best “given that I was angry at the time”… and if I kill someone, am I doing my best “given that I needed [money|revenge|drugs] at the time”? Clearly the term “best” becomes meaningless.

But it isn’t the absurdity of the statement that irks me, it is more the smug condescension. When I reflect I want to be able to acknowledge that I didn’t do my best. I want to acknowledge that I acted badly sometimes, that I made mistakes because I was caught up in my own ego, that I didn’t listen, that I rushed in like a fool, that I may have hurt people, or done poor work. If you metaphorically pat me on the head and tell me, “there, there, my dear, you did your best”, I’ll want to metaphorically punch you in the face.

Let’s respect people a little more than this. I’d like to offer an alternative approach to beginning a retrospective: It is not a directive though, not a statement to publicly proclaim, it is simply a suggestion, something to quietly consider before dialog begins.

We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

We don’t always do our best. So let’s get real.