Building Up and Tearing Down

Recently I put on a public Leading SAFe training. This wasn’t your typical training, however. In collaboration with Ron Quartel, we tacked on an extra day to discuss FAST Agile. Now if SAFe is an example of a scaling framework, FAST Agile is perhaps a good example of what you might call a de-scaling framework. FAST uses an open space style of organization to provide only the most bare bones structure and guidance. It’s really quite elegant in its simplicity. 

Ron and I had both been inspired by the ideas of mix-ins – processes and practices that we can mix and match together. So, it was with that in mind that we thought putting on a combined training class would be interesting. First teach SAFe, then turn around and teach a competing framework. Then compare and contrast. Well, as it turns out, the combination was quite brilliant.

As I taught the two days of Leading SAFe training, the class built up the framework from teams, to programs, to solutions, to portfolios. Learning the roles and processes of each. By the end of the second day, I was exhausted but happy (as usual). Then Ron stepped in and proceeded to teach FAST Agile on day 3. In essence, he took everything I had taught them and tore it all down. The focus was on simplicity and self-organization. The class was totally into it – questions flew fast and furious. Everyone was fully engaged. 

The contrast between the two frameworks was stark, and it raised many questions for both Ron and I. You see, I wasn’t there to sell anyone on SAFe. Don’t get me wrong, I like the framework, and I enjoy the training a lot, but I don’t give a damn whether or not you decide to adopt it. What I really care about is that you make an informed decision based on what I hope is the deepest possible understanding of the options. If you understand the values, principles and practices deeply, then you will choose to implement what is best for you and your organization. There is a tremendous amount of nuance and subtlety to the art of organizational change (that’s probably why I like it so much), so I believe that the ability to not only adopt ideas, but also to be critical of them is important. 

The act of building up the framework and subsequently tearing it down again felt like a very powerful learning experience. It went beyond rote learning. Not only do we ask, “Why would you adopt this?” We also ask, “Why wouldn’t you adopt this?” That requires us to understand the ideas from different perspectives. People stayed after class each day debating the ideas for over an hour each evening. That’s when you know you’ve really got them thinking. I’m looking forward to doing it again.

My Personal Andon Cord

Have you heard of an Andon Cord? On the assembly line it’s that cord you yank on to stop the entire line when a problem is found. The idea is to stop everything until the problem you encountered is fully understood and fixed. That way we take the time to improve the function of the assembly line so that those sorts of problems never slow us down again. It’s a little example of that “slowing down to go faster” that those crusty old software curmudgeons blather on about.

But who listens to those old cranks anyway?

I was thinking about a recent Product Owner training I was running where I was told that the product owners didn’t actually sit anywhere near the team (that was assuming they had a product owner to begin with, but I digress). It turns out that the product owner for a given team was very likely located in another building or even perhaps another state or country altogether! This kind of colocation issue is fundamental to improving a teams performance. Address it and you will see meaningful improvement quite quickly. Fail to address it and you will be wrestling with the side effects and consequences forever without dealing with the underlying problem. 

So what did I do? Well, this was just the start of a two day training, so I had at least a day and a half more of training that I was expected to deliver. So I tossed that issue on the mountain of other issues that I was uncovering and moved on. Trainers gotta train, kids gotta eat. I raised concerns, told the right people, and moved on. Everyone kept moving.

Now in hindsight, I’m not sure if I should be proud of dismissing something that important. However, I know it happens all the time. But it makes me wonder, is there an issue sufficiently important that I would call the whole class to a stop in order to address it? What would cause me to stop the line as a trainer? Where is my trainer Andon cord?

If a fist fight broke out in class, I’d certainly stop the class. So there’s that. But what else? If someone was crying, I’d stop the class. If I found out someone was being hurt, I’d stop the class. But if I found out they were doing something stupid…I wouldn’t necessarily stop the class. I might pause long enough to mention that I wouldn’t recommend doing that. Maybe I’d hand them a Darwin Award (oh, now there’s an idea…). But stop the class? No.

