Going Viral

August 15, 2016


“An inefficient virus kills its host. A clever virus stays with it.” -James Lovelock

I was talking with a friend the other day about that magical time you experience when you first start with a company. You know, it’s that honeymoon period where you feel like everything you do is effective. People are nice to you, things are easy, the company feels like someplace you can make a difference. You are on top of the world. Things just work.

Of course it doesn’t last. After a while, for some reason it gets harder and harder to create change – to do something new. People don’t think those ideas sound all that novel anymore. Getting things done starts to feel slow and laborious. Soon you are just another one of the gang. Part of the status quo.

If you are a consultant, perhaps it’s time to declare victory and move on. After all, the average consulting contract isn’t that long. Perhaps only 6 months. You introduce some change and then leave before things get too tough. That’s a good thing too, because before long, they’re on to you.

So what is happening here? I have a theory. It’s a little whacky, but hear me out: I think that a workplace is a living system and that when a new person joins it’s kind of like introducing a virus. The system, the corporate entity, doesn’t know how to handle it. It doesn’t recognize it. It doesn’t know how to react. So the virus…er…person, simply by their very existence, provokes a reaction in the system. Of course living systems adapt. Slowly sometimes, but they do adapt. After six months or so, you are no longer an unknown virus. The antibodies in the system have learned to react to your novel behavior. You are no longer novel to the system. You are part of the system. That is good and bad. It’s not all bad being part of the system. But you may find that its now really hard to get the same level of response to ideas for change. After all, they’ve heard it before. You are now a known quantity.

So what do you do? Move on? What if you aren’t a consultant? Well we know the system reacts to a novel inputs. You are no longer novel, so…you have to make yourself into something novel if you expect to create a similar impact to when you first joined. You must make yourself into something new and different that the system doesn’t expect.

You must change.

If you want to change the system you need to change yourself. Otherwise the system will recognize you and will fail to react. You need to change your behavior, so that the system has to adapt to your new behavior. You don’t ask others to change. You change yourself and the system will change to adapt to you.

Maybe its time to give the organization a virus.

The Agile Gymnasium

January 12, 2016


I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on the butt and tell you to “go be awesome!” You can record your exercise sessions on this little card over here…

That’s pretty much it.

As you might imagine, the success rate with that sort of system is fairly low. A lot of people never come back (although many continue to pay their monthly dues). Those who do come back typically have no idea what modern exercise programming looks like and simply go through the motions: they ride the stair master, do a few sit-ups, and maybe do some curls. That sort of exercise has some marginal utility – you get some small amount of aerobic benefit, but it’s a far cry from exercising a meaningful percentage of most people’s potential.

Most people stop there, but there are a few who have a more ambitious goal in mind. They may be trying to improve their tennis game with better conditioning. They may be looking to build massive pectoral muscles (like most teenage boys). They may be trying to maintain their conditioning in the off season of their sport, perhaps like cycling in the winter. In other words, the purpose of their exercise is to improve their performance in some sort of real world scenario.

I’d like to pause for a moment here. I was listening to a discussion with some folks who owned their own gym and they had an interesting model. It had three tiers to it:

  1. Gym Work: Work in the gym is not like the real world at all. It is where you go to prepare for the real world. The gym is a safe place to work to the point of failure (that’s important) and to learn.
  2. Expeditions: Expeditions are adventures in the real world that are guided by a coach. So it is real world experience, but with someone there to guide you and help if you fail.
  3. The Real World: This is where it all comes together. Ultimately, this is where the training in the Gym and the experience in the expeditions pays off in terms of improved performance.

As a model for the role of training for high performance, I thought this made a lot of sense. There was one more thing that they added to this: They were capturing data on the entire group’s performance and analyzing it in order to provide better training for individuals in the future!

So when you join the gym, you use a training program that is similar to what others in the gym are using. Your performance of that program is measured and metrics across the entire population training in the gym are measured. Then experimental changes are made to the training program and their benefit (or lack thereof) is measured across the group. Gradually their training program improves over time. But the training isn’t just tested in the gym. They also track the performance of their members when they go on expeditions. This measures the effectiveness of their training program in the real world.

OK, enough about this gym. What if we could use the same metaphor for the way we train our development teams? Training would be a weekly thing. Something where you go in for training on a periodic basis to firm up your skills. There might be repetitions (pair programming, mob programming, etc.) and there might be coaching (coaching circles, etc.) and there might be someone who is coordinating the training program and measuring the performance across the entire group of trainees.

There could be expeditions from time to time. Hackathons where people get to try out what they have learned in the gym out in the real world. You know: build a real project, maybe deliver something over a weekend. Test out your mastery of your skills in the real world – with a coach there if you need it.

