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.


Building the Corporate User Interface

September 20, 2014

architecture-blue-sky-building-563-825x550

A while back I did a talk on the subject of “Hacking the Organization”. It was largely inspired by Jim McCarthy’s talk at a local Open Space. Listening to his talk I realized that people who have programming skills AND insight into processes have a unique opportunity to reprogram the organizations that they work in. This reprogramming can be done in a few different fashions:

Changing the processes: Changing the way people work by introducing new methods, practices and protocols

Changing the systems: integrating the systems to make reporting, operations, and other business processes work more smoothly

Blending the processes and the systems: Changing the way people work and the systems that they work with so that they support each other – making people more alive and engaged in the organization. It’s merging the people and the machine to enhance each other.

In fact, in the lean/agile community, we have become very adept at creating relatively high functioning teams using practices that have evolved significantly over the last few decades. Technology has evolved at an even faster rate, with the web, mobile and other technologies creating opportunities for collaboration that never existed just a few short years ago. Modern teams have the opportunity to revolutionize the way people and systems work together.

Those of us who can code and who are interested in improving the process to benefit everyone are the magicians who have a uniquely powerful opportunity to create real change in organizations. That’s not a bad thesis, right?

Well, the more I thought about it, the more I realized that we are not simply trying to change the organization for the pure sake of change. We strive to make the organization more “user friendly”. Our changes aim to make the organization into a place where people can express their work as joy and express passion for what they do. It should enable that sort of engagement, which forms the catalyst for genuine innovation and products that people love.

What would an organization with a good user interface look like? That’s easy:

  • It’s fun to use
  • It has functions we care about and are easy to find
  • We can clearly see how to do what we need to
  • When we take action it is effortless and feels natural
  • It’s responsive, giving users rapid feedback to their actions

What could we do as organizational hackers to achieve these ends? We could introduce ramification to corporate operations. Turn in your timecard promptly and level up! Create electronic systems that make it easier to reward or thank our peers for their work. We could create dashboards that provide visualizations for corporate operations. We can make this information universally available, even omnipresent for everyone in the company from the CEO to the janitor. We can make our work visible so that people can make educated decisions about what the most important work is that they can be doing. All corporate activities should be self serve and provide immediate feedback.

Wouldn’t that be awesome?

We can do that. We don’t have to ask for permission, we can just do it. Link the sales reporting system to a dashboard. Go ahead, do it. Pull in some transaction metrics and do a little simple math to demonstrate the average dollars per transaction. Automate the HR system so that with the press of a single button you can initiate hiring someone – automate all the paperwork. You make the work easier for everyone. You not only save yourself time, but you save time for everyone else who does that work now – from now on! This kind of savings can multiply very quickly.

The coding really isn’t that hard – most back office systems have pretty sophisticated APIs that enable the possibility of this kind integration. All it takes is someone with the will to make it happen. Guess who that is? You.


Hunting for The Elusive Swarming Rule

September 19, 2014

animals-deers-forest-2570-527x350

There are a variety of different ways of going about swarming. There is the ad hoc approach: all hands on deck, everybody find a way to help. Then there are methods are a bit more subtle. You aren’t just dog piling on whatever the problem is. Instead, what you are doing is applying simple rules that allow behavior to emerge. Easy, right?

Not really. The trick is learning what those rules might be. We are looking for simple rules that when followed may reveal emergent patterns that are hard to predict. That very emergent nature makes them hard to discover. You can’t just say, “Hey, I want a simple rule to build the next mobile app.” It just doesn’t work that way. The rule and the emergent behavior often have absolutely no apparent relationship to each other. So how can we find these rules?

One way to do it is to simply look at others and see what they do. Perhaps there are things people do that bring about the behavior. The problem with this approach is that you need to find a source of pretty significant variation in behavior in order to have the best chance of discovering the kind of behavior you are looking for. That leads me to this conclusion: You aren’t going to find it where you work. In fact, you probably aren’t going to find it in your industry (yeah, I’m talking about software). If you are looking for these kind of rules you need to cast your net really wide. Across multiple industries.

If it were me, I’d look into industries like logistics and shipping, I’d look into the printing industry (they are the reigning kings of resource planning). I’d look across different cultures at food vendors in the streets of india, or the techniques that a London cabby uses to remember all of the streets and byways of London. I’d go to emergency call centers, emergency rooms, trucking dispatchers, call centers, anything you can imagine is game. Start with the end state in mind (at least in broad terms) and then work your way down toward the specific building blocks that might get you there. It’s probably a fool’s errand, but at least you are looking for an answer.