Let’s look at that example of the product owners in a different location than the team. Colocation of product owners or customers is pretty fundamental. You would stop the line if you found out that the car’s tires are missing. If someone told you,”It’s OK, we keep them in another building.” You would probably be well justified in insisting that the tires get brought in pronto. There’s not much point in leaving silliness like that alone. So I’m asking myself, if the customer has paid me a few thousand dollars for the training, but instead of delivering the training, I stop the training to focus on that one problem…what would happen? Fixing that problem could probably mean a huge return on investment for them. Something far beyond the paltry amount they have spent on the training. It’s food for thought. 

On the other hand, typically these types of organizations are not in a place where they are accepting or tolerant of radical change. Usually few if any folks in the room are actually empowered to do anything to change the situation. Furthermore, even the folks who hired me may not have that power. You have to have a lot of credibility in an organization before you can even start talking about that sort of change. Credibility takes time, and that’s something that most trainers don’t have. You’re in, you do the training, and you’re gone. Poof of smoke. Vanished.

So in the big picture it probably depends on your context. If you are just in for a quick one-time training, then you really don’t have the credibility to stop and attack problems like this. On the other hand, if this is part of a long term engagement, then there is the real possibility of being able to deal with problems like this in real time. To be able to pull your Andon cord and stop the line. What a marvelous thought.

One Step Back, Two Steps Forward

I was confronted with a bit of a dilemma the other day. I was working out and reaching the limits of what I could lift. I could tell, because as I prepared for each lift, I was a little bit scared. I didn’t really know if I could do it or not. Then I would perform the lift, and barely, just barely, make it. It wasn’t pretty, but I did it. Afterward, as I lay on the floor hyperventilating, I had a lot of conflicting thoughts running through my mind. I’ve been working toward a lifting goal for a long time now. I’m getting tantalizingly close. I can’t stop now. I’m not getting any younger. Time is short. If I keep this up I’m going to seriously injure myself. This is really painful. It’s no fun being terrified of the weight. I can’t stop now. I don’t know if I can do it again. Dear God, I hurt.

I don’t want to make too much out of it, but suffice it to say that I was seriously conflicted. I’ve literally invested years in getting my lifts to where they are today. It’s hard to step back with that kind of investment behind me. On the other hand, that’s a lot of investment to waste by injuring myself. So it’s a real dilemma, especially when I feel like I’m so tantalizingly close to my goals. Part of me is screaming, you’re almost there! And the other part is begging, pleading to back off.

Where else do we see this kind of goal oriented struggle? Developing and releasing a product? Getting a promotion? Saving up for something big like a new house? We see it anywhere there is a large investment over time toward a meaningful goal. The danger is that if we over reach, we may lose the opportunity entirely.

In my case, I decided that the prudent thing to do would be to take a few steps back. So I rolled back the weights and the intensity a few notches and started over again. I was back to lifting weights that I had been lifting nearly 3 months earlier. Three months is a lot of time to lose! However, I noticed a few things:

1. It was so easy! I felt my confidence come roaring back.
2. I was so much stronger than I had been. Where before it had been a challenge, now it was second nature.
3. I was performing cleanly and confidently, not scrabbling to survive the experience.
4. I no longer feared injury.

The road has gotten a little longer, but now each step I take feels more confident and certain. This is where having a coach can make a really big difference. They can act as that voice of reason that will help to steer you through these decision points. They act as a relatively unbiased party that is invested in your success. They need to know the domain really well – I would never take a coach who didn’t know about weightlifting. They need to have an experimental mindset: everybody is different, things that work for one customer won’t work for another. And they need to be able to firmly give constructive advice for change, even when the customer really, really, really, doesn’t want to hear it. Perhaps then most of all.

I don’t have a coach right now (perhaps I should take my own advice). I know that if a coach had told me that I needed to go backward three months in my training, I would have resisted. That would be crazy talk. And yet here I am. I think I now appreciate it a little bit more when I work with managers. I often recommend that they do things that would appear to be backward steps. For example, I might recommend pair programming for their teams. I often get the horrified reaction, “You mean twice the number of people doing half the work?” Uh, yes. That’s a giant step backward. Especially when you feel as though your teams are performing at what may be the best they have ever done. I think I get it now. That’s not an easy sell.

