Resources = People

Whenever I work with new teams I always ask, “who here has been on a project where adding people actually slowed progress?” Inevitably at least half the people in the room raise their hands.

The reason this is so common has its roots in one of the most damaging, insidious and pervasive mindsets I see in the businesses I work with. It can be summed up in a single word: resources.

This word saps the energy and enthusiasm of those whose creativity and engagement we need most — the people who design, build and innovate our products. It also causes us to structure businesses in highly inefficient ways resulting in poor quality, unhappy workers and waste-filledß production cycles.

First off being called a “resource” can siphon off pride and engagement making you feel like a wear part on an assembly line, and can also promote this kind of thinking among managers. But the real problem goes far deeper than the dehumanization the term invokes.

At the heart of the word “resource” is the idea of a fungible unit that can be moved from project to project or even partially allocated to more than one project. This misses a fundamental point about what it means to be human and therefore what it means to build a great business.

Humans are hard (and soft) wired to work with other people. Biochemistry, brain science, sociology, psychology, anthropology and economics all tell us the same thing: people work better when we work together. We’re happier, more productive and healthier. We live longer, report fewer health problems and greater life satisfaction when part of a community. We’re also more creative and engaged.*

But to reap these benefits we have to be in sustained contact with a core group.  When a person moves (or is moved) from project to project they switch context continually, never get up to speed, fail to form deep trusted connections with coworkers and are easily overwhelmed by competing demands.

In order to move beyond this kind of thinking we need to look at our language and attitudes but more importantly we need to rethink how we structure our organizations.

Here’s a cheat sheet:

1. Resources are people.
2. People work best with others.
3. Teams work best when stable.

Good managers and executives therefore build stable teams and move the work to the teams. They don’t “allocate resources” to projects.

This kind of team-based thinking and organization promotes innovation, quality and speed. And I predict the most competitive and profitable companies of the next 10 years will be the ones who are most able to create management systems based on empowered, self-organizing and self-managing teams.

And in order to get there they’ll need to rethink reporting structures, performance reviews and compensation schemes along with the org chart and management culture.

I’ll have more on this in subsequent posts. In the meantime tell me what interests you so I know what to write about.

What would change in your business if your adopted these guidelines? What’s stopping you from starting now?

– — –

Photo by Muffet

* For more on this see The Happiness Hypothesis (one of the most important books I’ve read this year)

What’s Love Got to do With It?

My friend and mentor Bryan Franklin recently gave a talk at TEDx Sin City challenging the audience to consider what impact they truly want to have in the world. This caused me to inquire deeply about why I do what I do. Why Agile? Why software? Why not something else.

My response may surprise you. Then again it might not. I welcome your thoughts on what place the word “love” has in the business world.

I also invite you to check out Bryan’s original talk. He is a remarkable thinker, coach and human being.

Collaboration and the Enterprise

A 5-Minute Interview with organizational psychologist Laura Danforth.

Holacracy – Kanban for Everything

On a recent visit to San Francisco I met up with Brian Burt CEO of Maestro Conference – an innovative conference call and remote education platform. It was also the first project I worked on as Product Manager where I applied Agile. We made a lot of mistakes back then but managed to successfully launch a product in very trying economic times. More importantly we learned how to work together.

Brian became so enamored of Agile that he has now adopted a corporate governance system called Holacracy which is based in part on Agile. In this short video Brian walks me through his system. Enjoy.

The Importance of Failure

Chip designer Amjad Obeidat spends his days building stuff that’s never been built before. In this 5-Minute interview he talks about the importance of failure in his process.

For more on failure check out this video from Honda.

Transformation and Management

Speaking with Geoffrey Bourne (SVP at a large financial institution and Agile aficionado) over dinner last night, my thinking arrived at a sticky yet significant point about the role of management in creating organizational Agility.

Management layers in large corporations are numerous and are built on a top-down reporting and power structure. In such environments command-and-control mindsets are crucial for career survival and reinforced by almost every aspect of an organization from the org chart to the placement of desks.

Yet Agility depends on bottom-up empowered lines of communication and collaboration. And this requires individual and team motivation and commitment. But commitment – the ability to say a powerful “yes” – can only happen in an environment where you can also say “no” meaningfully.

So when an organization attempts to reap the benefits of Agile they must also be willing to give up control. The jujitsu of this move however is that by giving up control you gain power and speed – like a cyclist who takes her hand off the brake and can suddenly travel faster and steer more effectively.

Line management seems to be the key. While executive support is important new, their jobs don’t change significantly in an Agile transition – at least not early on. And delivery teams usually get the benefits (and therefore motivation) quickly. It is the managers and business people who work directly with delivery teams who’s lives change the most and unless they are enthusiastic and good managers already Agile will fail.

It now appears to me that when selecting a team to begin an Agile transition, one of the most important filters we can use is to select a project that has a talented, enthusiastic manager (who is not risk averse) already in place. That is they need to be confident and self-aware enough to be able to relax the reigns of command-and-control below while still operating in one above. All they while knowing that the success or failure of the project will reflect on them. A conundrum if there ever was one.

