Cooperation vs. Collaboration

February 19, 2019

I was working for a small company that was acquired a few years ago. Soon after the acquisition was finalized, our senior VP invited his new boss to come visit us and meet with some of the leaders of our organization. I was invited to that meeting and introduced as someone who had been leading the agile transformation within our group. I remember shaking this guys hand and thinking he was probably some sort of ex-college football player. He was enormous, sporting a giant smile, and he did what he could to set us all at ease. He exuded confidence and power. After all, he was an exec with a fortune 10 company.

We were all given a chance to ask him questions. I wasn’t feeling very smart at all that day. In fact I was a little intimidated if the truth be told. So I asked what I thought was a pretty lame, if harmless question, “How can you help to promote collaboration between our two groups?” Like I said, weak stuff. His answer was priceless,”Collaboration? Isn’t that what they shot people for in World War II?”

Right then, I knew I was in for a rough ride.

I’ve been reading a book by Yves Morieux and Peter Tollman called “Six Simple Rules: How to Manage Complexity without Getting Complicated.” Yves Morieux first caught my attention in Ted Talk that he gave a few years ago. In that talk he made a compelling case for the over-complexity of today’s large organizations. His argument was that you needed fewer rules and constraints, not more, in order to improve. It turns out, he is speaking from experience. He has tried his approach out with multiple European organizations with some success apparently.

One of the things that he emphasizes early on is the importance of establishing and reinforcing cooperation rather than collaboration. Collaboration is good, he argues, but it’s too limited in scope. It can mean a little as we talked together, but perhaps didn’t actually do much. Cooperation, he argues, implies that at least one side had to give up something, and actually accomplish some work together. So he sees cooperation as a stronger statement than collaboration. Perhaps it is.

Do they shoot people for cooperation?


Trapped in Amber

February 17, 2019

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

February 16, 2019

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


Maxims and Manifestos

February 13, 2019

My Dad has always been a passionate outdoorsman. For him, when it comes to spending some quality time, nothing beats hunting and fishing. So as a kid I spent a lot of time on the banks of rivers and streams with a fishing rod in hand or marching through fields of tall grass with a dog and a 12 gauge. It’s just how I spent many of my weekends growing up.

Hunting and fishing are complex activities. First, there is knowing where to find the fish or birds. Then there is selecting the right gear. Then there is an element of skill in using the gear to actually catch what you are after. That is actually a very broad set of skills and tools required to be a successful hunter or fisherman, and I’m not even getting into some of the woodcraft required to simply survive in the outdoors, let alone catch food.

I hope I’ve made a reasonable argument for hunting and fishing as a complex activity. After all, if it was easy, they probably wouldn’t call it hunting. That’s actually a little maxim that Dad used to share with me when I got frustrated. 

He had a bunch of maxims: 

  • “If it was easy, they wouldn’t call it hunting”
  • “You won’t catch a fish unless you have your hook in the water”
  • “Always use enough gun”
  • “Never wear red in a duck blind”
  • “Shoot it ’til it’s dead”
  • “Never pee on an electric fence”

OK, admittedly some of that advice was perhaps less useful than it could have been, but that’s how maxims work. It’s kind of left up to the reader to decide how to use them and whether or not they are worthwhile.

When the Agile Manifesto was created, there were 12 principles that were part of it. Each of these twelve principles expressed a key way of thinking about or viewing the world from what we would think of as an agile mindset or agile philosophy. At their simplest the agile principles form a set of reminders or guideposts on our journey through a complex environment that help us find agility or perhaps just remember where it was. You could think of each of those principles as really just a set of useful maxims – just like those maxims that my Dad used to share.

A manifesto can also be beneficial to teams. Of course, you can just point at the Agile Manifesto and use that, but I’ve actually found that teams can benefit from writing their own manifesto. Writing manifestos is actually good fun. There are a variety of them out on the Internet that you can look to for inspiration and examples. Aside from the Agile Manifesto, there is the Declaration of Interdependence, the Craftsmanship Manifesto, and more. If you want to have some geeky fun, check out the communist manifesto. There are hundreds of manifestos out there! Most manifestos are an attempt to declare a shared set of values. They are also usually expressing those values as a break from the past. If you look at them closely, most manifestos are usually a statement of values perhaps with some guiding maxims. That’s perfect for a team. 

