shinsato.com

Jim McCarthy, author of the Dynamics of Software Development and co-author with his wife Michele of Software For Your Head, showed up at the Agile Open Northwest conference last week with a protective plastic layer he unfolded on one of the lunch tables. He sat there with blank canvases, paint, and a menu of conversations – and invited people to dabble paint along with him. This post is about the “Culture Hacking” menu item – for which Jim also held a late night 8pm session in the Seattle Center with about 15 other attendees.

If you’re not familiar with Jim and Michele’s work, the best introduction is probably their entertaining “McCarthy Show“, a podcast with years of recordings. And there are more concise writings available there as well, though my experience is the only way to really get the power of their work is to try a bootcamp and feel the power of a “booted” team. But some of this power is evident in Jim’s speech attached to this post.

Jim delivered a rousing and mobilizing talk calling forth those who work with software, and especially those who are reinventing the way that we do work through forward leading organizational and management tools like Scrum, Kanban, and “Agile” and “Lean” ideas in general – to bring on a new Golden Era like Classical Greece, circa 500 B.C. He believes we can do this by programming culture with the same hacker ethos that helped them reclaim the hardware and access to it from mainframe elites of the 60′s and 70′s, and which was moved forward by the Open Source movement.

Jim’s claim is that we’re only at the “pong” level of cultural hacks with tools like Scrum, Kanban, eXtreme Programming, and the other tools of the Agile Software movement. In a short time, we’ll start to see cultural programmed applications that are orders of magnitude from even the leading edge of what teams are doing right now.

Most of you are probably familiar with the adage, “Physician, Heal Thyself!” The miracle of internet search revealed to me that this actually came from the New Testament as a quote of Jesus from an even older proverb. The meaning might seem to be transparent, which is that healers should use their own knowledge on themselves before attempting to use it on others.

As a student of coaching, this simple meaning was what came up for me on a phone call with a master coach, Michael Spayd. Michael along with Lyssa Adkins, author of the book Coaching Agile Teams, are working together to advance the practice of coaching in the world of agile software development. When most people think of the term “coach”, they probably see someone on a football field or basketball court on the sidelines giving guidance and helping the team perform while not actually playing the game him (or her) self.

But the term “coaching” as intended in this article comes out of the increasingly relevant field of professional and life coaching. The International Coaching Federation defines coaching as “partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential.” There are executive coaches, success coaches, and many other “niches”.

Alright, so I just completed Coaching Fundamentals, the first class of the Coaches Training Institute (CTI), which is one of the leading coaching training and certification organizations. It was inspiring being with such a diverse group of people who wanted to help others – from technologists to teachers to managers to real estate brokers. What strikes me most about coaching as taught by CTI is “nobody gets to be wrong”, which means that the relationship between coach and client works best when you go outside of evaluation. In other words, good coaching is not about handing out grades. We’re not in school any more. Coaching especially isn’t about making judgements. And this can be quite tricky. I wonder if a good researcher has measured how much of most of our self-talk is evaluating and judging whether we’re getting it “right”? And what’s funny, is that judging and evaluating itself isn’t ‘wrong’ either.

So when I thought “Coach, Coach Thyself!”, I think mostly for me that was about doing what the manual of coaching as taught by CTI teaches. Here’s a quote from the beginning of Co-Active Coaching: “Naturally Creative, Resourceful, and Whole – The primary building block for all co-active coaching is this: Clients have the answers or they can find the answers. From the co-active coach’s point of view, nothing is wrong or broken, and there is no need to fix the client. The coach does not deliver answers; the coach asks questions and invites discovery.”

Wow, that’s a refreshing way to look at ourselves too. Imagine if we stopped being the judge and stern schoolmaster to ourselves, and instead we were coaches that were curious, asked useful questions that encouraged discovery rather than self-judgement.

I wonder how I might start asking myself better questions and be a better coach to myself? And maybe how can I put away that ugly free clip art whistle too?

Some have said that the mind is like a parachute. It has to be open in order to function. Contrasting that, the street wisdom I’ve heard is that if you keep your mind open, people will throw their garbage in it. Certainly openness is a virtue, and in what way and what context?

There have been a number of articles in my blog about Agile Software Development, and in this entry we’ll take a look at the project management framework called OpenAgile, which might help us also understand the meaning and value of “open”.

Before we talk about OpenAgile we need to set the stage. If you’ve been involved to any depth in any human affair, there’s going to be some dirty laundry. It doesn’t matter if it’s a family, or a business, or a charity. Agile Software Development was intended to improve the bureaucratic and oppressive management structures in place in large corporate software development teams. I’m deeply grateful for the changes that this movement has made in my profession as a software developer even if there is still a long way yet to go. The most successful system under the “Agile” transformation umbrella has been by far, Scrum. Now as exciting and juicy as conflict and controversy can be, it can also be tawdry. So rather than digging into the trash for trash’s sake, I’ll only reflect some of what I know to help understand perhaps at least some of my interest in the OpenAgile framework.