Perhaps it can only come from experience?

It reminds me of deer hunting with my father. In the darkest and coldest hours of the early fall morning we would leave our camp to hunt. As we walked out to where ever we were hunting for the day, often we would debate our strategy for the hunt. My Dad always told me that the best strategy was to pick a likely spot and wait for the deer to come to you. If you were patient and sat still, you were much more likely to see something or have a deer come stumbling across your path. He said that’s why old guys were better hunters. They would go out and fall asleep on stump and wake up an hour later to find a monster buck blithely munching away right in front of them. All you have to do is just sit there perfectly quietly. All. Day. Long.

Now to me, as a teenager, this sounded like an excellent recipe for going rather swiftly and completely insane. There we were, out in the hills wandering through what could easily be described as “God’s Country” There was deer habitat everywhere. A herd of deer over every hill. They could be down in the next valley beside the river in the morning. Later in the day they might be high on the ridges bedded down among the rimrocks. The only way to get those deer was to go to where they were. You had to move around and cover some territory.

I spent days roaming the hills and valleys hunting – and finding nothing but dry grass. I would cover 20 miles a day. It turns out that I make a hell of a lot of noise when I’m roaming around. Even when I’m being really sneaky I still make an unholy racket (at least to a deer). They hear you coming a mile off. That’s if they don’t see you silhouetted against the skyline as you cross the ridge. Or if they smell you coming from the next county as you sweat your way up to the rimrocks. It seemed like where ever I went, they were always long gone.

You see each of us was practicing a simple rule. My Dad’s rule: sit still. Mine? Keep moving. So who do did the best? Dad.

Me? I scared the hell out of every deer, fox, mule, turkey and woodchuck in a 20 mile radius. On the bright side, I never spent a dime on bullets.

I eventually learned which rule worked best, but it took me time and experience to get there.


Killing 7 Impediments in One Blow

September 18, 2014

Have you heard the story of the Brave Little Tailor? Here’s a refresher:

So one day this little guy kills 7 flies with one mighty blow. He crafts for himself a belt with “7 in One Blow” sewn into it. He then proceeds through various feats of cleverness to intimidate or subdue giants, soldiers, kings and princesses. Each one, in their own ignorance, misinterpreting what “7 in One Blow” actually refers to. It’s a classic for a number of reasons:

  1. It’s a story about mis-communication: Not one single adversary has the wit to ask just what he means by killing “7 in one blow”
  2. It’s also a story about using one’s cleverness to achieve great things. You have to love the ingenuity of the little guy as he makes his way adroitly past each obstacle.
  3. It’s a story about blowing things way out of proportion. Each of the tailor’s adversaries manages to magnify the capabilities of the tailor to extraordinary, even supernatural levels.

I’m thinking I might have to get a belt like that and wear it around the office. A nice pair of kahkis, a button down shirt, and a big belt with the words, “7 in One Blow”. Given how prone we all tend to be to each of the foibles above, I’m sure it would be a riot.
A QA guy might see my belt and say, “Wow! He killed 7 bugs in one blow!”
Maybe a project manager might see it and think, “This guy is so good he finished 7 projects all at once!” Or maybe the HR rep says, “Did he really fire 7 people in one day?” Or the Scrum Master who thinks, “That’s a lot of impediments to clear out at once!”
The point is that we make up these stories all the time. We have stories in our heads about our team mates, “Did you hear about Joe?” our managers, and their managers. Sometimes it seems as though we all have these distorted visions of each other. And perhaps we do. We need to get better at questioning those stories. We need to cultivate more of a sense of curiosity about the incomplete knowledge that we have of each other. That belt would be my reminder. I might have to buy one for each member of my team.
Of course the other thing that the belt can remind us of, is to use our own innate cleverness to help get what we need. When we are wrestling with the corporate challenges, we all too often tend to try and brute force our problems and obstacles. We need to be a bit more like the Little Tailor and manipulate the world around us with some cleverness. We all have it to one degree or another, and Lord knows we need all the cleverness we can get. Good work is full of challenges and you don’t want to take them all head on or you will end up like an NFL linebacker – brain damaged. Instead, we need to approach some things with subtlety. There is just as much value in not being in the path of a problem as there is in tackling things head on. Like the Tailor, we need to recruit others to achieve our objectives.
Finally, we really must stop blowing things out of proportion. Nobody cares about our methodology. You want to know what my favorite kind of pairing is? Lunch! We need to lighten up a bit. Working your way through the dark corporate forest, you can either play with what ever it brings and gracefully dodge the risks, or…you can get stepped on.


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.