My experience has been that teams have a lot of fun writing their own manifestos. It helps them to discover where they are empowered and where they have some autonomy. Being able to describe their own unifying vision goes a long way toward accomplishing that. However, you will find teams that struggle with this exercise too. From a coaching perspective, that struggle also represents an opportunity. There can be a lot of reasons that folks might struggle to write a manifesto. For example:

  • Not everyone is equally good with writing. Text based exercises like manifesto writing tend to fall flat for people who are very visual or physically oriented. Providing some visual tools, like a stack of magazines along with scissors and glue would be a good way to offer folks an alternative medium for expressing themselves if words aren’t their thing.
  • If there is significant dysfunction within the team. For instance, if they are being driven by a micromanager, then you typically don’t see a lot of independence and free thinking from groups like this. They might struggle with a creative exercise like this. These teams are often afraid to act without permission. There’s no quick fix for this, short of identifying the manager and starting to work with them.
  • Sometimes the team isn’t really a team. The reason they are struggling to come up with a common manifesto is…they have nothing in common. A team that is really just a group of independent actors will struggle to come up with a manifesto. They may manage to do it, but what they end up with is usually a watered-down mess that doesn’t feel like it’s very useful.

A good manifesto makes you feel something. A good manifesto smells like rebellion. It often feels a bit joyous too. Like something was unleashed. And when a team’s manifesto includes the customer, you know you have hit pure gold! If you read a team’s manifesto and the hair on your arms stands straight up, you’re on to something good. 

Running manifesto writing workshops is one of my favorite things to do. I’m always surprised at the outcomes. When people find the words that describe themselves as a team, they feel differently. Declaring that unifying theme to the world has power. Who doesn’t love that?


Building a Scaled Agile Framework for Dummies

February 10, 2019

Scaled Agile Frameworks like SAFe are all the rage these days. You can go out now and get training, certification and a shave from a bevy of consultants that for a mere two grand per head (not really sure about the shave part). That’s a perfectly legitimate approach. However here’s a dirty little secret: anyone can do it. Here’s an example of one that I made a few years ago.

I had taken a look at SAFe and there was a lot that I liked and there were some things that just didn’t seem to fit our context. With those qualifications in mind. I decided I could make my own version. I got out my notepad and my colored sharpies and I went to town. I knew that I liked the three layer model, but I found a lot of the SAFe Big Picture had too much complexity in it. So you can see that in the first level, I simplified things quite considerably. The second or program level was also quite simple. I mixed in some things like agile chartering which I felt would be beneficial and were not found in the SAFe diagram. What about the third (Portfolio) level? Well, at the time I really didn’t have a clear idea how that would look. It was at this level that I was looking to integrate the model with our existing PMO practices – which in hindsight was probably a mistake (hey, make your own model and you make your own mistakes). So then I started to iterate.

Now I was starting to think about how things related between the three layers. Those interactions between the team level, the program level, and the portfolio level seemed to be very important. I was also experimenting with different ways of visualizing the processes on each level (with what I must confess are varying degrees of success). My color repertoire had expanded too.

Finally I started to look at the processes as a series of prescriptive steps that I needed to be able to document and describe to people. You can see that I added numbers and then I took each of those interlocking blocks and documented them. I made poster sized copies and put them on the wall outside my office with a sharpie hanging next to them. The request was simple – please change it to fit your needs. After a few days, I had more feedback and iterated from there.

Building your own scaling model isn’t for everyone. However, it’s not rocket science either. If you have a modest understanding of your own business domain, AND you understand the basics of the agile frameworks, you have everything necessary to build your own scaling framework. I’m sure there will be folks who are appalled by the arrogance of doing something like this, but personally, I think we all should feel free to make our own Big Picture. When we can customize our processes in ways that work best for us, I think we win. We learn along the way and we don’t inherit a bunch of cruft from someone else’s framework.


Your Framework Sucks

January 16, 2019

We can learn the art of fierce compassion – redefining strength, deconstructing isolation and renewing a sense of community, practicing letting go of rigid us-vs.-them thinking – while cultivating power and clarity in response to difficult situations.

-Sharon Salzberg

Recently I’ve seen a lot of negative comments on social media criticizing SAFe and other scaling frameworks. Some of it can be chalked up to the Agile community’s typical aversion to change (ironic, isn’t it…). You hear it whenever somebody says, “That’s not agile.” That’s just another way of saying, “That’s different.” This isn’t anything new. I remember people used to say the same thing about Kanban when it was first introduced. They’ll probably say it about the next new thing that comes along too. Some of it is the usual competitive “My agile-fu is stronger than your agile-fu.” There are a bunch of agile scaling frameworks now, and curiously, none of them has anything good to say about the others. Despite all that, there are some criticisms that I think are pretty legit. I’d like to address a few of those here.