Although Scrum appears to have roots that trace back to Japan in the 1980′s, most people credit Scrum for software development to Ken Schwaber, founder of both the Scrum Alliance and the Agile Alliance. Ken Schwaber’s book, Agile Software Development with Scrum, co-authored with Mike Beedle, is the standard reference (although many other books on Scrum have been written.) In 2010, my company SAP had Ken Schwaber speak to its employees and Ken personally claimed the “blame” for Scrum. But in 2009, the board of the very Scrum Alliance Ken had founded unanimously asked him to resign. It is quite interesting to read Ken’s account of his “resignation”, and his reasons for founding yet another organization. Another more recent resignation from the Scrum Alliance came from its Creative Director, Tobias Meyer.

Both Tobias’s and Ken’s posts about their resignations speak to a conflict of vision contrasting mission against money. As a member myself of the Scrum Alliance, losing these two visionaries is a clear loss to the organization, and it raises many questions. And although it may be too soon to tell whether OpenAgile answers at least some of those questions, I’m very grateful that they’re trying to do so and that the appearance of the OpenAgile Institute on the scene will at the very least contribute to the conversation about these questions.

According to OpenAgile.com, the approach evolved out of Mishkin Berteig‘s work as an Agile software development consultant. It was also influenced by his father, Garry Mishkin’s teaching model, called the “Learning Circle”. Mishkin wanted to share this method for any type of work, and he wanted to share it in a collaborative way. He specifically wanted it to be like an open-source software project, thus he named it OpenAgile.

Having read the OpenAgile “Readiness Primer”, and having passed the “Readiness Test”, there is so much to love in OpenAgile. It simplifies much of the structure of iterative development while delineating in more detail many of the virtues required to make a team successful at getting work done collaboratively. I’m eager to learn more, yet this article wrestles with that sticky word, “Open”. How is OpenAgile Open? What does it mean to be Open?

The open-source movement attempted to free software developers from getting stopped by the barbed wire of patent law and copyright intellectual property claims by licensing the “source” code for software in a way that would allow others to copy and alter the “secret sauce” inside the software as long as they passed on the same open source license to all their users. This model has become extremely successful, and much of the worlds computers run this way. It engenders active user and developer communities who write code, find problems, fix problems, and give their fixes back to the community as a whole – usually without even getting paid for all their contributions.

On the face of it, OpenAgile is not “Open Source” in the common way of understanding it. The license on their website allows for people to copy and distribute the content, but not to alter or derive other works from it. In other words, if you see an improvement you might want to make to OpenAgile – you would be breaking the law to do so without getting permission from the OpenAgile Institute. I suspect that within the OpenAgile community, there is much more openness to collaboration. But this openness is not legally granted to the general public.

Before going any further, let’s take a pause and look deeper into openness. When I was going to college, I recall a Woody Allen movie in which nine year old Alvy Singer stops doing his homework because the universe is expanding, which to him means that everything is going to break apart and so there’s no point to it all. In college there was also for me a lot of talk about entropy and the laws of thermodynamics, which basically says that a system tends towards maximum disorder. Basically, everything eventually falls apart. It seemed a dismal but fundamental law of the universe. But after college I came across the work of Ilya Prigogene which really opened my mind (pun intended). It turns out that, yes, systems tend to fall apart – if they are closed. But all living systems are in fact open systems. They receive inputs in the form of sunlight, air, water, food, and they release what they don’t need. Open systems can in fact become more complex and develop higher and higher levels of order. They can evolve.

Perhaps this is why democracies have been much more vibrant and productive than closed societies, and why collaborative processes like Scrum and OpenAgile work. It certainly plays a part in the success of Open Space Technology about which I’ve written many times such as here and here and here. In an Open Space Technology style meeting or conference, the agenda is fully open to every attendee to talk about whatever they want to talk about. And every attendee is also free to come and go as they please. You can talk about whatever you want to, and you are given a chance to invite all the attendees to come to your session. This kind of openness enables the system to organize itself. It enables it to evolve.

In fact I only know about OpenAgile because of Open Space Technology (OST). It was at the amazing OST event, Scrum Beyond Software, that I first heard about OpenAgile. And then at the OST event, AgileOpen NorCal 2010 in San Francisco last October, I attended a presentation that David Parker gave about it. David is the current Executive Director of the OpenAgile Institute.

If it seems I’m being critical of OpenAgile, perhaps it is because I’m both disappointed by it and excited by it at the same time. I’d been fortunate enough to spend more time with David Parker at Lyssa Adkin’s most excellent Coaching Agile Teams class last November, and his enthusiasm about OpenAgile is infectious. The topics that OpenAgile covers, the virtues its extols, and even the books it recommends are excellent.

I hope that OpenAgile can grow more and more into the “open” that its name invokes. I asked David some of these questions at his session in San Francisco last year. How will the OpenAgile framework evolve? Will they give permission for derivative works to be generated? If not, how will the framework be open to submitted contributions? And how will the board of directors be constituted in the future? Will the membership be able to vote for the board members? Interestingly, the Agile Alliance gives members the opportunity to vote for board members. But the Scrum Alliance does not. This fact does not make me comfortable about the Scrum Alliance.