But a good coach knows that a few steps backward can lead to later leaps forward. A good coach is invested in getting you there. A good coach knows you will build confidence and capability, and that has value too. And a good coach won’t back down when they know it will help you reach your goals.

Oh, and if you are looking for a good coach, I’m available.

The Trial of Empathy

I’ve been working with some managers lately who struggle with a variety of challenges. Like many folks, when faced with a challenge they tend to dig in their heels rather than seek change. Trying to advocate change to folks in this situation is hard. Nobody wants to hear about creative alternatives. They have big problems to solve and are feeling tremendous pressure. The existing processes are often making their lives even worse. People aren’t collaborating, work is constantly in progress and never done. It really sucks. You’d think that if you walked in the door and offered a viable way to relieve the pain, you’d be treated like a hero.

But that’s just not the case.

It’s much more likely that you will be summarily kicked out of the office. Why is that? There you are with the answer to their problems, why won’t anybody listen? First, they want help. The best way to accomplish that is to dive right in and pick up a shovel. Of course that’s really unpleasant. But they need to understand that you grasp the current state of affairs deeply, and the only way I know of to do that is to ride the dragon with them. It’s terrifying, but you need to earn their trust first. Once you have that, you can begin to show them the alternatives in small ways. You model the behavior that you want to bring. And then you can both evaluate the results – as equals. You both look at what you have done and ask the question, “Is this good enough?” If the answer is yes, then you can bet that they are in.

But there is a catch – You have to join them in the soup. And that is not very much fun. You have to share the burden and experience the same sort of pain that they do. Perhaps this is why I often find myself shying away from these situations. I really don’t want to feel the pain (if I’m honest anyhow). I’m not really interested in feeling that kind of pressure. It sucks and everyone knows it. But sometimes it’s necessary. I see coaches sometimes who are playing the sidelines but not getting into the game. They are content to play a prescriptive role – why? Because getting in the game hurts.

Sometimes that’s why empathy is hard.

Eliminate Fear, Create Safety

Often silos within an organization are based on fear. There can be many different justifications for such fear. For example, the fear is expressed as territoriality, “This is my turf, no outsiders allowed.” You see this with teams who will not allow others access to whatever it is that they control. They use all sorts of justifications to support this (compliance, regulations, etc.), those reasons are often just smoke screens for the fact that they are afraid of opening up and letting others in. Outsiders are a threat. If you let someone in they get to see how you work, and maybe they will recognize areas of weakness (change, improvement). Sometimes they do not fear the outsiders as much as they fear their own management. This is typically manifested as a pattern of C.Y.A. (Cover Your A**) behavior. When this happens, you find resistance to letting others in because it may expose them to criticism by others.

How does fear manifest itself? If you are trying to talk to someone in another group and they start whispering to you so they can’t be overheard by others, that should be considered to be a strong indicator of a culture of fear. This is someone who feels that they cannot say certain things without some sort of punishment. On the other hand, the fact that they are willing to take a risk and share with you at all is a sign of trust on their part – trust in you.

What can we do about it?

First, we need to acknowledge that there probably is not much we can change in their environment. Whatever is causing the issues with fear hopefully has little to do with you. That means that all you can do is make sure that you do not aggravate the situation further when you are in their domain. The last thing they need to do is fear you too. That means that you have to be willing to deal with them in a fashion where they do not feel threatened. If they think you are going to escalate issues to their management, then you are not going to have a chance to build any trust with them. On the other hand, if they believe that they can bring difficult issues to you and that you will do everything you can to help them out, and then you have a shot to build a better relationship.

How can we create safety?

Ultimately, what we are after is the kind of relationship with the other group that can be open an honest. That does not mean everybody is happy all the time. Quite to the contrary, a healthy relationship, a safe relationship is one where the two groups can get upset with each other and express grievances. Signs of safety?

