Self-organization

There was a big discussion last week about how open space, open source and agile methods are related. The conclusion was that comparing those three methods has limited value.

Then Harrison Owen (originator of Open Space Technology) offered this perspective:

...I think that the value might lie in understanding that operative power underlying all three "methods" is self-organization. And to the extent that any of them "work" they do so because self-organization works.

It then might be very useful to consider how each method enhances the possibility for effective self-organization. What is the same and what is different?

From where I sit, it is all open space (not Open Space Technology) and the critical question is how can we most effectively work with it?

To quote my now favorite mantra -- "There is no such thing as a non-self organizing system."  There are only some mildly deluded people who think they organized it. And there are also, I am sure, an infinite number of effective ways to enhance our capacity to work intelligently in the self-organizing environment.

This led me to ponder how Scrum and other Agile methods --which are powered by self-organization-- use container, meaningful exchanges, and significant differences. (I wrote a bit about these ideas here.

It's worth making these connections explicit. When people don't know why particular practice works, or how a practice interacts with other practices, it's easy to misapply the methods. (And then wonder why its not working.)

For example, I talked to someone who was frustrated with stand up meetings. When I asked some questions, it came out that in their organization, stand-up meetings lasted two hours and included 30-40 people. (No wonder they were frustrated.)

Some where along the way, the essence of the stand-up meeting and its purpose of enabling meaningful exchanges within the context of the container got lost.

Thinking Together

Rachel reports on her pursuit of facilitation skills and her experience learning the Technology of Participation (ToP).

ToP isn't a grab bag or techniques and gimmicks -- it's a method based on the way humans naturally process information. The methods are flexible and adaptable.

I've been using ToP methods to help groups think together for years. I've used them for planning, requirements work, establishing priorities, surfacing group values, finding over arching categories, risk management... the list goes on.

Rachel attended a UK course, US courses here, courses in Canada here. ICA has a presense in many countries, don't know the details of training offered, but the websites are here.

Skills for "the People side"

I want to follow up Joshua's comment that it's high time we focus on the people side. What does that mean?

I ran into someone who described how he had handled a "people" issue. I'll call him Joe. Joe believes he's adept at handling people issues.

One of the people on Joe's team had a strong body odor. I'll call him Sam.

Joe found it unpleasant to pair with Sam, or be with him in a closed room.

At one of their team meetings, Joe commented that "personal hygiene is important."

Surprisingly enough this comment didn't lead Sam to change his personal habits.

Joe was really annoyed that Sam didn't take the hint. He couldn't take it any more. Joe also was mad that Sam was so dense that "he was forcing me to be harsh."

Joe went out and bought a large can of deodorant. He walked up to Sam, handed him the deodorant and said "You stink. I can't stand working with you, you smell so bad. Take a bath and use this."

This is not a stellar example of dealing with people issues.

In my view, interpersonal skills start with self-awareness, self-management, and social skills.

Self-awareness is about being aware of your own internal state and knowing who shows up when you enter the room -- how your behavior affects others. And it has to do with understanding your internal process in communication.

Self-management is about what you do with your internal state -- not getting rid of emotions, but consciously choosing how you express your emotional state. You acknowledge the importance of your emotions, but you aren't in the grip of them.

Social skills include empathy, the ability to navigate conflict effectively, give feedback respectfully, participate in groups and value differences.

These are the foundation for skills that help us build bonds and work collaboratively with others.

Focus on the People Issues

Joshua Kerievsky posted this update from SD West on the IXP mailing list:

At an SD West agile panel this week, I was jolted by legendary guru Jerry Weinberg.  He said he'd recently looked over the past 500 issues of a certain computer journal in order to count how many issues had been devoted to "the people side" of our business.  The answer?   3!  

Meanwhile, despite advances in programming languages, operating systems, networking and software processes, people involved in software development continue to find that "people issues" are the hardest to deal with and the greatest hurdle to achieving lasting excellence in our field.

Sounds to me like it's high time to focus on the people side of our
business -- something Jerry's been doing for a long time now...

Absolutely.

That's why Diana Larsen, Ken Schwaber and I are launching a new workshop,The Secrets of Agile Teamwork: Beyond Technical Skills.

We're focusing on building capacity in collaboration skills -- the skills people need to build solid self-organizing teams and work effectively with others in any sort of team.

We'll be running a public workshop in Portland, OR April 5-7, and we've already had inquiries about in-house workshops.

It's an idea whose time has come.

Diana and I have been working on the design and materials this week. We've got a great group coming and we're really excited about the workshop.

Self-organizing teams

Alicia Yanik has a great article on her experiences implementing Scrum over on stickyminds.

We had the Scrum logistics in place, but I struggled with harnessing the team’s power...

Then I took a closer look and noticed the team problem solving, self-organizing, and trying out Scrum practices without any nudging from me. Within a month of their introduction to Scrum, the team was making changes to their environment and beginning to introduce new practices into their coding conventions. Within six months the team decided to re-architect their entire code base – to make it more Agile!

Yep.

This is the story I hear from teams that implement various flavors of Agile methods. The team takes on a management role, managing their work, processes, and inclusion/exclusion.

Interpersonal Skills

Words are important.

I've fallen into the habit of talking about "soft skills" --
meaning intra/interpersonal, communication, and collaboration
skills.

Pretty common usage, so I'll cut myself some slack.

But I'm going to change the language I use.

There's something about "soft skills" (or worse, "the touchy-feely stuff" or "the fluffy stuff") that says "not important," especially when you contrast it with "hard skills."

So from now on: Collaboration skills or interpersonal skills replaces “soft skills” and technical skills rather than “hard skills.”

Project work is a social activity, and we won't get very far without interpersonal and collaboration skills.

Creating a Cut-throat Culture

Johanna's on a (very excellent) rant about forced ranking.

I concur.

Some people are convinced that forced ranking is a Good Thing. Usually they have arguments such as "everyone needs to know where they stand," or "we need some way to weed out the poor performers."

Bah.

Actually, it's not terribly helpful for people to know where they stand in a company-wide, department-wide ranking, or even a group ranking. In wide rankings, you end up comparing jobs that are dis-similar. In small group rankings, you destroy teamwork.

As for weeding out poor performers, it's a manager's job to a) hire people who are a good fit, b) encourage people to find a better fit (maybe at a different company) when it's not working (usually helps to timebox this, so you aren't encouraging someone to find a better fit forever).

