Cooperation vs. Collaboration

February 19, 2019

I was working for a small company that was acquired a few years ago. Soon after the acquisition was finalized, our senior VP invited his new boss to come visit us and meet with some of the leaders of our organization. I was invited to that meeting and introduced as someone who had been leading the agile transformation within our group. I remember shaking this guys hand and thinking he was probably some sort of ex-college football player. He was enormous, sporting a giant smile, and he did what he could to set us all at ease. He exuded confidence and power. After all, he was an exec with a fortune 10 company.

We were all given a chance to ask him questions. I wasn’t feeling very smart at all that day. In fact I was a little intimidated if the truth be told. So I asked what I thought was a pretty lame, if harmless question, “How can you help to promote collaboration between our two groups?” Like I said, weak stuff. His answer was priceless,”Collaboration? Isn’t that what they shot people for in World War II?”

Right then, I knew I was in for a rough ride.

I’ve been reading a book by Yves Morieux and Peter Tollman called “Six Simple Rules: How to Manage Complexity without Getting Complicated.” Yves Morieux first caught my attention in Ted Talk that he gave a few years ago. In that talk he made a compelling case for the over-complexity of today’s large organizations. His argument was that you needed fewer rules and constraints, not more, in order to improve. It turns out, he is speaking from experience. He has tried his approach out with multiple European organizations with some success apparently.

One of the things that he emphasizes early on is the importance of establishing and reinforcing cooperation rather than collaboration. Collaboration is good, he argues, but it’s too limited in scope. It can mean a little as we talked together, but perhaps didn’t actually do much. Cooperation, he argues, implies that at least one side had to give up something, and actually accomplish some work together. So he sees cooperation as a stronger statement than collaboration. Perhaps it is.

Do they shoot people for cooperation?


Individuals and Interactions

January 30, 2019

One of the things that has challenged me the most working with groups of people is the following statement from the Agile Manifesto:

We have come to value individuals and interactions over processes and tools. 

You see, the reality is that when I’m consulting, I almost always seem to end up talking about processes and tools. I talk to teams about scrum (process). I talk to teams about kanban (process). I talk about task boards (tools) and facilitation techniques (tools). I talk about the importance of flow (process) and value stream mapping (tool).  

Basically, I do a terrible job of focusing on individuals and interactions. I lean to the right in this particular equation pretty hard. It turns out that an awful lot of the time I end up doing the very thing that we say we shouldn’t do as agilists.

Don’t get me wrong, I don’t think I’m unique in this flawed behavior. I know for a fact that a lot of consultants have the same problem. We all know that we should be focusing on individuals, but we struggle to find the right way to do that. 

What does an emphasis on individuals and interactions look like? First, it means building relationships with people. Building trust with them and listening to what they say. It means asking questions rather than proscribing solutions. It means inquiring about what interactions there are and what the quality of those interactions are like. It means asking how you feel about a variety of things. How do you feel about your work, your management, your colleagues?

So, the next time you find yourself talking to a group about a framework, remind yourself to take a step back and consider a different approach. Perhaps your time would be better spent asking about how they feel about working together. No process or tool will fix that (all claims by vendors to the contrary). I need this as a rubber band around my wrist. Something that I can snap to remind myself to attend to the people and not the tools. I’ve done tools and processes for far too long. It’s become a bad habit for many of us in the industry. I think the time has come to push back and ask if we are really doing ourselves a disservice with the tool emphasis. 

Look, I know it says tools right in the title of my blog. I get it. It’s a hangover from my early days in blogging when I thought, “Hey, wouldn’t it be cool if I had a blog that reviewed agile tools?” Well, I think I did a tool review just about once and then never talked about agile tools again. I guess that’s just how it goes sometimes with blogs. Sometimes they end up being about things that you probably never expected. That’s OK, I think agile tools has been something that some people have found helpful, and that’s really all that matters to me.


Environments for Swarming

October 5, 2014

143491-425321_140863459444798_1708757280_n1

What kind of environment would best suit a swarming team? I just stumbled across something called the SOLE toolkit while researching this topic. SOLE stands for Self-Organized Learning Environment. It’s designed for children (start ’em young) and provides instructions for setting up this special learning environment. The kit recommends the following:

  • One computer per 4 kids
  • A whiteboard
  • Paper and Pens
  • A name tag

I love this! So our self organizing work environment is configured to encourage shared learning on a single machine (pairing anyone?),  plenty of whiteboards (Yes! information radiators), Paper and pens (do stickies and sharpies count?), and a name tag (team identification perhaps?). These very simple environmental constraints are all that are needed to create a self-organizing learning environment (oh yeah, don’t forget the kids).