What have you noticed about the role various layers of management play in successful organizational transformations (Agile or otherwise)? What do you look for in a manager (Agile or otherwise)?

Collaboration Can Kill

And why it’s a good thing.

THE END

I got the call just two months after we’d begun – the venture was off and I was out of work. In the weeks that followed my last two paychecks bounced actually costing me money and my friends and I scrambled to take our skills elsewhere.

Why is it that I now view this obvious business failure as a personal victory and a confirmation of the power of collaboration?

THE BEGINNING

The story begins several years ago when I was finishing grad school. Some classmates and I, along with and a few high-powered collaborators were working on a startup we thought would change the world. We were excited, enthusiastic and dare I say visionary.

A partner out of state held the technology, the money came from a local investor, and together we’d assembled a dream team of advisors and collaborators including a well-known former banker and monetary theorist and a former oil executive known for her visionary ability. Most other members of the team had a proven ability to make things happen and to think outside the proverbial box.

We envisioned an enlightened social venture (we were working in clean energy) that would create value and disseminate a simple and disruptive technology. We were sure we could not fail, or if we did we’d have learned a ton about an important sector and moved an important technology significantly forward.

We were wrong.

The business team had been working together for about 2 months and had created a preliminary marketing and business plans. The technology had been in development for a few years inside a university. After working in parallel we decided it was time to come together and “form” as a team with a 3-day, face-to-face session. I helped shape the agenda and ran many of the sessions. We based what we did largely on principles borrowed from Holacracy.

When we left town a few days later we had no agreements and no plan for moving forward. We were demoralized but looking back I believe that, though uncomfortable, this was the right outcome.

WHY IT DIDN’T WORK

The most significant barrier to moving forward was a fundamental disagreement between the technology holder and the business team regarding the valuation of the company. Without agreement we had no basis to raise investment and without investment we had no business. We worked hard to find common ground however it just didn’t exist then and still doesn’t today.

I should mention here that though I have my opinions about who was right and who was wrong, I’m not here to pass judgment. Well meaning people will often disagree and collaboration is not about proving who is smarter. It’s about finding common ground and a common purpose and moving things forward. If that cannot be accomplished then parting ways is usually the best option. Marketers often say the best answer is yes the second best is no and the worst is maybe. The same is true of team formation.

WHAT I LEARNED

Those 3 days were some of the most difficult I’ve ever experienced but the during that time we were forced us to talk to each other, face facts and ultimately decide to part ways.

The collaborative tools we used didn’t cause dissention but they did surface disagreements that were already there. Collaboration and Agile are not silver bullets, they don’t solve all your problems. They are however silver mirrors that allow us to see the present situation more clearly – even if that situation is not pretty.

What lessons do you take for your business from this experience? For me it’s to ask difficult questions early and to not be afraid to walk away.

From Command & Control, to Collaboration

5 Steps to Collaborative Culture

A keynote address on collaboration at a Rally Agile Success Tour in New York on Thursday March 3, 2011.

How Many Coaches to Form a Team?

Last December at the quarterly Rally coaches gathering in Boulder CO, four coaches (Isaac Montgomery, Steve Adolph, Scott Dunn and myself) resolved to form a team to write a book about Agile aimed at a general business audience. And we resolved to write it in an Agile fashion – eating our own dog food as they say.

Today marks the acceptance of our third iteration plan and I think we are finally getting somewhere. Along the way we’ve learned that Agile is not as easy as we sometimes make it out to be. Here are a few specific lessons.

BEGINNING: It takes time and commitment to form a team. As coaches who travel a lot and are focused on delivering in-person trainings 2-4 weeks each month finding the time to commit to work was challenging at first. We found that we had to first commit to a few meetings to shape the project before we could find the time (e.g. motivation) to commit to working on the actual writing.

DO SOMETHING: Early in the project we had a vision and a team and not much else. This lack of clarity early on nearly overwhelmed our enthusiasm and it was only by focusing on the small chunks, that we could do, that the project began to take shape.

CREATE SOMETHING TO KILL: We began, logically, with the introductory chapter only to realize that this was best written last. This chapter is sitting in our repository unfinished – we may never use it but it was an important step nonetheless.

DECLARATIONS ARE IMPORTANT: Early on we formed a product team – stakeholders from each part of Rally – that we would demo our work to (at the end of each two-week iteration). Without assembling this group, and declaring to them what we are working on, we might never have made it through the early stages of the project and developed the momentum it now appears we have.

IT’S EASY TO FORGET TO INSPECT & ADAPT: We are coaches, we advise and train teams for a living frequently admonish them that the Retrospective is perhaps the most important meeting in any Agile cadence. Yet it wasn’t until this morning that it occurred to us that we should schedule a retrospective as part of OUR cadence (doh!).

This has been a humbling and educational experience for us all and we’re beginning to realize that the story of creating this book may be more interesting than the story itself. Stay tuned for future updates.

What would you like to know about the project?