Agile Antipatterns

“Agile Antipatterns” was a June workshop I lead for the DC Technical Product Management Community. The purpose was, through techniques borrowed from Lego Serious Play, to take the audience through a journey discovery about their own software development challenges. It was different from the lecture style I usually do but, despite this, the quality and depth of the ensuing conversation exceeded my expectations.

This presentation is part of my goal to produce six original works in six months. For more information see the post about my conversion of travel time to productive time in 2019.

The slides and script are below.

Hello everyone! Let’s get started.

Welcome to agile anti-patterns. Thank you to Rob for giving me a chance to deliver this talk where we’re going to talk about:

Tetris Planning
Feature Factories
Success Theater

More importantly than just talk about those things, we’re going to discuss what to do if you happen to find yourself in those situations.

And if none of that sounds appealing, we also have some Lego at our disposal. Regardless of what you were looking to do, by the end you shouldn’t leave disappointed.

My name is Matthew Reinbold and I am an adult fan of Lego. When I’m not tinkering on my own builds in my home office I am also the director of Capital One’s Platform Services Center of Excellence. My team and I are responsible for balancing software programmer independence and platform integration needs for API and event streaming development. Capital One has approximately 9,000 developers. At some point in their lifecycle, my team collaborates with those development teams. I also have done similar roles at other enterprise companies. In the past year I’ve also consulted with Allstate, CVS, and Google on how they can create more effective software development pipelines.

When you deal with that many teams over the course of many years, you tend to see some things. Certain behaviors show up time and time again. At some point, these behaviors go from being random things and begin to be patterns.

(Photo Credit: Linux Foundation)

Creating models - either rhetorically or with physical bricks- is important. Models allow us to visualize assumptions and surface unknown values. Models help create shared understanding between many individuals, supplementing language.

This image is from 2014, just after I was getting back into Lego during my adult years. I was trying to model the stairwell at work, to better understand how space was used. While I could have pondered things for some time, building a physical representation of a stairwell gave me a different perspective and greater appreciation for how the space was optimized.

There are many ways that one might create a model. I could ask you to draw your responses, or perform some interpretation of your current challenges. Don’t worry, I am not going to ask you to do that, but I would be willing to bet that some of you already have the hairs on the back of your neck just at the thought.

Bricks, however, are far less intimidating. Many people have reservations about their artistic or thespian talents. But everyone can stick two or three bricks together. Lego presents a simple, approachable means to creating models: click/snap.

How many here have heard of or participated in a Lego Serious Play activity?

Lego Serious Play, or LSP, is a technique that uses Lego blocks in directed exercises to build structures that metaphorically represent business models. In the 1990s, under the direction of then president and CEO, Kjeld Kirk Kristiansen (grandson of the original Lego founder), Lego began looking for new techniques leadership teams could use when developing their strategies. The first version and trained facilitators began appearing in 2001. By 2010, Lego created the “community model” of sharing the technique, akin to open sourcing the ideas behind Lego Serious Play.

I’ve used Lego, previously, engage kids in computer science exploration. However, tonight I’m using a less structured version of a Lego Serious Play experience, while still heavily leaning into the model creation for discussion and discovery.

Complex Stories Can Start with Simple Models

You can tell a great story with a few bricks. What you can see here are a series of advertisements that Lego has run in the past. While the models may be simple, they tell a very complex story.

The point with this models is not to have picture perfect recreations of their real-world counterparts. What we’re going for here is the metaphor. If there is one rule this evening, it is that people should “Comment on and critique the metaphor, not the construction”.

That brings us to our first question for us to dig into. As technical product management, you either are working, or have worked with, a development team. I want you take a few minutes and create a model for your role in the development process.

Here are a few examples:

(hold up a stack of bricks) Perhaps this is your model -a bastion of stability, solid and firm for your team to be built upon
(hold a gear) Or maybe this is your model - a cog in a machine
(hold up a captain minifig) Maybe this is how you see your role in the development process - a Captain, ready to lead the team to adventure
(remove the head from the captain minifig) Or maybe this is how you feel, a headless captain, given all the responsibility but none of the answers