And here is one last question about the meaning and value of “open”. What place do certifications have in a dynamic open system? The Agile Alliance has made a specific policy not to pursue certifications. Harrison Owen did the same for Open Space Technology. Yet the presence of certifications helped make Scrum extremely popular by helping to spawn an industry of Certified Scrum Trainers. Isn’t it interesting that the financial success of Scrum certifications also seems to have led to the ejection of some of the foundational and creative forces behind Scrum such as Ken Schwaber and Tobias Meyer? Is there a way to have both certifications as well as openness?

Maybe there is no answer yet to these questions. And maybe, that’s also a part of openness – not always knowing the answer.

A few weeks ago I had a problem. I had attended a computer conference, Agile 2010, in Orlando this past August which also meant I needed to do a presentation for my colleagues about what I learned. This was a source of stress, and I thought I’d try an experiment. What if I let the presentation organize itself?

Agile 2010 Conference Hotel in Orlando

Before I get into the way I let the presentation do the work, you need to know a little about the topic, “Agile Software”. The term was born almost 10 years ago by some amazing software practitioners who wanted something more lightweight than the heavy, painful, and bureaucratic methods that were dominant at the time. The term “lightweight” didn’t really evoke a lot of confidence, so they picked the term “agile”. They did this at a resort in Utah between ski runs where they also wrote and signed the Agile Software Manifesto. It’s picked up a lot of steam since the early days when it was considered heresy, a fad, or even a cult. These days, it’s most definitely well into the Early Majority part of the diffusion of innovation curve, and it seems clear that it will soon be the dominant way humans make software.

Although this might seem to be something purely for the techies, geeks, and their bosses – the values and philosophy behind agile software development methods extend well beyond software. In fact, I got the idea for how to organize my presentation from a conference convened by the Scrum Alliance in Chandler, Arizona called Scrum Beyond Software. What is Scrum? One of the main techniques in the agile toolkit is called “Scrum”. It was stolen from the sport rugby, but the general idea behind scrum is that you let the team organize itself around the work that it is tasked to do. The boss might tell the team what it needs to make for the customer, but the team (not the boss) decides how to do it. For the team, the key phrase is “organize itself”, or self-organizing.

Without diving deep into the term self-organizing, let’s say it contrasts with the old purely hierarchical “command and control” style of management. So what does that have to do with getting out of a lot of preparation work for my presentation?

At Scrum Beyond Software, an organizational guru, Jim Benson, spoke about a new tool in the agile toolkit, called Kanban. Kanban is from Lean Manufacturing. If you haven’t heard about Lean – it’s the way that Toyota beat the pants off of most American automakers. Taiichi Ohno found that Toyota after WWII had few customers for the cars they were making. In an effort to reduce waste, they only built cars that customers were ready to buy. It’s a bit more than that – but one of the things that has been adopted from all the Lean techniques into the Software world is called Kanban. It just means “sign” or “visual card” in Japanese – and the basic idea is pretty simple.

With Kanban, you look at all the steps in your process, and draw those steps as columns on a wall. Then you use a card, or a post-it, to represent all the production parts (or to-do items). All the inventory moves from left to right. When a card moves into the last column on the right, it means the piece of work is complete. Jim Benson explained that the most important idea in Kanban is to get a picture of the work you are doing.

Now we’re ready to talk about how I let my presentation organize itself. Jim Benson started the Lean Coffee Seattle discussion group in a coffee shop and he spoke about how he runs the group at the Scrum Beyond Software event. Jim starts each one of these sessions by gathering from the participants all the topics they want to talk about and put the topics on stickies which gather up in the left most column of a large three column table chart. That column he labels “To Be Discussed”. They quickly vote on the topics, and they proceed from the topics with the most votes to those with the least. When they discuss a topic, Jim moves it to the middle “Discussing” column. And when they finish, he moves it to the right “Discussed” column. This helps everyone see what they have coming up, what they’re doing, and what they’ve finished.

So rather than generate a large deck of Powerpoint slides to help people get in a little nap after lunch while I droned on reading my slides – I went to an office supply store, bought some huge 4-6 inch post-its, and put all my topics on the post-its in large letters. I posted those on a large whiteboard in the conference room in a three column table, just like Jim Benson’s Lean Coffee Seattle. Everyone voted, including folks online, by letting everyone vote for three topics. We tallied up the score, which gave an easy ranking order. When I started talking about something, I moved the post-it to the middle “discussing” column, and when we finished, I moved it to the “Done” column.

I guess the presentation didn’t exactly write itself, but rather than make it all about me talking at my audience, I also generated a few questions on each of the topics so that I could engage the audience, and I also provided a Wiki page of links for each of the topics so that the audience could follow up after the talk.

The end result – we had a lot of very engaged people during the talk. I received a number of compliments afterwards. And I didn’t have to stay up until the wee hours the night before creating my slides, so I was a lot more relaxed and a lot less tired and burned out after the presentation.