This is the Way Scrum Ends

September 30, 2014

Processed with VSCOcam with x1 preset

This is the way the world ends
This is the way the world ends
This is the way the world ends
Not with a bang but a whimper.

– T.S. Eliot

Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way it has to be. Perhaps all great new ideas eventually become diluted in a sea of mediocrity.

I think I hear a longing in some to fight such dissolution. To resist the forces of corporate entropy. Rather than try to fit in, they urge us to confront and overturn the system. You know, subvert the dominant paradigm? Confronting this dissonance is the difference between making a living and actually living.

I wonder if that’s the difference between those who “fire” their customers and those who stay and work within the system. Are those consultants who give up and declare, “These clowns aren’t ready for Scrum.” going out with a bang? And what about those who stay? Are they afraid to make the big moves and just content to fit in? Whimper. Or are they more subtle than that? Can you embrace your client and still change them? Perhaps the “bang” approach is quicker, and more decisive. And maybe, just maybe, remaining engaged is very, very hard, but yields results in the end.

I know, I know…why so bleak? Well, I feel this tension a lot in our weird little community. I’ve been on both sides of the engagements where a respected consultant has tossed their hands in the air and walked away from the engagement because “They just don’t get it.” or “They’re not ready yet.” And I’ve been that poor fool, laboring away within the system, living on a meager diet of optimism and the occasional conference, trying to make change happen. I won’t pretend to know which approach is right, or even when to use these strategies, but I think it would be worthwhile to understand this issue better.


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.

 


Team Genetics

September 28, 2014

dna-163710_640

Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…


Broadcast Communication

September 27, 2014

SONY DSC

In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.


Swarming Roles

September 26, 2014

athletes-ball-football-2199-828x550

So far in this series I have covered the values and principles of the swarming methodology. Now let’s talk about roles on swarming teams. In nature, when you look at swarms, flocks and schools there are all kinds of specialization. The nature of the roles can be fixed (i.e. workers and queens) or they can be dynamic (foraging, nursing, etc.). So there are a very broad range of roles that we can find in the animal world. Given those models, there are a few things we can identify as critical to swarming teams:

  • Swarms don’t have Managers, Masters or Owners
  • Swarms have radical diversity
  • Membership is not fixed

There are none of the typical command and control structures to be found on a swarming team. There is no manager. There is no owner. There is no one person making any of the decisions for the group. Swarming doesn’t work without complete equality. That doesn’t mean there can’t be leaders, they are still necessary, but it is only leadership by virtue of their ideas, not any sort of hierarchy or power relationship.

Swarms require diversity. Swarm based decision making is enabled by diversity in the group. Without that diversity, the swarm is likely to have too narrow a perspective and come up with poor answers. This comes from the wisdom of crowds – it doesn’t work without diversity. True diversity is rare in our business. I’m not talking about just race and sex (although more diversity there is necessary), I’m actually talking about a diversity of knowledge and interests. We need people who aren’t software engineers on our teams. Anyone can play: the admin, the fisherman, the librarian, the doctor and the engineer. I think of this as radical diversity.

Finally, the membership of the team doesn’t stay the same. It ebbs and flows with the popularity of the project and the ideas that are being worked on. Anyone can come or go on any given day. They are able to follow their passions where ever they may go. Swarm teams can recruit, sell, and dissipate completely. Nothing about the membership on swarming team is mandatory.

 


Swarming Principles

September 25, 2014

animal-beetle-insect-329-825x550

In an earlier post I introduced a set of values that might be used to guide swarming teams. Values are a good start. They provide very broad guidelines to give teams guidance when making big picture decisions. Principles help give more specific guidance. So here are a few principles that are aimed at guiding teams practicing swarming as a discipline.

Swarming Principles

  • The most important thing I can do is whatever I am most passionate about today
  • Prefer one way broadcast over two way communication
  • Using agreed upon protocols enhances the effectiveness of our communication and decision making

The first principle tells us that we need to be fully engaged in whatever we care most about. That means that people move to where ever they have the most interest. Teams are spontaneously formed dynamic entities that are composed of people who share a common passion.

The second principle tells us that we not only need to communicate, we need to radiate. Information needs to be broadcast exuberantly without reservation or hesitation.