The model I want you to build is a metaphor for your role in the software development lifecycle. Let’s take five minutes and then we’ll discuss.

There’s a timer onscreen. When it reaches zero, I’ll ask a few folks to share their creations. Again, we’re not going for photo-realism and five minutes is not a whole lot of time. We need to work quickly. Go with you first idea. Trust your instincts and let’s get going.

Ready? Set. Build!

(After building, five minutes of conversation where volunteers share what they’ve built, and why. We discuss the metaphors and how that makes them feel.)

Let’s get into our antipatterns. In my experience, before we can correct a phenomenon, we first have to identify and name it. Without a name, we can’t address it.

What follows are the description of three agile anti-patterns. There are certainly more, but there’s only so much time that we have this evening.

Agile anti-patterns typically manifest themselves as commonly applied solutions. A solution becomes an anti-pattern when it ceases to provide an effective fix, or when the cumulative effect of repeatedly applying that fix has an ongoing negative impact.

The first of those anti-patterns is Planning Tetris.

Hopefully everyone here is familiar with the game Tetris but, in case you aren’t here’s a quick summary:

The shapes of various configurations enter a player’s screen from the top, and the shape begins to descend to the bottom
The player can move the shape side to side, as well as rotate it
The player’s goal is to complete horizontal lines with the provided shapes. Completed horizontal lines will disappear from the gameboard
The game is over when shapes can no longer descend from the top of the board

The goal is to avoid gaps in the board by cramming as much together in as tight of space as possible as fast as possible.

What does this have to do with product management?

How many people here use story points in their planning rituals? T-shirt sizes? Time-buckets? Am I forgetting any other sizing method?

Well, regardless of which method used for planning, each of these assume that not all work is sized the same. There are “big” tasks and “small” rocks. When prioritizing a backlog, a common approach is to weigh the size of a task with its importance. Balancing across many, potentially competing, backlogs (like tech debt, UX updates, and business imperatives) are a challenge.

The first problem is getting the master queue prioritized for the business. Typically, there are rules for how to do this. Putting together the ‘master list’ isn’t the problem, however.

The second part, and where people get into trouble, is assigning that work. These are two separate problems, but people begin playing Tetris (optimizing for the peak number of items “done”) rather than maximizing the flow of business values.

In this animation, there are several parts:

First, the business creates the “master queue” of priorities across many competing concerns.
Next, teams are assigned, with the highest priority (or ‘Priority 1’) items assigned, then ‘Priority 2’, and so on. In this case, we have a UX “shared team” that will work with Team 2 on Priority 3.
However, ‘Priority 2’ is a big item that requires two teams. Team 2 can’t start work without Team 1. Despite the fact that ‘Priority 1’ is the highest priority, it is shuffled so that teams 1 and 2 can start at the same time.
Meanwhile, the UX team is encouraged to “work ahead” or “get a jump on” their work, despite being dependent on Team 2’s input.
And then executive leadership comes along with their own work-to-be-done, immediately rending the previous prioritization irrelevant.

What are common properties of planning Tetris? Let’s run through some examples:

Pulling “small stories” into a sprint to hit some illusory “velocity” target (even when the stories have nothing to do with a meaningful goal).
Encouraging high individual utilization rates. Optimizing for “looking busy” instead of optimizing for efficacy, outcomes, and flow.
Big-batch quarterly/annual planning whereby some group of managers/planners attempt to “put the puzzle pieces together” and “get all of this done in the quarter” (even if priorities vary drastically).
Asking functional disciplines like UX to “get ahead” of the work, in an effort to work more “efficiently”. This results in an impossible-to-navigate set of dependencies and handoffs (and a lack of information exchange).
Making assumptions about the size/shape of planned work (and the flow of future work) that end up being false. For example, a team will be asked to “move on” from a promising initiative because of layers of dependent plans.
Rapidly reshuffling/rotating teams to tackle an onslaught of projects.
Parallelizing dependent work in the hope that a “horizontal slice” of multiple projects can be completed simultaneously (instead of treating the work as a single project).
Never going back to fix things. The “debt” remains, eating into the collective psyche of the organization.
Ever-increasing pressure on “the teams”. Pushing teams until they crack. Instead of fixing the gaps, management layers on more and more work until the system experiences a spectacular collapse. Teams, inevitably, have to clean up the mess (and are blamed for not “pushing back”).
Banking on that “one piece” to fall into place and save the day. Until then, making no forward progress. When the silver-bullet piece fails to appear…you find the next silver bullet.