• Disagreement
• Emotion
• Reassurance
• Laughter
• Good-natured teasing

Some of these things may seem contradictory. Emotion, especially strong emotion can seem very threatening. Disagreement and conflict can also be seen as a threat. However, in an environment where people feel safe, these things are part of healthy interaction. You need someplace where people can feel passionate (strong emotions). You need someplace where people can take a contrary position and debate alternatives (disagreement).

Trapped in Amber

Have you ever seen those blobs of amber with some hapless insect trapped inside? There it is, frozen in time, forever locked in a golden prison in whatever position it happened to be in at the fatal moment. That really must suck.

Seriously though, I think that in some metaphorical way I have some idea how that insect must have felt. One minute able to move freely, even to fly, and the next, unable to move a muscle or flex a wing. Often times I join organizations as an outsider. I’m there to provide help in some small way. On my good days I might even be able to help bring about meaningful change. It’s on those days that I feel like I can fly. I’m able to move through the organizational matrix freely, perhaps even dance a little along the way. 

So, with the usual qualifications, I consider myself to be reasonably adept at moving through the organization. However, I recently found myself in a very different situation. It was in a simulation. An exercise as part of a recent training. I was supposed to be an executive in a large company. I work with these guys all the time. I knew the rules of the game before it even started. I was going to crush this.

So, we started the simulation and I dove into it with enthusiasm.  I played by the rules and tried to do the right thing. As I was doing this, I could hear a little voice in my head saying, “OK, big guy, start dancing.” But for some reason I couldn’t. I was working within the system. I was stuck. Frozen.

It really did suck. 

I think this happens in a lot of organizations to a lot of people. You’re bright, creative, and motivated. Yet, somehow the rules of the system are configured such that you don’t feel like you have the power or ability to make any big moves. Everything feels constrained. Trapped in amber. There are many things that can contribute to this. Perhaps a rigid organizational hierarchy. Maybe a risk averse culture that doesn’t support new ideas. Or even explicit processes and rules that make any sort of change difficult. It might even be work overload. It could be one or many of these factors that come into play. All of them can lead to a state of ineffectiveness. An inability to move.

So how do you get out of this trap? Assuming you don’t want to end up some fossilized specimen, how do you escape these constraints?

Here are a few thoughts:

Wait– That’s right, just wait. Sometimes when we face something new, when the pressure is really high, we tend to short circuit a bit as we come to understand the new challenge. Once we have oriented ourselves, we find our confidence and our ability to move returns. This is what happened to me in that simulation. Once I had a little time to absorb the new stimuli, I found I was able to move again with confidence.

Pause and Take a Break – Sometimes we get so absorbed in the day-to-day that we just need a break. Removing yourself for just a bit from the pressure can give you the break you need to start thinking clearly again and see a way to move forward.

Leave– You may find that you simply have yourself in a situation where there is no winning. There is no meaningful solution. In which case, it may be time to move on. It’s unfortunate, but it happens.

Peer Support– It’s very likely that if you feel unable to move, your peers probably feel the same way. If so, perhaps it’s time to talk to each other. Maybe working together, providing support to one another, you can help each other out.

Mentor or Coach– Sometimes an outside perspective is what you need. Someone who has been there and understands what it’s like but isn’t living under that pressure in the moment. Someone who can provide guidance to help you get moving again.

Interested in Learning More?

I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com

Painting The Spots

If you do a little reading about Scrum one of the first things that you learn are the 5 basic values of Scrum:

• Courage
• Focus
• Respect
• Committment
• Openness

I’d like to examine one of those values that I watched a team wrestle with recently: commitment. These were really great folks. They were bright, energetic, friendly and passionate about the work they were doing. Within the team they took a lot of pride in their ability to “be agile.” They seemed to be doing a lot of good stuff.

However, I was hearing some disconcerting things from other parts of the organization. Other teams characterized this team as flakey. Managers expressed frustration that they didn’t deliver. I wasn’t sure what the story really was. Was it a cultural thing? Was it petty jealousy at work? I really had no idea.