These sorts of rules are already pretty common on some Agile teams. The pairing, many whiteboards, and lots of notes are hallmarks of enriched learning environments. So this is a great starting point for creating an environment for swarming too. If you haven’t seen the TED talk and the SOLE Toolkit, you should definitely check it out.

 


Poaching vs. Collaboration

September 12, 2014

adventure-evening-fun-2029-825x550

No one wants advice, only collaboration. – John Steinbeck

Imagine you are working as part of a team on a project. One day your manager approaches you and says, “There is this really high priority project that has come up and we need you and your expertise on it. We are going to move you onto that team for the duration of the project. Is that OK with you?”

How would you feel about that? I know how I would feel. I would feel jerked around. I would not feel in control or part of the decision making. I might even feel that the value of my membership to the team that I’m already on is being discounted. In short, it would suck.

How do you think your team would feel about it? Would they feel like they were able to participate in, let alone determine, the membership of their team? They wouldn’t feel in control of anything either. In fact, they might even feel victimized by the whole experience. They might be thinking, “Geez, we are screwed. How are we going to finish this project without Joe?” They might even wonder why you were the one who was chosen. That could lead to all sorts of fun misunderstandings.

So what would you do instead? After all, there is this project or team that needs help. It’s a top priority – a higher priority than anything else you are working on now. How can we manage this situation without destroying the integrity of the team?

Instead of moving individuals we could take the problem to the whole team. Perhaps a manager would come and sit down with the team and describe what they need. They could explain the trade offs and the specifics of what the other team needs help with. Then they might ask, “Could you guys help this other team out…as a team.”

This would have all sorts of advantages. If a team needs help and you send them just one guy, you’ve increased your team size by one person. If instead, an entire team pitches in to help, then you get the resources of 6 or 7 guys. Forget whatever multiplier effect you might get from a closely knit team – which solution is going to deliver results faster? That’s right, the team of 7. And there is more benefit besides productivity. By engaging the team in this fashion you are asking them to remain a team, and to help another team. Team’s helping teams – what a great idea!

You don’t hurt morale. You leave the decisions on how to manage the problem to the teams – so they feel like they own the problem. They are engaged, they are helping someone else. It really does have a lot going for it.

So what about that other project you were working on? You know, the one that you had to put down to help out with that other team? What about that project? Wasn’t it important too? Sure, but it wasn’t as high a priority, so it waits. This encourages the kind of organizational focus where everyone is attending to the most important issues first, rather than scattering their efforts across multiple lower priority issues in the name of higher utilization or productivity.

So if you are currently in the habit of pulling people off of teams in order to solve resourcing problems, I’m here to tell you that there is another way. If you are open minded enough to give it a try, you might just find that it may be a better way.


Can a Project Be Beautiful?

September 7, 2014

What would make a project beautiful? What sort of aesthetic would we seek? Would would make a beautiful plan? What would make a beautiful backlog? What would make a beautiful team? What would make a beautiful delivery?

I imagine it might be different for everyone…

The Plan

For me, a beautiful plan would be something that covers a wall of a team or war room. It would have requirements, wireframes, architectures, acceptance criteria, impediments.

mess

 

 

 

 

 

It would tell a graphic story of the evolution of the project over time. It would be a graphic history in multiple dimensions, worthy of Edward Tufte. But it would not be perfect. It would reflect rough edges, rapid sketching, mistakes, blind alleys, rough annotations everywhere.

istock_000019366898small

 

 

 

 

 

 

 

 

It would also reflect the growth and improvement of the team. Items from retrospectives would be incorporated into the timeline. There would be different ways that the team measured their own performance. It would be a glorious mess!

OLYMPUS DIGITAL CAMERA

 

 

 

 

 

 

 

The Backlog

A beautiful backlog would be on it’s own wall. It would reflect dialog with the customer, questions from the team, user profiles and scenarios.

tumblr_ly5c4tDfnr1qfg8uu

 

 

 

 

 

 

 

 

 

It would be shaped like an inverted pyramid, with rich detail at the top, tapering down to sparse sets of one line ideas and proposals below. It would have color (LOTS of color) and use different shapes to indicate stories, epics, features, etc.

writing-on-wall

 

 

 

 

 

 

 

The Team

A beautiful team is tight. The team works physically closely together, eliminating all barriers, focusing on collaborative activity over solo activity. They work together, they eat together, they respect each other. They share roles and responsibilities promiscuously.

teamroom

 

 

 

 

 

 

 

 

 

They pair, they mob, they swarm!

