Monday, June 24, 2013

The Truth About Agile Management, And How It Can Help You

The truth about agile management is that there's too little of it. So little in fact, that there are those who believe it does not exist. Or worse, that it should not exist.

Many companies are switching to an agile approach. As a result, wave upon wave of agile transformations strike at the heart of classic reductionism. Some are absorbed, others just dissipated or reflected.

When an organization absorbs agile, it truly groks the concept of continuous improvement. Of striving for perfection in order to find ways to improve ever more. For these companies, the question is never “how agile are we?” They ask themselves “what's next?” They structure and restructure themselves accordingly. Depending on the experiment at hand, they adopt a set of practices to maximize the chance of a positive outcome. Sometimes this requires less management, sometimes more.

Examples of truly agile organizations are Semco, Google and Toyota. They differ widely in their specific approach to management, ranging from practically non-existent to incredibly pervasive. But they have one thing in common. All three companies unapologetically strive for perfection in everything they do, believing firmly that the people that work for them are crucial to their success.

Most organizations though, don't absorb agile, but rather dissipate it. They start doing agile, in stead of becoming it. This is where Scrum-but rules supreme. There's always a reason to tweak your process. Sometimes it's even a good one. There's never a good reason to set your process in stone though. And that's what happens in most organizations that adopt agile by dissipation. They adopt the practices, not the philosophy. And it's the philosophy that leads to the practices, not the other way around.

Some organizations even reflect, or rather deflect, agile. Sometimes, they point out the fact that in their opinion there's little scientific evidence supporting the contention that agile works better than the alternatives. I've fallen into that trap many times. I've sent scores of scientific reports supporting small, multidisciplinary teams, no multitasking, whole-team estimation and planning, and iterative development to nay-sayers. All to no avail. It's not about the evidence. It's about belief. When key executives don't believe agile can work for the organization, it won't.

In my experience, for an organization to effectively leverage agile, executive support is essential.

For Semco to become the communalist company it is today, it took a lot of effort from the Chief Executive, Ricardo Semler, to make it so. To grow Google into the internet behemoth it is today, its founders hired an experienced manager to guide the company. Similarly, to become the epitome of continuous improvement it is today, Toyota invested heavily in more effective management practices and continues to do so.

Like it or not, we need management. And we need management to be able to absorb agile in stead of dissipating or deflecting it. To do so, managers need to embrace complexity and non-linear thinking.

Organizations are essentially collections of structures and strategies. They are dynamic networks of interactions that tend to self-organize or mutate based on events. As such, they can be categorized as complex adaptive systems. To understand them, one must be able to think in a non-linear fashion, because in these kind of systems cause and effect are not self-evident, nor are results inherently repeatable. In other words, in most organizations one could do exactly the same thing twice, and get a different result. For old-school managers, this is frustrating. They try to change this by willing the organization to be not a complex system, but an ordered one. For agile managers, this is obvious. They work with the organization as a complex system, probing, sensing, and responding their way to success.

In order for management to effectively surf the waves of agile transformation, managers will have to become more agile themselves.

To become more agile themselves, managers must bridge the chasm of cognitive dissonance between classic reductionism and modern holism in management thinking. When hierarchical managers embrace complexity and non-linear thinking, they effectively become agile managers.

Thursday, June 13, 2013

Constructing Your Parachute On The Way Down, Overcoming Organizational Gravity For Smarties

Jumping out of a perfectly good airplane, while in flight, without a parachute is generally not recommended. Strangely, it's exactly what happens in a lot of corporate lean/agile transformations. People jump enthusiastically, enjoying the rush of sudden speed and the exhilaration of getting things done as a team, only to discover organizational gravity when they hit rock bottom.

If only we knew how to fly. In his acclaimed survival manual "The Hitchhiker's Guide To The Galaxy," Douglas Adams points out that there is an art, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss.

To be able to do that, you need power. And for that, you need to know a little bit about how to get it. You need to know about politics.