An opportunity came along to do a little coaching with the team in question, so I was eager to find out more. Here’s what I found:

• Optimism at the start: So the team said that they were prone to overcommitting to the amount of work they could handle in a sprint. During sprint planning, they would realize the balance of the work was unequal and that there would be team members left idle. So they would take on more “overflow” work to make sure that everyone on the team has something to do during the sprint. It’s great that they were aware of this problem. This pattern of behavior was leading the team to consistently overload their sprints with more work than they could achieve. The team told me that their typical velocity was 27-29 points per sprint. When I asked them what they had committed to in the last sprint, the answer was: 44 points. When I pointed out the obvious discrepancy, they admitted that they had overflow work from the previous sprint that they felt they had to get done. So then I asked them if they were going to deliver on all 44 points. And the survey says: No.
  The good news? This injury was self-inflicted. The bad news? It didn’t sound like they were entirely convinced they had a serious problem. A pattern of failing to reliably deliver sprint objectives can lead to a crisis of trust with a team’s stakeholders. The stakeholders start to doubt whether or not you will deliver on your sprint commitments. This can be a corrosive influence on the relationship with the very people who are signing the team’s paychecks. The solution? Stop overcommitting. This means that the team has to face some awkward issues about how to manage balancing work within their ranks. These are issues they were able to hide from by overloading the team with work. I got some grudging buy-in at this point, but I could tell that there was still work to be done.
• Carry over matter: Since they are overloading the sprint, they are almost guaranteed to have items that are not completed and those get carried into the next sprint. I took the time to point out that this sort of issue is a problem, but you can skate by when you are simply going from sprint to sprint. However, when you are trying to work to a release plan with multiple teams and multiple sprints, then carry over is a total deal breaker. If you are working with other teams and you have a pattern of failing to deliver stories, the other teams are very quickly going to learn that you are not a good partner to work with.
• Transparency: So I asked about this because I wasn’t sure what the problem was. Apparently they were concerned that they were being asked to track their time and their tasks in a time tracking tool to a level of detail that was making them uncomfortable. As we talked about it someone said, “I don’t think they trust us…” I could tell that this person was a bit upset by this perceived lack of trust. Of course I put on my Mr. Sensitivity hat and replied…Of course they don’t trust you! You don’t deliver committed work on time!

Well, I don’t think I said it exactly like that, but it was some polite variation on that theme. Now people were upset, and finally my message was getting through. The product owner for the team, gave me loud and vigorous support at this point. You could tell that we had stumbled on a fundamental assumption that people on the team were realizing was dead wrong. The scrum master articulated the invalid assumption for me: The whole purpose of having a sprint goal means that you can achieve the goal without having to deliver specific stories. You focus on the goal rather than the stories. That is an interesting, but completely incorrect interpretation of how commitment works. Apparently much of the team was operating with this model in mind. Once I pointed out that other people were depending on those specific stories being delivered, not some abstract goal, then you could feel the resistance immediately start to evaporate.

The other thing that was a little disturbing about this situation is the blind spot that the team had when working with other teams. They had explained away their inability to deliver as due to their own superior understanding of what it means to ‘be agile.’ No one else understood how awesome they were because the other teams weren’t as agile as they were. Now there is no doubt that they were doing a lot of things right. Like I mentioned in the beginning, they had a lot of good things going on. However, they had managed to paint over the ugly bits of their process without examining them and addressing them. Their ‘agility’ was their excuse for not delivering commitments. This sort of failure is not unusual – I’ve seen it happen in plenty of other teams. Dealing with these sorts of issues is hard for a team to do. Sometimes it takes an outsider to see them and point them out. So be careful about declaring your own agility. Doing so can sometimes hide some ugly spots.

This is What I Do

I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com

Individuals and Interactions

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

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

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

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

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

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

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

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

The Agile Gymnasium

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?

Superman Syndrome

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,

Superman