First, the rollout plans for SAFe and other frameworks seem to be pretty static. That could just be me, after all, but I don’t see a lot of variation in the approaches to rolling out frameworks. It’s often top down, and dictated largely by the management teams or key stakeholders in the organization. I’m not arguing that isn’t the right way to do things, but I am arguing it’s not the only way to do it. The agile community at large has been experimenting with how to introduce agile to groups in a fashion that is more bottom up for a long time. This bottom up approach has many advantages. If we can get the people doing the work to have a voice in how they are organized, then we are much more likely to get their buy-in and engagement with the new organization. Those folks also know more about the work, so they are probably better suited to make key decisions about who works with whom. Bear with me here, because this is some pretty radical stuff. There are folks who are experimenting with self-selecting teams that are making impressive progress. Imagine being able to work on whatever team you like? Amazing.

For example, we should be able to introduce team self-selection into SAFe as one of multiple options for creating release trains. There is nothing about self-selecting teams that breaks or somehow violates the 9 fundamental principles of SAFe. In fact, I might argue that self-selecting teams are perfect for SAFe. I truly believe that they are much more likely to be high performing teams than teams that are selected in a top down fashion by managers. There could even be a hybrid model where the management teams define the capacity – the overall size of the release train according to funding allocation, and the teams self-select to match that capacity. It would be a combination of top down and bottom up.

The other area where I see rather dramatic over-control from the top is with the emphasis on the top down epic-feature-story elaboration. Often this process can be so rigid that teams can feel as though their feet have been nailed to the floor. Everything is so tightly defined by the time that it comes to the team, that the team doesn’t feel like they have any options. All of the key decisions have been made. In a very real sense, if everything has been decided before the team sees it, then the epic-feature-story elaboration process is indistinguishable from waterfall from the teams perspective. It’s especially bad when the teams are asked to commit to delivering those features and stories for a planning increment. Suddenly you have teams wondering what, if anything, they are contributing to the process. There certainly doesn’t feel like there is much room for learning.

I think there is a hybrid approach here where the teams take the epic-feature-story breakdown as inputs for negotiation and conversation, but they don’t commit to them. To me, epics, features, and stories are a useful language or model that product owners use to describe what they think the customer or marketplace wants. Epics, features, and stories are not actual value. They are a description of what we think value might be. They are an input to the team design process, not an output. This is important and probably bears repeating: epics, features, and user stories are an input to the design process, NOT AN OUTPUT. We want teams to commit to outputs. Specifically, something valuable. Software that does something useful is valuable. So we want them to commit to delivering some software that we can use to do something valuable. So we should stop asking teams to commit to the inputs, and instead ask that they commit to outputs. Commit to value. That would cure a whole lot of dysfunctions that arise from asking teams to commit to delivering inputs.

There is a transformation that needs to take place between a request defined by epics-features-stories and the resulting useful software that is produced. This is where the sausage gets made. The team uses features and stories to try and understand in simple terms what is being requested of them. Then they integrate that model with their own understanding of the domain and the working system that they have before them. Even that is an incomplete picture of the world. To really do well, they have to use all of this incomplete information to test their assumptions against the system and the customer to get some feedback. They find unanticipated problems, and they have to have the freedom to change fundamental assumptions in order to arrive at what is hopefully something very useful to the customer. That’s never a given, there are always lots of unknowns, and we have to allow for that.

These are a couple of examples of how we can experiment and play with how the framework actually gets rolled out. There is lots of room for variation – that’s why they call it a framework to begin with. There’s a roadmap for rolling out SAFe. If you are just starting out, that’s probably the best place to begin. However, I think that as experienced practitioners, we need to be exploring many different ways of rolling out SAFe (or whatever your framework of choice happens to be). Not all customers are alike, especially when it comes to scaling agile. We need to be flexible and creative in the manner in which we implement our frameworks. In and of themselves, frameworks provide a set of overlapping ideas that can help us start to deliver value amid the chaos that is often the norm in so many places. However we need to implement those frameworks using all the creativity and imagination at our disposal. This is how we can best serve our customers.


Going Viral

August 15, 2016

thermometer-temperature-fever-flu-large

“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.