How do you deal with planning tetris?

Do not decompose a unit of value into tasks, and then place the tasks on other teams’ queues.
In other words, what counts is the mission: the engaging outcome you hope to generate for your customers and business.
Try to deeply ingrain the idea of “pull” in your organization. It is a huge mindset shift. Pull means that starting something will ALWAYS mean finishing something else. You don’t load people/teams up. You don’t “push” work on teams. Rather, you wait for teams to reach out when they’re ready, and you respect that. You have to trust your teams to do their best without asking them to pre-commit to big batches of work and “stretch goals”.
Stop fetishizing busyness and output. Place a premium on doing more with less. Make craft, thriftiness, and frugality a part of the culture. “Above and beyond” is fine, but it often inadvertently swamps the system. It also incentivizes local heroism over global flow. Focus less on output/busyness, and more on benefits and outcomes. (this can be challenging when metrics are set up in such a way to promote “business”
Leverage work in progress/process constraints. WIP constraints serve as a forcing function for continuous improvement, a catalyst for pull, and a signal that the system is straining and needs some TLC. Think of every piece/level on a Tetris board as WIP. Unfortunately, WIP constraints are counterintuitive: we look to estimates/guesses to “size up” the work and “fill up” the system. This is a recipe for dangerously high utilization rates and long, long lead times.
Visualize dependencies / visualize the whole. When we split things up, we tend to lose the thread. By visualizing things “as a whole”, we tend to make wiser decisions. Instead of six “projects”, we have a single mission.
Do something about the “debt”. Cutting corners creates gaps. We rationalize cutting corners to learn earlier, deliver earlier, and make money earlier. The problem is that the debt add up and add psychic drag on teams and, eventually, overwhelm them.
Map your assumptions. We tend to act based on a web of assumptions (some conscious, some unconscious, some fragile, others robust). Building shared understanding around our assumptions can expose “tangled webs” early, and encourage us to simplify, solidify plans at the last responsible moment, and leave more slack in the system.

Modeling You in Relation to Your Backlog

This brings us back to our models. We previously created a model of our roles in our product development. We’re going to continue to build on that. Take the model of yourself and create the relationship between you and your backlog (or backlogs).

Is that relationship:

a treasure of untapped potential
a dumpster fire
a pipeline of great ideas
an overstuffed stuffed closet?

While creating that model, take what we’ve learned about planning Tetris. Is there an aspect to that in your sprint grooming? Are you optimizing for a high rate of Work-in-Progress (WIP)? Do you metrics celebrate busyness or velocity? How does that manifest in your model?

(After building, five minutes of conversation where volunteers share what they’ve built, and why. We discuss the metaphors and how that makes them feel.)

Planning Tetris, if left unchecked, results in teams producing things for the sake of producing things.

In this situation, development has been come a factory, pumping out features, and the team are just line workers. They’ve become disconnected from the business value derived from their work. They finish a feature, or close a ticket, only to get another immediately afterward with little sense of continuity or importance.

Update 2020-01-17

I had to include this image from Charles Lambdin’s post. It perfectly illustrates the problem of mistaking feature velocity for value generation.

Feature factories (also called feature pumps) are incredibly corrosive to morale and, despite the pressure to create an ongoing stream of work, decreases the alignment with the missions of the company. Outputting things is more important than the outcomes those things cause.

Thus, we have the agile antipattern of feature factories.

What does it feel like to work in a feature factory? This quote sums up the experience:

“You know… when this is “done”, we will have moved on to the next thing. Sure we will have shipped something, but it will be anyone’s guess whether this actually worked. When do we answer that question? It just never seems to happen.”

How can you tell that you might be working in a feature factory?

Rapid shuffling of teams and projects.
Instead of compelling missions or initiatives, teams deal in feature and project assignments. Chronic multitasking and over-utilization
Infrequently acknowledged failures and scrapped work. No removed features. Primary measure of success is delivered features, not delivered outcomes. Work is rarely discarded in light of data and learning. Often the team lacks the prerequisite safety to admit misfires
No connection to core metrics. Infrequent discussions about desired customer and business outcomes. Team cannot connect work to key business and customer satisfaction metrics. Impossible to connect iterations to “what matters most”
No PM retrospectives. Product managers do not conduct regular retrospectives on the quality of their product decisions and compare expected benefits to actual benefits. Developers have “passing tests”, but product managers do not. Product managers view velocity and output as their key performance indicator.
Obsessing about prioritization. Mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (deciding if it was, in fact, the right thing to work on). Prioritization rigor is designed exclusively to temper internal agendas so that people “feel confident”. Lots of work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Roadmaps show a list of features, not areas of focus and/or outcomes
No tweaking. Once work is “done”, the team moves immediately on to the next “project”, leaving no time to iterate based on qualitative and quantitative data
Culture of hand-offs. Front-loaded process in place to “get ahead of the work” so that items are “ready for engineering”. Team is not directly involved in research, problem exploration, or experimentation and validation. Once work is shipped, team has little contact with support, customer success, and sales
Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint
Chasing upfront revenue. Features are implemented to close new deals. While not inherently wrong, the economic justifications are often flimsy (at best), and fail to account for the non-linear increase in product complexity (you make the quarter, but you pay for it many times over later). Again, this reinforces the idea that features are the unit of value measurement. Product decisions lack a sound economic grounding
Shiny objects. Low visibility for refactoring work and debt work-down. Low visibility for overall value delivery capabilities. As mentioned, primary measure of success is new feature output. Little appreciation for the health of the whole product as opposed to shiny new objects. Little awareness around impact of new features on usability (and maintainability and extensibility) of existing product
Success theater around “shipping” with little discussion about impact. You can tell a great deal about an organization by what it celebrates (more on that in a moment).

Approaches to Dealing with Feature Factories

Correcting a situation in which a feature factory exists means mending the gap that has occurred between what is worked on and the value that is delivered.

Arrange a meeting with your company’s CFO. Have them explain the moving parts in the business model, and the assumptions that underpin forecasts and growth targets. How do you really make money, and what must remain true for you to continue to make money? What costs matter now? Why are sales goals what they are? Where does product performance fit into the big picture?

To defeat the feature factory, the line-workers (that’s you) must learn to speak the language of the business as well as the language of their craft. It’s the game you’re playing. Be wary when told that the team “just needs to execute”.

What does the ‘language of business’ sound like? Some examples include:

“If we continue to iterate on this existing feature we can achieve that goal without having to fork the product. It’s worth our focus.”
“The work we’re doing is barely making a dent in the key metric.”
“If we accumulate this technical debt, we wont be able to meet those goals for new product development.”
“Churn will increase beyond your threshold if we don’t double-down on nipping this expectation mismatch in the bud.”
“We can still meet these sales goals if we choose to be more selective. Building feature on demand is a distraction, and I’ll show you why ….”

It’s a reframing of one’s job. It means you’re not just there to deliver work. But by speaking the language of business you can break out of the factory model by explaining how peak optimization is hurting the bottom line.

Illustrate the value of your work in terms of business output - the value created by your teams is not the number of features delivered, and be wary of any metric that only looks at features delivered, tickets closed, etc. Emphasize the outcomes created in terms of business value - what does that look like?

(After building, five minutes of conversation where volunteers share what they’ve built, and why. We discuss the metaphors and how that makes them feel.)

The continued production a features, now unmoored from real value creation, cause an interesting dynamic. Lots is getting done, but there’s questions about whether it is the right thing. Those that are creating the work now have a stake in selling the work as valuable. In that respect, they become complicit in marketing the work. They are performers in what is known as “success theater”.

At its base, “success theater” is an projected optimism and celebration of delivery that doesn’t match the reality of customer reaction. It’s that the burndown chart must go to zero, or features delivered quarter after quarter go up and to the right, although there were corners that needed to be cut. It’s vanity metrics - the ones that celebrate more for the sake of more, but have little to do with value delivered. It’s optics and smoke and spin and the more levelheaded you are about honest summaries, the more likely you’ll be cut out of the loop for not being a “team player”, or “being a critic”.

Some tell-tale signs of ‘Success Theater’ include:

“pervasive good news culture”, including creation of a particular language. For example, you are not allowed to point out problems, or discuss weaknesses. Instead, anything that isn’t great today is “an opportunity”. (Story about color coding an item in a spreadsheet as ‘light green’ instead of green when it is behind schedule, because coding the row as yellow would raise alarms.)
Every plan is a hockey stick; in order to justify the hiring and spending wanted now, significant ROI has to be shown the day after tomorrow. Or, there’s always the story that next year is the year it all comes together
Messengers are shot - people who raise concerns keep disappearing - either moving on of their own accord, or have odd reasons
Do you do a product showcase? Warts and all? Is it scary to share anything less than the final product to product owners? Stakeholders?

Approaches to Dealing with Success Theater

Success Theater is the last resort of teams that have done the tetris planning, toiled in feature factory, resulting in little-to-no meaningful impact; as a resort, the team is forced to trumpet hollow talking points to justify all their activity.

Success theater has its own language. Like combatting feature factories, it is vital to recognize the prevalent storytelling and frame the discussion accordingly. This won’t be undone easily, either. If you work in one of these places you won’t be able to walk to your manager’s office door tomorrow and be celebrated for the list of grievances you nail to it.

Ask people to highlight issues or concerns - if the culture is averse to admitting weakness, you can soft pedal by asking “if a risk were to develop, where would it be?”
Lead by example - find those in leadership that are passionate pragmatists, concerned about the craft more than the ladder climbing. This leadership needs to reinforce the message, swarming on the things that matter.
Share challenging news, but beware of tone - this isn’t to wallow or curry sympathy. This is an open conversation with an emphasis on learning; despite the fact there might have been a setback, use it to engage and energize people that there is a way forward.
Celebrate those who share an issue or concern, reinforcing their courage and willingness to be vulnerable. It is a way you signal it’s ok to share concerns.
When you have “real” wins, celebrate them like crazy! Shout from the rooftops - put a spotlight on the things that really matter. Have avenues for telling your story and make sure the message isn’t ignored from “celebration fatigue” by only using them for the big things.
Promote people who have bounced back. - celebrate those who have demonstrated resilience, rather than those who have never tasted failure.

Creating a culture where true impact is valued is vital. How do you celebrate the ‘real’ wins? What does that look like in your company? Add to your model how you’ll overcome superficial superlatives, and elevate those things that create real positive customer impact.

(After building, five minutes of conversation where volunteers share what they’ve built, and why. We discuss the metaphors and how that makes them feel.)

The challenges of successfully implementing an agile development process are numerous. We’ve only just scratched the surface. However, it is my hope, that by providing an introduction to planning tetris, feature factories, and success theater you’re better able to identify these problems before they grow.

If you are interested in reading more about these items, please refer to the links below:

Lego Serious Play

In general, why there are some interesting bits here, I have yet to find a Lego Serious Play reference I can recommend without reservation. Your mileage may vary.

Build to Lead (Free ebook from O’Reilly), Donna Denio & Dieter Reuther
Building a Better Business Using the Lego Serious Play Method, Per kristiansen and Robert Rasmussen
Serious Work - How to Facilitate Meetings and Workshops Using the Lego Serious Play Method, Sean Blair, Marko Rillo & Partners

Planning Tetris

Feature Factories

Update 2020-01-28

John Cutler - Feature Factory Signs - 3 Years Later

Success Theater

Finally, if you are on Twitter, I would strongly recommending following John Cutler, the origin for a number of these links. A self-described “product management nut”, he regularly provides thought-provoking examinations of modern product development facets.

My name is Matthew Reinbold. If you are interested in my thoughts on the evolving API industry, I write an email newsletter called ‘Net API Notes’. I am Twitter’s libel_vox and write at MatthewReinbold.com.

Thank you and good night.