The third principle tells us that one of the foundations for emergent behavior is in simple protocols. We need to be explicit and disciplined in how they are applied and we need to be always seeking new protocols to add to the mix.


Coping with a Fear of Inaccuracy

September 24, 2014

“Even imperfect answers can improve decision making.” – Donald Reinertson

When I read this from Reinertson’s book on flow, I realized that I had found the reason that people have so much trouble with story points. It’s a matter of overcoming their fear of inaccuracy. They are under the misguided belief in the accuracy of using hours or days to estimate work on projects. They’re basically afraid of being wrong (aren’t we all?) and that is the source of a lot of resistance to change. Being wrong sucks. I get that. Nevertheless, I’m wrong a lot.

Fortunately, wrong isn’t always boolean (unless you happen to step in front of a swiftly moving bus). There are shades of wrong. You can be just a little wrong, your aim just a little off, and still be headed in the right direction. Or you can be a lot wrong (the bus). That’s where frequently re-examining your decisions can help you catch the stuff that’s a lot wrong and fix it. What about the stuff that’s a little wrong? Don’t sweat it.

In the software world, a little wrong is still pretty useful. There is a tremendous amount of error and missing information. Compared to that, being slightly wrong isn’t so bad. Being slightly wrong gets you started – at least in mostly the right direction. You’re going to fine tune it anyway, so there’s really no need for decision making precision. That will come later, when you know more.

To me, the ability to overcome our fear of being wrong stems from an all-or-nothing mindset. We can’t allow ourselves to be even a little wrong for fear of failure. As Reinertson rightly points out, there is a time and a place for precision in decision making, but it’s not ALL the time.


How to Slow Down Your Team (and Deliver Faster)

September 23, 2014

Is your team in need of a little improvement? Are they getting a little stale? Are you looking for a way to bring their performance “to the next level?” Well, maybe you should slow it down.

Oh I know, those other consultants will tell you that they can speed up your team. It’s the siren song of the wishful manager, “Speed my team up: faster!” But I’m here to tell you they’ve got it all wrong.

let me ask you this:

When you get a flat tire in your car, do you speed up? No!
If there is a burning smell coming from the oven, do you heat it up? No!
So if you see your teams start to slow down, why on earth would you try to make them go faster?

Let’s face it, when teams slow down there is usually a damn good reason. So rather than speeding up, perhaps it’s time to slow down, pull over, and take a look under the hood.

How do you slow down? Nobody really teaches that. Everybody is so focused on speeding up they seem to have forgotten how to slow down. Here are my top 10 ways to slow down your team (and hopefully address your problem):

  1. Apply a WIP Limit
  2. 1 piece flow
  3. A more rigorous definition of done
  4. Pair programming
  5. Promiscuous programming
  6. Continuous Integration
  7. Continuous Delivery
  8. Acceptance Test Driven Development
  9. Spend more time on impediments
  10. Hack the org

Taking time to implement any one of these things is almost guaranteed to slow you down. That’s a good thing, because your team probably needs to pull over to the side of the metaphorical road and repair a few things.


The Values of a New Methodology: Swarming

September 22, 2014

birds-clouds-cloudy-2002-828x550

Perhaps the time has come for a new methodology. The old methodologies are showing their age as they are gradually incorporated and transformed by the large organizations of the world. There are many who feel that scrum today is but a pale shadow of what it used to be. One mediocre “transformation” after another has watered it down to functional irrelevance. Perhaps it’s inevitable that any method that you develop will eventually lose its vitality once it reaches the mainstream. Sooner or later you always sell out to The Man. That’s OK though, there is always a new young buck waiting to take up the mantle of The Next Great Development Process Breakthrough. What if it was Swarming?

If you were going to work on a team that used swarming as it’s only development process, what would it look like? This hypothetical team wouldn’t use any other processes, not scrum, not kanban, and certainly not waterfall – just swarming. It’s a pretty radical idea. Like many of the other methods, maybe we should start with the values. Values are the bedrock upon which we can build our new method. So what values would a swarming team have? Why don’t we start with these:

  • Passionate Engagement
  • Radical Transparency
  • Natural Rhythms
  • Simple Rules
  • Abundant Alternatives

