Swarming Context

September 29, 2014

Rail_Bridge_Swarm_of_Starlings._-_geograph.org.uk_-_124591

The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.

So what are the four contexts of Swarming? Here they are in no particular order:

  • Emergencies
  • Shifting Gears
  • Innovation
  • Building

Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1” defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.

Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.

In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.

Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.

In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.

 


The Grumpy Scrum Master

September 17, 2014

grumpy dwarf

“Going against men, I have heard at times a deep harmony
thrumming in the mixture, and when they ask me what
I say I don’t know. It is not the only or the easiest
way to come to the truth. It is one way.” – Wendell Berry

I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right.

We sat down and had a talk. It turns out he’s tired and cranky and seen this all before. I told him I can relate. We agreed that we’ve both done enough stupid to last a couple of lifetimes. No arguments there. He knows what he doesn’t like – me too! After a little debate, we both agreed we don’t give a damn what you think.

So we decided it was time to write a manifesto. That is

We grumps have come to value:

Speaking our mind over listening to whiners

Working hard over talking about it

 Getting shit done over following a plan

Disagreeing with you over getting along

That is, while the items are the right are a total waste of time, the stuff on the left is much more gratifying.

 


Role != Job

September 16, 2014

Student_teacher_in_China

When I talk to folks about Scrum, one of the points I make sure to cover is the holy trinity, the three basic roles in Scrum: Product Owner, Scrum Master, and Team. I’m starting to think I must be doing it wrong because when I talk about roles, somehow that role manifests itself as a job. Let me back up a step and see if I can explain what I mean. To me, a role is a transitory responsibility that anyone can take on. It’s akin to what actors do. Actors take different roles all the time. But when an actor takes a role, say as a teacher, they act in every way like a teacher, without actually being a teacher. They do it and then leave it behind and move on to the next role. They may perform the role so well that you can’t tell the difference between the actor and the teacher, but to the actor teaching is still just a role.

Now there are people for whom teaching is a job. A job is very different from a role. You are hired for a job. A job is something that you identify with and are assigned to. A job, at least for some, becomes something that they identify strongly with (i.e. “I am a teacher.” or “Teaching is what I do.”). A job is a very different thing than a role. A job comes with identity, some feeling of authenticity and permanence. Typically we hire people to perform jobs.

According to this definition, jobs and roles are very different beasts. However, people have a hard time keeping this distinction in mind. We tend to take roles and turn them into jobs. That’s unfortunate, because a role is meant to be something transitory, something that is filled temporarily. It is meant to be worn like a costume and then passed on to the next wearer. When you turn a role into a job, you risk perverting it’s purpose. When you turn a role into a job, you make it very difficult for others to share it – it’s hard to swap back and forth. When you make a role into a job, people get surprisingly defensive about it. It becomes something that they identify with very closely. If you try and tell them that anybody can do it, they tend to get all fussy and upset. They start to try and protect their job with clever artifacts like certifications – they’ll do anything to make themselves unique enough to keep that job. It’s an identity trap.

Here is how I see this problem manifest itself with Scrum teams: You sell them on scrum and teach them how it works. Every team has a Scrum Master and a Product Owner. So what do they do? They run out and hire themselves some people to fill the jobs of Scrum Masters and Product Owners. They get their teams sprinting and start delivering quickly – hey, now they’re agile! Only they’re not really. You see, as you face the challenge and complexity of modern day business, the team often needs to change. That person you hired as the Scrum Master? You may be best served to swap that role with somebody else. Maybe a developer or QA on the team. The ability to move that role around to different actors could be very useful. But you can’t do that now because it’s no longer a role, it’s somebody’s job. And you can’t mess with their job without seriously upsetting somebody. The end result is that your organization effectively can’t change. You limit your agility.

The bottom line is that I believe that the roles in Scrum were never intended to be jobs. To make those roles into jobs risks limiting your agility.


Killing the Buddha

September 10, 2014