The political economy of lean transformations

Talking about the political economy of lean/agile transformations always brings a smile to my face. As a political economist turned computer programmer, turned delivery manager, turned project manager, and ultimately turned management consultant, I can talk for hours about this and not get bored.

Don't worry though, I'll give you the short summary. The very short summary in fact: All politics is a struggle for power. The political economy of lean/agile transformations then, looks at the effects of the redistribution of power in an organization.

Now, there's something special about power. To speak with Rosabeth Moss Kanter: "Power is a dirty word. It is easier to talk about money and much easier to talk about sex than it is to talk about power. People who have it deny it; People who want it do not want to appear to hunger for it; And people who engage in its machinations do so secretly."

Let's open up about power for a bit. And while we're at it, let's lighten up about power as well.

And let's begin with the end in mind: To learn what you need to know about power to become a more effective change agent, you don't have to read Machiavelli. You just have to read this book: "Power, Why Some People Have It - And Others Don't," by Jeffrey Pfeffer. In that book, the Stanford Professor of Organizational Behavior provides ten tips to help you wield power like a Jedi with a light saber:

  • Mete out resources.
  • Shape behavior through rewards and punishments.
  • Advance on multiple fronts.
  • Make the first move.
  • Co-opt antagonists.
  • Remove rivals–nicely, if possible.
  • Don’t draw unnecessary fire.
  • Use the personal touch.
  • Make important relationships work–no matter what.
  • Make the vision compelling.

Why should you learn about power? You should learn about power for three reasons:

  • First, power is a tool. A sharpened saw in stead of a dull one. By knowing about power, you can help organizations change faster, with less risk of organizational gravity wreaking havoc on your hard work. All tools can be used for evil as well as good. It’s the same with power. Most of us that “don’t like to play games” are just afraid we’ll lose. That’s not principled. That’s chickening out. Wielding power purposefully allows you to be more effective as a change agent. Don't fight the power, grab it!
  • The second reason you should learn about power is that your opponents have learnt how to wield it to create and protect the status quo. Rest assured that as you enter an organization, it will be structured in such as way as to conserve the status quo. It’s a natural state for organizations. Well, sort of. In reality, all systems are in a state of continuous flux. Which is why all the politicking occurs. It is needed to maintain the status quo. It’s also needed to topple it.
  • The third reason you should learn about power is because of what happens to power in a successful corporate lean/agile transformation. Transforming organizations from a traditional to an lean/agile structure entails a democratization of power in the organization. From management to teams, from IT to business, from top to bottom. Power gets redistributed from the elite to the masses. It's a radical democratization of decision making power. Such redistributions are generally met with a combination of enthousiasm and resistance. Both are understandable.

But there is another reason companies are remarkably resistant to change. This has to do with organizational gravity.

The concept of organizational gravity

The concept of organizational gravity comes from Mike Cohn. In his book “Succeeding With Agile,” Cohn describes the tendency of an organization to slowly, but surely, veer back to it's original state. Old habits die hard.

Organizations are structured to maintain the status quo. To escape that, you have to exert a lot of power. The larger the organization, the more power you'll have to exert. If you don't exert enough power, whatever you launched will either come crashing down or at best achieve orbit.

Some real life examples

Let's talk about some real life examples for a minute.

Way back when I was still a Project Manager struggling to convince management that an agile way of working would yield better results, I got called into the office of the head of Project Management. He showed me a letter from one of our most important clients. The letter said we would loose the contract if we did not improve within three months. "That's your assignment," the head of Project Management told me, "do whatever it takes to make it right so we don't loose the client." And I did. What it took, was some remedial team building and the introduction of an agile way of working. Within six months, the client sent us another letter. This time, it was a signed reference for marketing purposes. A dramatic reversal of customer satisfaction! All thanks to adopting an agile way of working. They kept improving on that way of working after I left and today have a rock solid reputation for delivering high quality software to millions of users. This then, is an example of an organization truly overcoming organizational gravity.