3/14 Thanks to Andy for pointing out a couple of typing errors that spell checker missed.

Story Time

I wrote a little article (posted on stickyminds) about how our interpretation of an interaction can get us in a tangle.

Sometimes we hear someone say something, and conclude that we're being treated unfairly or we're under attack.

A friend of mine wrote to share his story of being "under attack:"

My wife would come home and ask "Where are the kids?"

If I didn't know then I was a "bad father."

...in my mind the question became a statement "You are stupid, incompetent, ..." and my reply became "Why are you berating me?"

You can imagine where the conversation went from there:

"I'm not berating you."

"Yes, you are. You always imply I'm incompetent as a parent!"

Downward spiral ensues.

In the article, I describe two types of stories. In "I'm an innocent victim" stories, we tell ourselves our own motives are pure, and that we are 0% responsible in the situation.

"He's a bad guy" stories ascribe evil motives to the other person and make the other person 100% responsible.

Either way, we're off the hook, but the relationship is damaged.

My friend went on to say:

Finally I realized she was simply inquiring about the x,y coordinates of the children - not attacking me.

Sometimes we are under attack or being treated unfairly. But it's worth checking out our own stories, and then checking out the other person's intentions before going into the downward spiral.

the opposite of sustainable pace

Also from Dave Smith: Four of Cubicles

Sustainable Pace

Via Dave Smith: Why Crunch Mode Doesn't Work: 6 lessons by Evan Robinson.

Evan's 6 Lessons.

Lesson One, then, is this: Productivity varies over the course of the workday, with the greatest productivity occurring in the first four to six hours. After enough hours, productivity approaches zero; eventually it becomes negative.

Lesson Two, then is this: Productivity is hard to quantify for knowledge workers.

Lesson Three is this: five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century. What makes us think that our industry is somehow exempt from this rule?

Lesson Four is this: At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.

Lesson Five is this: Continuous work reduces cognitive function 25% for every 24 hours. Multiple consecutive overnighters have a severe cumulative effect.

Lesson Six is this: Error rates climb with hours worked and especially with loss of sleep . Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?

It comes down to productivity. Workers can maintain productivity more or less indefinitely at 40 hours per five-day workweek. When working longer hours, productivity begins to decline. Somewhere between four days and two months, the gains from additional hours of work are negated by the decline in hourly productivity.

I still run into managers who believe that long hours will help bring the project in and by enforcing long hours they are teaching people how to "work hard."

This belief persists because it is hard to quantify productivity for knowledge workers. But it's not terribly hard to count defects or see the relationship between work actually completed and work remaining when you count in the new work from defects. When you measure only hours, the dynamic may remain hidden. But you'd think that when the project still didn't finish at the desired time despite long hours, people would begin to question their assumptions.

Maybe the studies Evan cites will convince some people.

Read the full article here.