imagesIJ4EINVG

 

“If you meet the Buddha on the road, kill him!”

This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.

In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.

Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.

OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:

“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”

Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.

fish

Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Thought Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.

You become, THAT guy.

And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”

…oh brother, I think I just dated myself straight back to the stone age.

So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?

  1. Keep your mouth shut
  2. Stop telling people what’s Agile (see #1). Use pantomime or something instead.
  3. Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
  4. Rinse and repeat until nobody mentions Agile in your presence. Ever.

So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.


Culture Club

August 6, 2014

pablo-picasso-don-quixote

 

 

 

 

 

 

Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture:

  1. You can’t change culture, you can only adapt to it (customize your process to fit)
  2. You can change culture (through influence, good looks, and the right practices)

Of course, perhaps the first question is, “What is this culture thing anyway?” Most definitions of culture are terribly vague and in my opinion not especially useful (although, couched in the delightfully hand-wavy  terms of corporate sociology, they usually sound very smart). Just for giggles, here are some definitions:

  • Culture is the accepted norms of behavior for a group
  • Culture is the collection of social contracts that a group depends on
  • Culture is how we treat each other
  • Culture = people

I forget where I saw that last definition (Tobias Mayer?), but it’s probably my favorite of the bunch. You see often culture is used in conversation to hide or excuse problems with people. It’s kind of like referring to employees as “resources” (Ooh! Now I can be that irritating agile guy who corrects people’s terminology! A word to the wise: Don’t be that guy). So where was I? Oh yeah, culture. So here’s the deal, I don’t like the term culture because it’s just too damn vague. Often times I get a lot more clarity if I use more specific terms to describe the problem. For example:

  • Our culture won’t permit us to do that = Manager X won’t permit us to do that
  • Our culture only supports hierarchical decision making = Bob likes to make all the decisions

Once I take the time to replace culture with more specific terms (Who, What, Where, When, Why), I usually find that the problem feels more manageable to me. More human and less onerous. On the one hand, “Our culture” is vague and hard to put strategy around. On the other, influencing Manager X is a simple exercise in winning friends and influencing people. That’s something I know how to do. People I can work with. Culture…not so much.

So if you accept this definition of culture (culture = people), then your ability to change the culture directly depends on your ability to influence people. That’s Dale Carnegie stuff. It’s not easy, but it can be done – one person at a time. When you are in a small company, that’s not too daunting a challenge – win a handful of people over and you are done. However, in a large company, it’s quite a different matter. In a large company you have to win over hundreds or even (heaven forbid) thousands. That’s a very different challenge – and it’s an order of manure…uh…magnitude more difficult. It can be done, but it’s a long term challenge that may take years – and while some strategies you will use with larger groups are the same as for small groups, often they can be very different. If you are accustomed to trying to change the culture in small companies, you almost have to learn a completely new language in order to try and change the culture at large companies.

But seriously, can you REALLY change culture in big companies? One way to answer this question is to look for examples of successful culture change within large corporations. There are one or two that I can think of:

  1. Richard Semler, SEMCO (As described in the book, “Maverick”)
  2. James Collins, “Good to Great” (A series of stories of dramatic corporate change)

If you accept these stories as true, then the answer must be that culture change can indeed happen. But perhaps you are an inveterate cynic (like me) and don’t believe everything you read in books. Maybe culture change is just something that people with extraordinary power can achieve (like CEOs). Then what hope do those of us who exist much lower down in the corporate hierarchy have? Two thoughts:

  1. Sometimes we have to accept that our sphere of influence is limited. Those limitations are things that are very real like geography. You may only be able to influence folks that you work with in your particular office (which makes a lot of sense). Influencing the rest of the organization is going to be much harder. This has nothing to do with culture and everything to do with constraints. Start small, gather your wins, and grow.
  2. You can just wait. Bide your time. Sometimes you have to wait for the right opportunity. How long should you wait? I don’t know. There is an element of patience when dealing with culture change. You need a lot of patience. Focus, prioritize, and be ready. There’s nothing wrong with that approach.

OK Tom, what if I still don’t buy it. My company is HUGE and there is just no way that I can influence these clowns…er…people. No matter what happens, once an organization gets above a certain number (perhaps the Dunbar number) then it becomes extremely difficult to change. So difficult in fact, that it’s just not worth fighting. If that really is the case (and in many cases it just may be), there really are two approaches:

It may be that there are kinds of change that will never be accepted within some organizations. However, usually, that is a relatively small set of invariants. There usually still remains a broad spectrum of change that can be introduced successfully. Just stay away from the hot buttons. Does it really matter that you introduce every single one of the 12 XP practices? Or would it be enough just to introduce a few (there is still some benefit gained). Can you bring change in small amounts rather than a huge batch? There is plenty of room for creativity in this sort of culture change.

In the end, even after all this, you may come to the conclusion that you can’t change the culture in big organizations. Maybe it’s just too hard. Perhaps you just don’t like Dale Carnegie. I don’t know. That may just be the way it is. If that ends up being the case for you, then saddle up Rozinante. Grab Sancho, and go find some more giants to tilt at. The world is full of them.


Agile Coaching and Training is a Scam

May 5, 2013

con-man4

In the Agile world, coaches and trainers are distinctions that were created in order to create different ways of making money. They have no useful business purpose outside of filling the pockets of consultants with cash.

How can I maintain this? Here’s how I see it now: I (used to) have friends who are trainers. They are normal people like you and me. They typically got their start as project managers and or scrum masters just like the rest of us. At some point they go through a process where they are vetted for the following:

1) An understanding of the vague terms used in the agile lexicon
2) Conformance to religiously held views regarding a process
3) Communication skills & attitude

