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


Dev + Friends

February 15, 2019

I was introduced to a new concept a while ago: Dev + Friends

Apparently it works like this: the only truly productive people in an organization are developers. They are the only people who actually put hands on code. Everyone else in the org is just overhead…ahem, friends. Managers, release engineers, Admins, QA, Project managers, in short anyone who doesn’t write code. Full stop.

I’d like to pause for just a second to express my utter horror at this concept. I think I get where it comes from. Organizations, especially large organizations, can become bloated. Executives looking at the composition of teams see that some teams are less than 50% developers and…Oh jesus I can’t even begin to paraphrase this bullshit. It hurts just repeating it. Well, I’m going to grit my teeth and try anyway.

I was part of an organization where the CTO introduced this concept. I suspect he felt that the developers didn’t have enough voice in the organization, so his answer was to make them the most important role in the organization. Everyone serves the developer. There is a certain justice in this. Teams had indeed become bloated with required roles that increased expense without necessarily increasing productivity. One particularly suspect role was the scrum master. To some degree this was a backlash against introducing agile to teams that wanted nothing to do with it (and were given no choice). Then there were product owners, who were often new, and had no domain knowledge. In fact the teams often knew more about the domain than the product owners. On a team with 7 people you just introduced 20-30% overhead without writing a single new line of code. And those scrum masters and product owners don’t come cheap.

So, apparently to combat those issues the CTO told everyone in the organization that the only valuable people are developers. Everyone else only exists in service to development. He called it Developers+Friends. Coders are the only people who are valuable to the organization. I remember feeling like a third class citizen almost immediately when this was announced. It was the most demeaning thing I’d heard in my professional life. Apparently, the work I did wasn’t important because I didn’t write code.

Just in case you’ve missed it, the fallacy lies here: developers aren’t the only people in the organization who contribute value. Part of the problem lies in the explosion of job types in larger organizations. This rarely comes up in small organizations for the simple reason that in a small organization, everyone contributes no matter what their job description is. In fact, their job descriptions in small organizations are almost irrelevant. Everyone is scrambling to help out so frantically, that the question of strict role responsibility never even comes up.

For the record, there are constructive ways to deal with these issues that don’t involve demeaning everyone who isn’t a developer. Involving the teams in the selection of their roles and processes. Insuring adequate training for people filling key roles. Focusing on flexible roles that don’t map directly to job descriptions. It’s really not that hard. You just have to treat people with respect.

Want 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



It’s All About Flow

February 14, 2019

OK, please forgive me, but I’m going to geek out for bit here on some Thermodynamics of Emotion stuff. Furthermore, I’m going to try and draw an analogy between a law of thermodynamics and the business world. So, hold on to your hats, here we go… 

In the Design of Nature, Bejan states the Constructal Law as:

“For a finite-size flow system to persist in time (to live), its configuration must evolve in such a way that it provides easier access to the currents that flow through it.”

-Bejan, Adrian. Design in Nature

This is to say that for any living system there is a design or landscape that must change over time such that the flow through the system improves. The design can be anything as primitive as the branching of streams, the vascularity of the arteries and veins in your body, or perhaps the process that you use to do work at the office.

In business, process is the design that we use to structure the way work flows through our organizations. As such, the process is not arbitrary, but intentional. If it improves the flow of work, then it’s a useful process, if it degrades the flow of work, then it’s not. By improving the flow of work, we mean that it must configure the landscape or domain such that the work flows more easily (read with less resistance) through the system. That also implies that the access to that work is improved (it takes less energy to find it).

According to Constructal Law, processes that allow work to remain hidden interfere with flow. Processes that constrain work so that it’s flow can’t change or evolve also interfere with flow. Given these assumptions, old-school, plan-driven methods with rigidly defined processes are counter to healthy flow and are less likely to succeed than processes that are dynamic and enable transparency of work in the organization.

In fact, to carry this one step further. What we are currently witnessing in the last two to three decades is the evolution of processes in the business world. Rigid, plan driven processes are dying off, as the Constructal Law would predict, in the face of new dynamic processes like agile. Any process, even somewhat imperfect, that improves flow and transparency of work in the system is going to be more successful (more efficient conversion of energy to work) than a more rigid process. 

Of course, agile too will one day be replaced by a process that successfully enables better flow. What that next process is remains to be seen.


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?


Team Emotional Flow

February 12, 2019

The morning begins with everyone arriving at the office and gathering in the kitchen. The whole team is works together, there are no remote workers. As folks grab coffee and maybe toast a bagel, there is casual banter about the game the night before, the kids performance at a school play, and plans for an upcoming barbecue.

When the last member of the team arrives, they all gather round into a circle looking at one another. There are a few mumbled “good mornings” and one member starts off with, “I’m feeling excited, we are going to get to integration test the system for the first time today. I think the plan is to start around 10:00.”