8666.pp-Team-Room_4C3230AF

 

 

 

 

 

 

 

 

 

 The Delivery

A beautiful delivery is smooth and effortless: friction free. It happens on demand – with the ease of a thought. Work flows through to production almost inevitably. It’s a downhill slide, not a grind uphill.

Free-Mattress-Delivery-Farmington-Hills

 

 

 

 

 

 

 

 

 

 

 

What does a beautiful project look like to you?


Being There – Geek Style

July 2, 2010

I’m getting another lesson in “being present” with people. Specifically my 3 year old daughter. When I’m playing with her, she demands my absolute, complete and undivided attention. Any distraction on my part is a punishable offense – usually by a rather irritated, “HELLO Daddy!” As a part time geek and full time father, I find this requirement to be completely “present and in the moment” often hard to satisfy. You see I’m really the typical introvert – often imagining I’m somewhere else, ruminating on a problem, running some absurd internal monologue, or otherwise just drifting about with my head in the clouds. Apparently children don’t tolerate that sort of behavior particularly well, and in my opinion, neither do teams.

I don’t know much about kids in general, but from what I’ve seen from mine so far they are *extremely* highly interactive creatures. They are avidly absorbing everything in their environments like manic little sponges. They’re asking questions and gosh darn it, they expect the answers pronto! They’re looking for a good partner, someone who is going to attend to their every need. And as a good partner, they are watching you to see where you might be going next. They repay any attention you give them with vigor, enthusiasm and affection. Not a bad dividend really.

Teams are a tougher nut to crack. They are also highly interactive beasts to work with. They are doing a lot of learning, typically trying to understand a complicated domain or design challenge. They’re asking questions and gosh darn it, they expect the answers pronto! I hope you see where this is going by now…

Recently I attended the XP2010 conference. One of the sessions that I attended was on using improv theater techniques to learn to be a better team member (this was facilitated by Mike Sutton – a really fantastic guy). A lot of improv is about being “in the moment.” It was all about making yourself a good partner to interact with. I found it to be a very powerful experience and I felt like I got a lot out of it. For instance, like many geeks, I place a high value on cleverness. But it turns out that “clever” behavior is very hard to anticipate (and even harder to produce with any consistency). So being too clever can make you hard to work with when you are doing improv work – it’s hard to know what you are going to do next. Now, I imagine there are a lot of parallels between improvisation and collaborative, problem solving work. In fact that was really a theme of the conference.

The conference reception was kicked off with a presentation by two jazz musicians. They did a fantastic job of demonstrating improvisational musical technique for us in an entertaining and thought provoking way. Part of the message was about making yourself a good partner, but for them, an equally significant message was that in order to express ourselves truly, we need to learn how to be “in the present”. They ended their presentation with the  following quote:

Yesterday is history.  Tomorrow is a mystery.  And today?  Today is a gift.  That’s why we call it the present.  ~Babatunde Olatunji

So what does all of this have to do with teams? Look, let’s get one thing straight – so much of the “process” that we use on software development teams is all about planning or history. Very little of the process focuses on the work actually being done in the moment. I consider the work in the moment, the collaboration that takes place as we are writing code, as the hardest part of the development process. We have techniques that lead us toward this mode of collaboration like pair programming, but often I find teams resist them. Teams that aren’t able to work in the moment, in the present with each other, are going to be handicapped in the speed with which they can deliver innovative solutions. If you are looking for the place with the greatest opportunity for improvement for your team, try steering away from the process – the planning and the history – and try spending more time in the moment. Focus on the actual work you and the team are doing right now. Give your team a gift – the present.


Agile Teams Better Found Than Made?

December 22, 2009

I’ve been dabbling with the idea of swarming and how it might relate to team organization in software development for a couple of years now. There are some great resources out there that provide tantalizing hints toward how we might create self organizing teams that are capable of “swarming” and solving problems rapidly.  After a while I realized that I wanted to find a way to create one of these self-organizing teams using principles similar to those we find in nature. What would you do? How would you organize a team that you wanted to behave more like a swarm than a traditional top down entity?

Lately I’ve realized I may have gotten it all backwards. It may be impossible for one person to organize a self-organizing team. On the face of it, it’s an obvious contradiction in terms. You really can’t tell the team how to act and then say, “self organize guys!” (as we so often do in Scrum). So is it even possible to “make” a self organizing team? I think that a really good self organizing team is a much more subtle and elusive beast than that.

Maybe we need to take Peter Gloore’s approach and instead of trying create self-organizing teams, we should try to discover self organizing teams that already exist within our organizations?