Once they are hit with the golden hammer, anointed by the powers that be, given the blessings of the bishops, or certified, they can charge large amounts of money to provide the same training over and over…and over…

Or they can just go out on their own and do it without any such approval. Of course if they do that, then they have to survive based on whatever actual skills they may have. They have to come up with their own material that isn’t provided by some governing authority. They have to market their skills all by themselves, and it’s a cold and unforgiving consulting market out there.

Regardless of which path you choose to take, are you doing anything that a good scrum master or a project manager couldn’t do? No. Training is part of any good manager’s role. Many scrum masters that I know have actually given CSM training at one time or another – and done quite well. Furthermore, the agile training that I’ve seen isn’t rocket science. It takes only marginal presentation skills to successfully deliver agile training. It’s not original material. It’s not like you have to know how to write code. In fact, most trainers I know, can’t write code. Are these really the people who are going to tell software developers how to work?

It’s nice work if you can get it.


Value Creation is a Dialog

April 25, 2012

Day two of trying to live the first principle of the 12 principles of the Agile Manifesto (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”). So far so good. I spent much of the day co-training a class. It was a unique training because we asked the attendees to pick the topics that were most valuable to them, prioritize them, then taught the material. Finally we finished up with periodic retrospectives throughout the day. It seemed fairly obvious that this was a great example of asking the customer what they value, delivering the value, then checking to see if they thought it was really useful. After an entire rather exhausting day of this, it occurs to me that continuously providing value is actually a dialog (or perhaps an ongoing experiment) that works like this

  1. Ask what value you can provide
  2. Attempt to provide that value
  3. Ask the customer if they got the expected value
  4. Adjust and repeat

I think that value cycle lies at the heart of a lot of Agile processes. You see this in the sprint reviews and retrospectives on projects. It really is the PDCA cycle all over again. But speaking for myself, I think I’m going to have to modify my approach this week. Here’s a sample:

  • Ask friend: How can I provide value
  • Friend: Buy me a beer
  • Beer provided
  • Ask friend: So, how’s that beer?
  • Friend: Excellent! Too warm! Too foamy! bitter, etc.

Value delivered.