There are a few raised eyebrows and then a question or two as folks sync up. The next person in the circle says, “I’m feeling frustrated this morning. The work on the UI hit a stumbling block last night, and I hate leaving work with an unresolved problem.” Someone else chimes in with, “Me too! Let’s pull the mob together and see if more brains can help us nail this problem this morning.” There are general mumbles of assent from the group and the process continues with the next person, “I’m feeling glad that we’re making progress. I think I know what is causing that problem, so I’m looking forward to sharing a potential solution.”

And so it goes, each after the other. The format is relatively loose: You always start with sharing a feeling, then follow up with any resistance you may be encountering. The emphasis is on keeping the interaction casual and not forcing anything. There is no pre-defined leader. Everyone has agreed that this kind of sharing is important and they support it as needed.
At the end of the meeting, everyone updates their feeling status on a whiteboard. They track their feelings on a daily basis so that they can see trends in their overall team mood. They work together as closely as possible. They use mob programming to do their work together whenever possible. The focus is on sharing their experience together.

One tool they use to keep themselves aware of the emotional flow of the team is frequent use of the “check in”. The check in is taken from Jim McCarthy’s core protocols. The idea is to declare your emotional state at the beginning of significant meetings and interactions. This helps to make emotion visible to everyone and gives important needed context for others who you work with. You simply state your current emotion: I feel Mad, Sad, Glad, etc. It lets everyone know where you are at and helps the group to synchronize emotionally. It doesn’t have to be rigid and highly formalized. I think that depends on the character of the team. I personally prefer a casual but disciplined approach (always do it, but let the language be natural and informal rather than highly structured and rigid).

I offer this as an alternative to the traditional standup. We don’t track work, we track feeling. We focus on achieving emotional flow. We don’t use a rigid system of pre-defined questions that must be answered. We flow.


Transformation Journeys

February 11, 2019

I was talking with a customer today about a transformation. Like most folks, they wanted to know what the start of their transformation journey would look like. That’s usually a pretty easy question to answer. I might suggest that we start with basic agile training for the leadership team, then engage with them to co-train the teams in work groups. Maybe we work with product and other teams to help get them engaged. I might even suggest chartering and kickoff events of one kind or another. It’s all pretty standard stuff, but it usually ends with “…and then you advance from there.”

There’s nothing wrong with that. We don’t really know where a given customer will take their transformation once we, as consultants, have left the building. However, it doesn’t give people much of an idea of what comes next. In fact, it does nothing at all. It strikes me that we as an agile community have collectively acquired enough experience with agile transformations that we can start to articulate at least rough trajectories of agile transformations.

Here are a few transformation journeys that immediately occur to me:

  • The Pendulum – You adopt an agile framework, run into impediments, pain, etc. and drop the framework. Then you realize that you need agile, so you start all over again and adopt another agile framework. Rinse and repeat.
  • The Requirements Black Hole – you like the new agile process, but you missed a few things in your last plan. So you add more process to catch those things in planning next time. But you miss a few details next time, so you add some more process. Repeat until the requirements process becomes so inconceivably heavyweight that not even light can escape the organizational event horizon.
  • Spotification Syndrome – You want to skip the learning bit and just use a successful system that someone else has already taken the time to invent. You change all the names of your process artifacts to match (Let’s call them tribes!). Of course, nothing meaningful beyond the names have changed, so there is no real change.
  • De-scaling – Maybe you adopt a framework and that was an improvement over the chaos you had before. Now, based on thoughtful experiments, we continue to remove processes rather than add it. Ultimately we have a unique, very lightweight framework that works the most efficiently for our culture.
  • The Inverted Bureaucratic Pyramid – We slap additional roles and processes on the organization. This has the consequence of creating an army of new managers and middle managers. The organizational hierarchy balloons, with there being more roles than people actually doing the work.
  • Bright Shiny Frameworks – We start with one manager attending a certification class for a framework. He comes back and pitches the new dream framework to the organization which decides to adopt it. They get into it for a year or two and realize that they still have problems, so they send a manager to another framework certification. They come back and pitch the new dream framework…ad nauseaum.
  • Fossilized – We adopt a framework and never change again. Ever.

None of these is guaranteed, but I’m sure folks have seen varieties like these. Looking at the list now, I’m a little disappointed that I didn’t have more success scenarios. I must be feeling a little cynical today. I’m sure there are many more (and I’d love to hear what you think they are).

I think we need to pay more attention to describing what the journey might look like for our customers long after we have left (both good and bad). It could give us a sort of pattern language to describe the challenges that they will face down the road on their own agile journey and help them to make better decisions, or at least better informed decisions, when the time comes.