Then there is game day – the real world. You take what you have learned and join a team. You get to flex your massive coding and collaboration muscles and help build something challenging – something amazing. What a great model for development! But I’m not done yet…

Let’s take this model, we’ll call it the “gymnasium model”, and apply it to something like Certified Scrum Master Training. Right now, there is two days of class time and exercises and then they slap the CSM on you and send the newly minted CSM out into the world. It’s a hauntingly similar scenario to the average person’s experience at the Gym: welcome to scrum, now “go be awesome!” Maybe you do a few sprints, do a few standups and off you go. That’s about as agile as most people get. Seriously. You get some marginal benefit, but that’s about it. It could be so much more.

But what if we did things differently? What if instead of signing up for a 2 day class, you were to join an Agile gym. Maybe twice each week you go into the gym to “work out”. A coach would give you a workout, perhaps something like this:

1. Dysfunctional Standup
2. 3 Reps in the coaching dojo
3. 2 Sets of mob programming
4. 2 reps of code katas
5. 1 cool down with a retrospective

That’s just a sample workout. The Agile Gym is a safe place to try out new skills and to push ourselves. The coach would be responsible for measuring the effectiveness of the workout and modifying it over time. Experimenting with new techniques and combinations of methods and evaluating the outcomes. Of course, this is just training in the gym. From time to time we are going to need to test our our competence in the real world. The coach would provide some guided expeditions (perhaps twice a month). For example:

1. Participating in a Hackathon
2. Participating in a Startup Weekend
3. Participating in a Maker Fair

These are events in the real world that are important places to evaluate the effectiveness of our training in the gym. If our coding skills have improved, then we should do well at these events and build confidence in our ability to use our newfound skills in the real world. Speaking of the real world, hopefully now we would see the agile behaviors that we have practiced being manifested in useful ways in the actual projects that we are running from day to day. Our collaboration skills should be tight, our planning impeccable, our retrospectives revealing. And if we find any weak areas, then it is back to the gym for more training.

In this model, the gym is always open. You actually practice your skills and see improvement. What an amazing way to learn about agile!

It’s not a bad model really. Actually, it’s a really darn good one. Who wants to start a gym?

Roles Considered Harmful

December 27, 2014


“Man’s role is uncertain, undefined, and perhaps unnecessary.” – Margaret Mead

So there I was talking to a team that was split across two locations. There was the usual set of complaints that you might expect from a scenario where a team is divided across geophysical locations: miscommunication, delay, misunderstandings, etc.

In this case, the QA folks happened to be in one location and the development folks in another. As we talked through some of these issues, I couldn’t help but point out that the root cause – that separation between the two groups, could easily be solved: just split into two teams by location. Of course, that would leave us with a team of developers without any QA. Working with dev only teams doesn’t bother me (been there, done that, got the merit badge), but it was a different question altogether for this team member I was talking to. For them, the entire idea of removing a role from the team was completely untenable.

The first objection was, “If we don’t have QA on the team, who will keep developers under control? ”

Whoa! What? Back up the truck!

Who will keep the developers under control? Seriously?

At this point, I shifted gears and started asking questions about the team roles. I was concerned with this QA role that ‘controls’ cowboy developers. Why do we need to ‘control’ anybody in the first place? How exactly do you exert this control? What would happen if you didn’t control them?

It was quite an eye opening conversation. The more I looked at it, the more I realized that the roles of QA and developer had an astonishing amount of baggage associated with them. The QA role is the only role that can test code. The developer role is the only one that can write code. One can’t possibly be trusted to do the other’s job. It would be a lapse of ethical integrity!

Oh my God! Do people hear themselves when they utter this tripe?

Apparently not. No wonder we avoid creating roles or minimize them in some processes (i.e. Scrum, or better yet, swarming). It’s awfully easy to come to the conclusion that roles carry as much dysfunction as they do benefit for a team. They invite definition and structure, but in doing so they also create walls and barriers to effectiveness and efficiency.

As soon as you create a role that is entirely responsible for quality (or anything else for that matter), you do three things:

  1. You define their job, and by doing so, you make a distinction between “the things that I do” and “the things that you do”. It starts to define what you can and can’t do. That’s useful if you are trying to subdivide work. But not so useful if you are trying to create dynamic, flexible teams that adapt themselves to unanticipated changes. You know…Agile?
  2. You create an in-group and an out-group. In psychological terms, you are creating an “us” vs. “them” distinction which almost inevitably leads to conflict.
  3. With these foundations, our thinking is constrained about how the process of value creation should work. The distinctions that we hold in our heads are what we use in order to create the boundaries of our processes. We find these boundaries between Dev and QA, sales and product, managers and teams, and yes, even Scrum Masters and coaches. They’re everywhere.