More recently, I consulted with a company that wanted to deliver faster, more relevant software to production with higher quality at lower cost. They'd done a lean transformation already, and asked us to do an agile one as well. So we did. And it was a success! We helped the client create multiple agile teams simultaneously working on the same technology stack and worked with management to introduce a governance structure feeding those teams with a single corporate backlog. And then, the financial crisis hit home. The company had to cut costs fast. So they did the now obvious thing: They asked their agile teams for help. And the teams told management to fire half of them. So they did! How about that? You ask the turkey what to have for dinner for Christmas and his advice is to have turkey! That was the level of understanding the teams had gained from adopting an agile way of working. But, there's a sad end to this story. The shift from continuous improvement to cost-cutting, that is from Eastern lean to Western lean, destroyed employee loyalty to the company. The first to go off to greener pastures were the managers and team members instrumental in the initial change. Then, organizational gravity hit hard. Last I heard, the teams are being told what to do by management and have stopped thinking for themselves. Apparently, overcoming organizational gravity is not enough, you have to keep at it to avoid falling back down.

Overcoming organizational gravity

So, how do you overcome organizational gravity? And how can you make sure you keep at it to avoid falling back down?

Speed is essential. The faster you go, the faster you'll show results. The more results you show, the easier it is to maintain momentum and push for a real and lasting change. Also, speed sharpens your focus and facilitates flow. It hightens your senses and prevents you from cruising along without paying close attention to what you're doing. Just like driving a supercar on a racetrack.

Trouble is, you're not actually on a racetrack in a corporate lean/agile transformation. For starters, there usually a lot more cars on the road. And they're not all supercars. They drive at different speeds. Worse, they follow different rules. Worse still, they might not be going in the same direction.

So a corporate lean/agile transformation is more like driving a supercar through heavy cross-town traffic. If you want to do that at speed, it's hard to keep going without accidents. It's impossible to do that without breaking the rules.

Breaking the rules is essential. Or rather, using and bending the rules so they work in your favor. To cut through cross-town traffic in a supercar at speed, all you need is flashing lights, a siren, and a badge. In a corporate setting, that's a sense of urgency, vocal executive support, and power. However, if you're using and bending the rules in your favor, you'd better have a good reason and a great sense of direction. If not, you'll lose popular support really quickly.

Navigation is essential. If you don't know where you're going, any road'll take you there. So you have to know where you're going. Or rather, where you currently want to go. And then get everyone to go along. A great and proven way to do just that on all levels in a corporate setting is applying Toyota Kata:

  • What is the target condition?
  • What is the actual condition?
  • What obstacles are preventing you from reaching the target condition? Which one are you addressing now?
  • What's your next step?
  • When can we go and see what we have learned from taking the next step?

What we call lean/agile today, resulted in large part from answering those five questions consistently over time. As Mike Rother points out in his book "Toyota Kata," the roots of Toyota's success lie not in its organizational structures, but in developing capability and habits in its people. The competitive advantage of an organization lies not so much in the solutions themselves, but in the ability to understand conditions and create fitting smart solutions.

This points to an important, and in my opinion sorely missed, addition to the Agile Manifesto:

Experimentation over implementation.

Do something. See if it works. If it does, do more of that. If it doesn't, do something else. As opposed to think of something. Talk about it. Talk about it some more. Then talk about something else.

If you don't go fast, break the rules, and navigate like a pro, you're likely to go SPLAT! Avoiding a Surprisingly Painful Lean/Agile Transformation (SPLAT), is hard work.

It's hard work to keep up the pace. In a truly lean/agile organization, you're not just sprinting, you're doing back-to-back sprints without stopping. It's more like a marathon. Actually it's more like an ultra. To be able to do that, you must want it badly. And you must train. A lot.

