A House for Hermit Crab

April 23, 2019

One of the wonderful things about being a parent is all of the children’s books you get to read. I never fail to be amazed at the simplicity, grace, and sheer storytelling genius that I find in many children’s books. I’m thinking of amazing books like Where the Wild Things Are. It’s stories like these that seem compelling no matter what your age. One of my personal favorites is a little story by Eric Carle called A House for Hermit Crab.

In this story, our hero the hermit crab has grown out of his old shell and it’s time to find a new one. So off he goes and finds himself a nice, brand-spanking new shell. He’s pretty pleased with the fit, but to be honest, it looks a little plain and could use a little decoration. So our hero ventures forth in search of a little bit here or there to decorate his new home with. Each time he meets a new character (a starfish, an anemone, a coral) he greats them with great joy, compliments them on their beauty, and invites them to share his house with him. It’s a long journey, and at the end of a year he has a magnificent shell covered with many dazzling creatures. Just as he feels happiest, he realizes he’s growing out of this shell, and with some regret moves on to a new shell.

This story speaks to me on a couple of different levels. Like the hermit crab, I have adopted different process frameworks (call them shells) over my career. Early on it was XP. Then it was Scrum. Then SAFe…and God only knows what the next bright shiny framework is that I’ll wear. And with each one, I discovered unique practices that seemed like useful additions to my process house. These were practices like test driven development, pair programming, mob-programming, and so on. Each one I held up to the light and thought, “You’re awesome!” And invited my teams to try them. It took years, but I collected quite an array of decorations for my shell. Usually, just when I felt pretty confident with it all, I started to outgrow that shell, and with some regret, moved on to a new shell. So the process repeats itself. I know that my journey has been metaphorically very similar to that of the hermit crab. I adopt a model, modify it to make it mine, and eventually grow out of it.

There’s another reason A House for Hermit Crab speaks to me. It’s the delightful open and inviting attitude of the hermit crab as he meets each new creature. I feel the same way about a lot of the people, practices and processes in our agile community (…and beyond). I guess I tend to err on the inclusive side. I think of it as a “play first” approach. Extend the open invitation and see what happens. All too painfully often our community tends to do the opposite. There is far too much, “That’s not agile” and far too little invitation to join and explore together. I think that our little Hermit Crab has an admirable way of approaching novelty.

Ultimately, I think I like the way that A House for Hermit Crab makes me feel. Not to get too precious about it, but this feeling of open invitation is what I long for the most. It’s what originally drew me to agile in the first place. We all will likely have many different shells (or models, or frameworks) that we will inhabit at one time or another as we grow. We should invite each other to decorate those shells to reflect what we think is beautiful, and share them with others. That is what motivated me to write my recent series of articles about SAFe Mix-in’s. SAFe is the shell in this case, and we can decorate that shell any way we please with many interesting practices. If you are curious, like me, and want to decorate your own shell, check out the following Mix-ins:

Perhaps my SAFe shell is starting to feel a little cramped, so maybe it’s time I shared it with someone else.

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


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.


When ToDo, In-Progress, and Done Aren’t Good Enough

January 4, 2010

On a task board there are two places that we can capture additional detail regarding the tasks we are working on:

  1. In the tasks and stories
  2. In the categories that we use to organize the tasks and stories

The common starting point for categories on a task board are: ToDo, In-Progress, and Done. Obviously this works for the great majority of cases because the categories are so vague. It’s the starting point for most teams that are using a task board for the first time. However it isn’t long before we discover that some things don’t fit this model well. For instance many tasks commonly take place in multiple ordered steps. Look around you, it happens all the time. Trying to capture tasks that have more than three steps to them on a task board starts to feel awkward. People start to ask if there should be another column on the board. The answer is probably yes.

You see, if you resist and decide not to track additional legitimate state for a task, then in essence you are keeping that information invisible. State is important. Hidden state violates the principle of transparency that we are trying to promote on agile projects. So you need to find a way to represent it on your board. There are lots of mechanisms to reflect additional state on a task board:

  1. Add new swim lanes
  2. Use color on the task/story cards
  3. Use labels or stickies on the task/story cards
  4. Additional text on the card
  5. Additional task cards

All of these techniques will provide additional state information to your task board. A common symptom of a board that isn’t conveying enough state information is when the stories tend to get “stuck” under the In-Progress category for long periods of time. Now there are lots of reasons this can happen, but one reason the task/story may not be moving is because you don’t have an adequate way to express the state of the progress being made on the work. The developer may be making lots of progress, but none of it is reflected in the task board. When this happens, you need to consider that perhaps the board is not displaying information that would make the progress visible.

I was reminded of this today when looking at a team’s task board. Stuff was sitting in the In-Progress” category for too long. However I knew that the team was making great progress. So they weren’t lazy. And they were keeping the board up to date. So what was the problem? There wasn’t enough information on the board to properly reflect the work that the team was doing. As a result, there were impediments that we couldn’t even recognize because we didn’t have any way of showing progress on the hidden states. Being blocked on “In-Progress” is not very informative. Being blocked on the “certification request” is much more explicit.

So the next time that the team seems like they are stalled with their task board, consider changing the way the information is presented. Adding a few new categories could help the team identify some of the hidden issues that are currently blocking them.


Technical Product Owner

June 2, 2009

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

  1. Stories requested by operations
  2. Stories that have to do with infrastructure improvements
  3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

  1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
  2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
  3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
  4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.