That seems like a nice set of values, but what does it mean? Why would these be values that a swarming team would hold most essential? Let’s examine them each in turn:

Passionate Engagement – When you look at swarms in nature, from flocks of birds to nests of ants, one thing becomes apparent very quickly: each individual is completely and utterly focused on their task. Bees don’t simply ‘like’ honey. No, honey is much more important than that. To a bee, honey is life and death. Bees don’t ever take a coffee break. Similarly, we want teams that are equally passionate about what they are working on. We want them to believe that it is important, in fact it is absolutely the most important thing that they could be working on. Passion like that is infectious. Other people are attracted to it and soon you will find them working with you side by side just as passionate as you are.

Radical Transparency – Mobilize everyone to look for and manage team threats and opportunities. Share accountability, so that everyone can have the same responsibility for success and failure. All project information should always bet available at a glance on the walls, on dashboards, on my mobile phone, even at home. Access to information needs to be ubiquitous. Anywhere you look it can be found.

Natural Rhythms – A lot of the environments that we work in today don’t honor natural rhythms. Just ask anybody who works swing or night shift. On a swarming team, we want to make sure that we use the cadences of nature where ever possible. Our attention and focus have natural limits, so we can break up the day into smaller chunks. If we are happy and passionate about our work, does it really matter if its a Wednesday or a weekend? The norms of industrial society do not apply to a swarming team. They take their weekend whenever they feel like it.

Simple Rules – Use simple protocols to help enable the highest possible functionality of the team. We need to have simple rules of engagement that enable us to rapidly uncover disagreement and help us to promulgate learning as quickly as possible. Using simple rules requires conscious attention to their maintenance and upkeep. The team needs to keep their rules clear and disciplined in order for them to function well and not decay into disorder. Everyone in the flock needs to have the same signal for turning left.

Abundant Alternatives – Swarms thrive best in complex environments. There need to be an abundance of alternatives to explore, because that’s what swarms are really good at. When swarms find themselves in an environment characterized by scarcity, then they move on to more fertile ground. The same should apply to our teams, if they are working in an ecosystem that is rich with complexity, then they are probably well suited to it. If not, they move on.

These are what I would propose as values for a team using swarming as a development process. These ideas are what support and enable the kind of environment where swarming can happen. The tools are all there, we just need to be bold enough to use them.

 


From Bankruptcy to Abundance

September 21, 2014

blur-flowers-nature-471-827x550

I recently read Rose and Benjamin Zander’s book The Art of Possibility: Transforming Professional and Personal Life and I strongly recommend it. To me it was a book full of stories about mindset management, all primarily set in the wonderful context of music. Much of the book described techniques for moving from a mindset of bankruptcy to a mindset of abundance.

That’s something that I can relate to in my current role. There are times when I find myself trapped in that mindset of bankruptcy. The narrative in my head goes something like this: None of the teams I work with is doing what I hoped they would. We’re not agile enough. We’re not innovative enough. Our culture is all wrong. We can’t get there from here. We suck.

That’s the mindset of bankruptcy talking. There’s never enough. We’re never good enough. It’s a pretty bleak place. I know I’m not alone in living there from time to time. I work with people who come to me with this narrative all the time. What do I tell them?

Well, first of all, I have to check in with myself and see where I’m at. If I’m in the same place as they are, then this conversation isn’t likely to go well. The best I can usually do in that case is to commiserate with them.

But there are times when you are in the place abundance. There is another perspective that allows a much different interpretation for the same set of circumstances. I find that talking with folks from a variety of different backgrounds helps. They’re the ones who will look at me and say, “Wow! You guys are awesome! I hope we can get there one day!” At first my reaction is to deny what they are saying. We aren’t that good. You don’t really get it. But then sooner or later it dawns on me that although we have many things to improve on, we also have managed to achieve amazing things along the way. Things that we now take for granted.

The difference between those two mindsets is that one has room for new opportunity and the other leaves little room for any opportunity at all. I loved their expression when something fails, “How fascinating!” Using a phrase like that suggests curiosity and an openness to exploration. I love it.

I don’t know if I have the kind of temperament that would enable me to live in this mindset full time. But I sure would like to visit it more often and maybe even share the trip with a friend.