Obviously, roles can have profound impacts on how people think about their relationship with the people they work together with. So what can we do about it?

As I asked further questions, it became apparent to me where I might go. Talking to the team would be a complete waste of time. They didn’t define the roles. They were hired for the roles that their managers defined. So step one is talking to the managers.

Of course managers are people too. They are only trying to fit in the hierarchy and culture of the company. Eliminating roles would be a very threatening thing to a manager whose whole career has been based on making and supporting such roles. So we can’t expect a whole lot of help from there either.
Of course you could just show them…

There are some talented developers I know, coaches really, who are very good at working side by side with teams and demonstrating by example how to blur the distinctions between roles. You can even do it yourself with other managers. Build those relationships. Help them out. Show them how it feels to have someone else help out that doesn’t have the same role as they do.

In the end, I think it comes down to people being able to experience what not having hard defined roles is like. You can’t talk them into it. You just need to roll up your sleeves and demonstrate with them.

“I’m not playing a role. I’m being myself, whatever the hell that is.” – Bea Arthur

Scrum Masters Considered Harmful, Paul Hodgetts
Us and Them: The Science of Identity, David Berreby

Superman Syndrome

October 19, 2014


There you are, in your tenth meeting of the day. You haven’t even had lunch, just one meeting after another. You’d skip the meetings, but you are required and half the meetings are yours anyway. You finish the day without having accomplished one single thing (except a bunch of meetings). Your todo list has only grown longer and the only time remaining is after hours (because nobody can schedule a meeting then). If this is you, then you might have superman syndrome.

It’s pretty common in software development. The nicest people get sucked into it (no, really, they’re too damn nice). You are competent, eager to please, and really can’t say no. It’s a great ego boost – you are needed! Well, I’ve got some bad news: you’ve got Superman Syndrome.

That’s right, you got it bad. Now sit down. This is where we get to play product owner. Product owner of your life. Write down that list of all thing things you have to do. Go ahead, put it in priority order. That’s right, it’s not easy. Product ownership is a bitch. Good, now cancel all your meetings. I know it hurts. Do it anyway. Send some polite excuse about being behind in your work (because it’s true) and you’ll catch up with them later (maybe never).

Now take that one thing at the top of the list (it is just one thing, right?) and get to work. Here’s the new rule, you don’t get to work on anything else until that thing is done. Take comfort in the fact that you are working on the most important thing that you could be working on. No one can fault you for that. You see what we are doing is limiting your work in progress (WIP). Limiting the amount of work you take on is like kryptonite to Superman Syndrome.

While we’re at it, let’s just turn outlook off. Yeah, completely off. You have a WIP limit here too: twice a day. Once before lunch and once before you go home. That’s it. That’s all.

While we are having so much fun setting WIP limits, we might as well put a WIP limit on your meetings. That’s right, nobody can reasonably expect you to do your job AND attend every single meeting: so don’t. Set a reasonable limit (no more than 2 hours of meetings/day). That way you are available if the issue is REALLY important, but otherwise, they’ll have to just get along without you. Again, polite apologies all around.

Try that on for a while and see how that works for you. Come back and chat with me when you think you are ready to change your WIP limits.

Now to take my own advice…wish me luck.

Yours truly,

Keeping It In the Family

October 16, 2014


I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter.

You won’t find me standing around with the kids doing a daily standup. There is no weekly planning meeting on my family calendar. And the only retrospective that I do is after getting caught leaving the toilet seat up (“Doh!”). Nope, I’ve got to be honest, my household isn’t very agile.

You might ask, “Why not?”

Dang, that’s a really good question. I’m not sure that I have a good answer. Maybe I just want to leave all that stuff at work. But if that were the case, then why do I go home and write this blog? No, that’s not it. Maybe there really has been no structure modelled in my family life before. In fact, the very idea of doing that kind of “work” at home makes me cringe a little bit. I guess I feel like we have things under control. Maybe I don’t even want that control. It’s really hard to say.

I think there is value in sharing the practical time management techniques that I use at work with my kids. I didn’t hesitate to introduce them to pomodoros when my daughter was struggling to stay focused on her homework. It felt really good to be able to introduce her to a tool that would help her be successful. She loves pomodoros! The kids like all the fooling around that I do with self-experiments around the house (“Hey! Look at Daddy!”). They always want to know what kind of nutty thing Dad is doing this week.