It's hard to break the rules. Sometimes, this may get you fired. Like in the story Brian Marick likes to tell about a certain Scrum Master:

  • An agile team was made to work in cubicles, like the rest of the company.
  • Agile methods aside, cubicles are the "single worst arrangement of humans and objects in space for the purpose of developing software."
  • The team proposed changing their workspace to an open one.
  • Furniture Police turned them down.
  • In response, the Scrum Master went to the office over the weekend. She disassembled the cubicles and changed the office layout to an open one. On Monday, she declared to the Furniture Police that "If the cubicles come back, you will have to fire me."
  • They gave in.

But they could have just as well taken her up on her offer and fired her.

Hard work, hard work, hard work. Are there really no shortcuts? Well, no, not really. But you can speed things up a bit. Quite a bit in fact. Let's have a look at some of these "wormholes."

Wormholes to the rescue

A wormhole, or Einstein-Rosen bridge, is a shortcut through spacetime, much like a tunnel with two ends each in separate points in spacetime.

Start your lean/agile transformation small, but make sure to select a really important project. Preferably one with lots of risk and high pressure. This will allow you to start fracking the organization releasing the hidden energy reserves encased within.

Propose a ship-it day to show everyone the power of self-organization. Ship-it days are a fun way to foster creativity, allow people to scratch itches and get radical. They're also a wake-up call to management showing them what happens if they stop holding people back.

No one in their right minds should be against the disciplined application of common sense. And that's exactly what lean/agile is. In other words: Just do it. So if you can't get anyone to approve your lean/agile transformation effort, remember it's more blessed to ask forgiveness than permission. Get going, kickstart a never-ending cycle of continuous improvement, and merrily deal with whatever impediments you encounter to getting things done. Results don't lie!

So, now for constructing your parachute on they way down to overcome organizational gravity. You jump in without a parachute. How do you avoid hitting rock bottom? I have seven tips for you to help you do that.

7 powertips for smarties

  1. Be honest with yourself. See things as they are, not as you want them to be. Acknowledge your feelings, then use the scientific method to check their validity.
  2. Use social network analysis to map the distribution of power in an organization. Visualizing the flow of power makes it easy to tap into it.
  3. Use heat maps to identify the points of maximum leverage in an organization. Visualizing the distribution of power makes it easy to know where to start drilling for oil.
  4. Create a power matrix to determine who to influence.
  5. Show genuine interest in everyone you meet. You never know where they'll end up later. Make eye contact, let them talk first, ask open-ended questions, listen.
  6. Tap into the awesome power of the secretary or personal assistant. Get to know them. Treat them as you would their bosses.
  7. If all else fails: Run!

Summary

Do your cause and yourself a favor, and learn about power. Be mindful of organizational gravity and use any means possible to overcome it, be it the smart use of power, plain-old hard work, or a shortcut. If you can't beat them, or join 'em and then beat them from within, run! Apply for a job at Semco, Google, or Toyota, to name just a few truly lean companies. Or start your own. Don't settle for less! You deserve to work at an awesome company!

Wednesday, April 10, 2013

Toyota Kata

Toyota Kata by Mike RotherTwo days ago, I read the book Toyota Kata by Mike Rother. Like most management books, the central message is hammered home by repetition. Some people, like me, may find that a bit annoying. That does not make this book any less a must read though. If you're interested in making Lean/Agile really work in your organization without running the risk of organizational gravity eroding all your hard efforts over time, this book has the answer on how to do that. I'll be incorporating the concepts of the Toyota Kata in my consulting from now on. Empower yourself. Read this book now! Or at least check out my summary of it.

Saturday, February 23, 2013

Sketchnoting For Absolute Beginners

I've taken up sketchnoting recently, and I love it! So, what is sketchnoting? Why is it useful? And how do you get started?

The answer to the first question is pretty straight-forward: Sketchnoting is a way of note taking that involves not just notes, but also sketches. Mike Rohde, the godfather of sketchnoting, defines it as taking rich visual notes, mixing handwriting and drawing to create a more appealing set of notes. And that's exactly what it is.