However, I’ve never felt a compelling need to have any kind of formal family meeting at all. Call me a bit waterfall. I guess when it comes to my family I only want to give them the techniques that they need for the problems they have. I don’t want to burden them with a framework. Got a problem with focus? Use pomodoros. Does the problem seem too large? Break it down into stories. No progress? Try iterating.

When I can provide a helpful technique that solves their problems (agile or not), I feel like Superman. Seriously folks, there is no better feeling in the world. There is no preaching. I don’t lecture them on the perils of waterfall. To my kids a waterfall is something you ride a log down at Disneyland. I aim to keep it that way as long as possible.

I guess, in retrospect it’s not such a bad approach for introducing agile practices for anyone, regardless of whether they are in your family or not. In fact, why would you treat a team any differently than your family? Aren’t they just that – your extended family? Can we use this to inform how we approach introducing Agile Practices to our teams?

Maybe we just introduce them to the tools they need to solve the problem that they have in the moment. Perhaps that’s how we start. That’s how we demonstrate value and earn trust. Not by dumping some framework they must comply with on their heads.

Hmmm….I think I’ve been doing it wrong.

Introduce agile practices to your team like you would to your family. Give them only what they need and let them figure out the rest.


October 16, 2014

As some of you may know, I’m building a boat in my brother’s garage. We had a big milestone the other day: we finished painting the bottom and rolled the boat over to finish the topsides. From a distance it looks great!

Up close is another story though. Up close you can find ripples in the paint from where the fiberglass wasn’t sufficiently well sanded. There are other places where you can see fine lines in the paint due to underlying patterns in the filler compound. Add to that the fact that the paint has rough areas where the roller left a pattern. And don’t even get me started about that flat spot.

I see all of these imperfections and more. It’s pretty rough.
I’ve worked with teams like that too. From a distance, everything looks great. You are hitting your milestones and everyone is pleased.

But get close and you find all sorts of flaws. They’re not using story points. They won’t keep their burn down chart up to date. They don’t even know what an acceptance test is. They’re pretty rough. Maybe we should just keep them in the garage…
But around this time, along comes my brother. He takes one look at the boat and says, “Damn! That’s beautiful!” So I point out a flaw. He waves it off and says, “The only boat without scrapes and dents is in the showroom. This boat is going to sail!” Not to be dissuaded, I point out another flaw. He looks at me and says, “Will it float?”
My answer, “Yes.”
“OK then. Let’s get this thing in the water.”

And so we go back to work, and somehow it is OK. I stop worrying and focus on what remains to be done.
Sometimes someone visits the office. Someone I really respect and admire. I show them around and they say, “Wow, what a great team!” So I walk them over to the story board and point out that it’s out of date. They look at me and say, “That’s cool. Not many people even use physical dashboards.” I tell them that the team doesn’t use story points. They look at me and say, “Does the team deliver?”
My answer, “Yes.”
“OK then. Let’s sling some code.”
And so I’m reminded not to be such a damn perfectionist.
Love your boat.
Love your team.

Building Glass Houses: Creating the Transparent Organization

October 11, 2014


Visual management occurs at many levels. There is personal transparency: the ability for people to see what you are working on within the team. Then there is team transparency: the ability for stakeholders and other teams to see what the team is working on. Finally, there is organizational transparency: the ability for people within and outside the organization to see what the organization is working on. Ideally, we have all three levels of transparency fully developed in an Agile organization.

Individual transparency consists of the ways in which we communicate the state of our work to the team. We can use both active and passive mechanisms to achieve this. Active mechanisms are things like using one-way broadcast like yammer, or just shouting out when you need help, achieve victory, or otherwise want to share with the team. Then there is two-way broadcast like the status in the daily standup, one-on-one communication, working meetings like the planning and demo. Passive mechanisms include updating things like task boards, wiki pages, and status reports. All of this information is primarily directed at the team.

At the team level there are active and passive mechanisms for communication. There are burn down charts, task boards, calendars, which are all passive. Then there is the active communication that takes place at the scrum of scrums and other larger forums where multiple teams and stakeholders meet. I’ve often seen teams struggle to get information out at this level. They tend to do really well at the individual level, but at the team level it is not uncommon to find that teams aren’t getting enough information out beyond their own boundaries.

Finally at the organizational level there are active and passive mechanisms for communication as well. There are passive communication mechanisms like annual reports, company web pages, intranets, and billboards in the coffee room. There is also active communication at company meetings, and…often not much else. This is an area where as Agilists we need the most improvement. It seems as though the communication demands get more challenging the higher up the organization that you go.