To me, sketchnoting is appealing, because as it turns out I've been doing it for the past decade, thinking I should really structure my "mind maps" more like Tony Buzan's. Then, I saw an awesome TEDx vid by Rachel Smith from The Grove Consultants and encountered The Sketchnote Army. It dawned on me that what I'd been doing had a name, was not as strange and uniquely "me" as I'd previously thought, and it was gaining momentum as a cool thing to do at conferences and meetings. I decided to get better at sketchnoting and went looking for ways to do so. I joined a Meetup group by Petra Hegenbart. Never made it to one of those meetups, but in the online discussions we had leading up to the meetups, Petra mentioned an online Rockstar Scribe course by Alphachimp. I enrolled in the course and subsequently read The Sketchnote Handbook by Mike Rohde.

Rockstar Scribe & Sketchnote Handbook

And now, I'm hooked. I've developed the sort of passion for sketchnoting that keeps you in a continuous flow. I _love_ to sketchnote, and feel like I _have_ to do it. Now, in and of itself, the fact that I think it's fun is probably not enough reason for you to try your hand at it. So what is?

The main reason to start sketchnoting, in my opinion, would be that it allows for true active listening, where you engage with a topic in a holistic way allowing you to focus your attention and fully immerse yourself in a subject, be it a talk at a conference, a meeting or a group discussion. If you show what you're doing to the people around you, e.g. by drawing your notes on a whiteboard, flip chart or projector, sketchnoting can contribute to a highly interactive and adaptive meeting. There is something about seeing the group discussion being drawn as they speak that captures people's imagination and holds their attention in a way that just doesn't seem to happen with a Powerpoint, Keynote or even a Prezi.

So, how do you start? That's the beauty of sketchnoting: You're probably ready to start right now. Just get some paper and your favorite pen and you are ready to go. Just start listening for metaphors and models in the conversations around you and draw those images combined with carefully calligraphed text. If you're like me though, you like to select "the best" gear for everything, including sketchnoting. If that's you, this is my kit:

Any way your structure your notes is fine, but there are a few common layouts you could use to get started. A two- or three-column spread with a header and footer, for example. Or a nine-box layout with the main topic in the center (yes, just like a mind map!). Basically, any page layout you find in a magazine or on a website might be useful.

I've done two presentations/workshops on sketchnoting so far. One at Xebia, the other at Agile Holland. Both were very successful in that most, if not all, participants have now taken up sketchnoting, have bought the book, and are having entirely too much fun!

Monday, July 2, 2012

Gearing Up For Stoos Stampede 2012

Friday, July 6, and Saturday, July 7, I'll be attending the Stoos Stampede 2012 at De Rode Hoed in Amsterdam.

One of my favorite quotest from Jack Welch, former Chairman and CEO of GE, is "An organizations ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage."

laurensbonnema_podcastThe Stoos Communique agrees, and states that organizations can become learning networks of individuals creating value and that the role of leaders should include the stewardship of the living rather than the management of the machine.

I have been using the Jack Welch quote as a tagline in my email for over 10 years. It has taken me at least as long to grok its real depth and truth. It has taken me a decade to move from learning from books and courses, to learning from anything and everything. To move from process improvement to system improvement. To move from work-life balance, to just balance. To move from being a true professional, to being authentically me.

Seems a bit vague right? Maybe a little example will help. About a decade ago, I got myself a nice podcasting rig, and started recording stuff. Nothing special, just me talking about things that matter to me, not unlike keeping a spoken diary like they do in Star Trek. It reminded me of how, as a child, I recorded stuff on an old tape recorder that I requisitioned from my dad. I didn't publish those recordings. The idea was to get some practice before launching my project management podcast. Then, I changed jobs and procrastinated the hell out of my rediscovered hobby. But lessons are repeated until learned, so recently, I got the recording bug again. This time, to make sure I mash-up my passions, I've made sure to immediately volunteer my recording services to anyone. First up, the StoosCast!

A week from now, on July 9, I'll publish the processed audio files from Stoos Stampede 2012 right here on this website as two podcast episodes.

After the StoosCast, I intend to revive the Xebia Podcast, and offer my services to lean/agile conferences to make sure I follow through this time. Also, I intend to start recording stuff at some of my client's in-house events.

So, how does that help me grok the Jack Welch quote and the passage from the Stoos Communique? The revival of my field recording hobby, is but an example of a trend I'm spotting in my life and some of the people I meet professionally. The trend is to approach work and other stuff holistically. I've always loved reading, recording, broadcasting, writing, and drawing. But somewhere along the way in my professional career, I stopped doing those things because of self-imposed rules and time-constraints focussing my efforts on other forms of, mostly professional, development. Now, I'm (re)integrating those passions into all aspects of my life. And I'm having a lot of fun doing it!

UPDATE 20121010: My month-long trip to the States, followed by a full-immersion return to work have so far prevented me from editing the audio I recorded at Stoos Stampede. In case you're wondering: Yes, I am still planning to publish the finished files. Probably by the end of this month...

UPDATE 20130216: Finally got round to scrubbing, editing, and uploading the Stoos Stampede interviews.

Friday, March 4, 2011

Agile Project Planning In Twelve Easy Steps

  1. Create a list of all your requirements in Epic format (think Product Breakdown). 
  2. Break down each Epic into work items in User Story format (think Work Breakdown).
  3. Determine which Epics and/or User Stories have dependencies. 
  4. Visualize dependencies in a network diagram.
  5. Create an estimate for each User Story using Planning Poker Points, NESMA Function Points, Gummy Bears, anything but time and/or money. 
  6. Assign business value to all Epics and divide this value between the User Stories based on their point-estimate. 
  7. Sort the list of User Stories based on priority, dependencies and business value per point-estimate (triage). Having trouble sorting the list using triage? Pick another prioritization technique. 
  8. Take an educated guess (assumption) about the number of hours per point you're likely to spend, based on a representative sample of User Stories taken at random. 
  9. Calculate duration based on your assumption. 
  10. Use the calculated duration as input for a Monte Carlo analysis to create your first rolling wave planning.  
  11. Correct the assumption every sprint based on the progressive average of the actual hours per point ├índ a new Monte Carlo simulation for the remaining duration. 
  12. Report regularly, preferably in a reporting format currently in use by the organization.

Tuesday, January 12, 2010

How to get a T-Mobile Web'n'Walk stick to work on Mac OS X Snow Leopard

Yesterday, I had a momentary lapse of reason and bought a T-Mobile Web'n'Walk stick to be able to connect to the internet whenever and wherever I want.

The girl in the T-Mobile store in Groningen was very helpful and sold me the last Web'n'Walk they had, sending me on my merry way to the hotel where I discovered the stick didn't work. At least, not out of the box it didn't.

Figuring this had to be an issue with the Mac software T-Mobile ship with the stick, I decided to be sensible and call customer service. Their first response was "I'm sorry sir, we don't support Mac." At which point I curtly stated this was unacceptable as I had asked this in the store (and gotten a yes), and checked it on the package (which states they do support Mac). The inevitable cop-out was a callback appointment that they failed to live up to.

Which left me to solve the problem myself. As it turns out, it's very, very easy. Here's what I did to get the app to install.

  • Command-click the app and select "Show package contents" from the contextmenu.
  • Enter the "Contents" folder, then the "Resources" folder.
  • Doubleclick the MobilePartner.mpkg file and follow installation instructions.
  • Done!

Everything installed without a hitch. And after installation the software even updated itself to the latest version.

So it would seem T-Mobile ships a faulty installer with otherwise working software. Very easy to fix that. But they haven't yet.