≡ Menu

FASTER Fridays – Retrospectives

Happy Friday! This week’s #fasterfridays is a good chance to reflect on our work and our process through the use of retrospectives. Specifically we are using it to help teams develop a mechanism for inspecting, experimenting with, changing and owning their process. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com. Have a great weekend!

Links:

Transcript:

Happy Friday, and welcome to another edition of FASTER Fridays! The end of a week is always a good time for reflection, and in today’s video I want to share how I teach teams to use cadenced retrospectives as an experimentation framework for their own process.

First, if you’re not familiar with Retrospectives (or After Action Reviews, or maybe even “Postmortems”) I’d highly recommend picking up the great book Agile Retrospectives by Diana Larsen and Esther Derby. There’s no single way to run a retrospective, and it was a game changing book for me in thinking about setting ups facilitating and running retrospectives.

One of the challenges I run into with teams is that if they try something – or are told to try something – that becomes their process forever, and ever, amen. This often comes because they don’t have an explicit mechanism for reviewing their processes and operational models to try and report on different ways of working. So instead, I teach them not to think of it as “Teh Process” but instead to think of it as an experiment to explore a hypothesis. Here’s how it works.

I set up what looks like a common board for Retrospectives with 4 columns – What did we expect to happen, what went well, what didn’t go so well, and what do we want to try. Let’s look at an example team and try filling out the board.

The start by saying they expected to release version 3.14 this week. What went well is that they shipped it! But what didn’t go so well is that they had a lot of critical bugs immediately after shipping, so they had to rapidly follow 3.14 with .15. [Pi]. The defects were caused because of a miscommunication between the code reviewed by the business and what actually got shipped. This was caused by two reasons. The first, a section of code was refactored, but the test coverage missed some edge cases, so even though everything passed it wasn’t actually testing all of the critical logic. Secondly, an additional last-minute feature was requested by the business and the team thought it would be easy to put in – but missed that it modified a data variable used by a later calculation that was now off.

Now, does this mean refactoring is a bad thing to do, or adding small features even late is a bad thing to do? Should we say we shouldn’t do that? No! We need to think beyond that to the roots of the issue. We’ve already modified the unit tests to catch the boundary cases, and we modified our integration tests to catch the calculation cases. We throw out a bunch of ideas, but ultimately settle on two:

1) We have a policy that refactorings where all the tests pass don’t require a Code Review, but in this case it would have likely caught the problem. So we want to try modifying our policy that all code requires a pull request reviewed by a second team member

2) The data calculation bug would have been caught by the data team, but they weren’t involved in the discussion because of how late in the game it was. So we’ll set a policy that all changes that could impact data we’ll run past them for input – or not ship it if we can’t get it in a timely fashion.

Now here’s where things get interesting. We agree to try both of them for 3 cycles – in this case, 6 weeks. In our next retrospective, we talk about the two processes, but in the context of what we expected to happen.

We expected that the code reviews on refactoring would catch some defects, but would cause more time to be spent in review and a delay in features

We also expected that having to loop data into any additional change would potentially lead to less cross-team defects, but would cause a significant delay in work since they aren’t always as available

What went well is that we had two cases where the code review caught defects the tests missed. In addition, we found that it didn’t significantly impact the time we spent on reviews.

What didn’t go so well is that two stories that potentially included data work were delayed by several days waiting for their review. We also didn’t notify them of the change we were making, so they weren’t prepared.

But going back to what went well is that the data team agreed to have reserved capacity for our requests with a turnaround time of less than 2 hours.

We want to try another round of the code review, as well as the data team review.

And so the next week the team might find that the code reviews still went well, so they were permanently adopting it, and the data team review times dropped, but uncovered a significant number of cases of missing integration tests no one had thought about before. So they want to try fixing those tests this cycle to see if they can reduce the number of items they need to refer to the data team.

What I like about this pattern is that the team stays in control of their process. They have both a mechanism and a forum for trying new things, and an understanding when they try something new of being able to visualize it as an input for the next cycle’s retrospective.

If you’re interested in more, I go a little more in-depth in a separate blog post on retrospectives. And again I’ll highly recommend the book “Agile Retrospectives” as well as the book “Innovation Games” by Luke Hohmann.

Hope you’ve enjoyed this. Feel free to check out all of the FASTER Friday videos on my blog, and if you’d like more information do reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to come back next Friday for another Faster Fridays video!

{ 1 comment }

Mapping Mondays – Agile, Lean and Six Sigma

Happy Mapping Monday! Today’s #mappingmondays video covers one of Simon Wardley’s Doctrines – “Use Appropriate Methods”. It’s a quick dive into how and when to use different methods. As always, the links in the video are below, and a full transcript is included below the video. And If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!

Links:

Transcript:

Happy Monday! Welcome to another edition of Mapping Mondays. In today’s video I want to talk about what I consider to be a fascinating point in Simon Wardley’s Doctrine which is “Use appropriate methods”. On its surface, that doesn’t sound that controversial. In fact, it sounds quite desirable! Let’s use the methods that work best for us. But that’s not exactly the point he’s trying to get across.

There’s two concepts I want to give a quick overview of around Wardley Mapping to help. The first is that the key axis in a majority of Wardley Maps is the x-axis which indicates evolution of components. The idea being that all components will move from Genesis – basically uncharted territory – to Commodities or Utilities over time.

The second concept is what Simon calls Pioneers, Settlers and Town Planners as shown here. The idea is that Pioneers can jump rapidly into a space and iterate towards something interesting. Settlers are capable of taking those ideas and turning them into functioning products we can realize value from – either by selling or building on. Town Planners take those products and commoditize them.

So what does all this have to do with methods and process? What it says is that each stage and group has different needs. Early stage pioneers are going to need fast cycles and rapid iteration with a high level of agility. Methods like Extreme Programming with focuses like on-site customers, whole team and collective ownership are critical. Scrum may also be a good fit if the focus is on short iterations with feedback influencing the next steps the team takes. The feedback cycles can lead to wholesale pivots in direction very rapidly.

As we get to something worthy of being more invested in, we start to look at it from a slightly different perspective. Here we have a sense of the play towards being a product, so the focus shifts into getting analysis and feedback into the work, and getting into customers towards building a functional product. We care about iteration, but we also care about cycle times and how many steps are between feedback and teams. We also start to need more planning for things like market rollouts. In short, everything becomes slightly bigger with more people (and teams!) involved. So Lean methods – especially Kanban – become a critical tool. Feedback cycles here become focused on modifying the direction of the product towards improvement and market needs.

As we’ve productized something – or as we roll out a productized or commoditized item – we tend to shift again towards more industrialized needs like project plans, scale, analytics and efficiency. So our methods shift more towards Six Sigma or Sequential processes, still incorporating feedback but more as a corrective force than a transformative one.

I find all of this interesting because organizations tend to struggle with a single method, let alone managing three different ones! So the tendency is more for them to adopt a single Agile (subway map) method (cough SAFe cough) and try to use it to cover all bases rather than focus on understanding their market, evolution and the appropriate methods to use for it.

If you’d like to learn more about Wardley’s Doctrine and the Pioneer – Settler – Town Planner approach, I’ve included the links here and will also post them in the blog post for this video.

And if you’re interested in learning more about how organizations can have high levels of business agility and use a variety of methods feel free to reach out on Twitter at Cory_foy or via email at hello at coryfoy dot com. And be sure to check out all of the Mapping Monday blogs posts on my site.

Until next time, have a great week of mapping!

{ 1 comment }

FASTER Fridays – Prioritization and Sequencing

Happy Friday! This week I started a new series around Mapping and Strategy and I’m excited to announce the start of a second series I’m calling #fasterfridays. FASTER is an acronym for a method I developed to help organizations deliver faster (it stands for: Form, Align, Sequence, Test, Execute, Realize). The heart of it is a combination of Lean and Agile techniques, and this series is designed to share short videos around these topics you can use in your teams and organizations.

This week’s video covers how you can approach challenging prioritization or ranking sessions by thinking about the terminology just a little differently. You can watch the video below, and I’ve also included a complete transcript at the bottom. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com. Have a great weekend!

Transcript:

Happy Friday! Welcome to a new edition of FASTER Fridays. In today’s video, I wanted to share a little terminology trick I use to help teams and organizations figure out the order they should do work in. Let’s bring up a little backlog. It looks good! We have post it notes, and things on them. But one problem – what order should we do them in? Does it matter?

Typically we’d call the notion of ordering things “prioritization”. Which is good! We should understand from a relative perspective how important work is. But I’ve been a part of more than one prioritization session where multiple items end up with a priority of “1” – or whatever we’re using to indicate the top most thing. For example, preventing fines is a pretty critical initiative, but so is being able to close more sales.

To sidestep this, I separate out the notion of prioritization from sequencing. In other words, we absolutely should know how important the work is, but we also need to know what thing we should tackle first. And that might not always be the top most item.

For example, let’s imagine we have a backlog of features we want to tackle. We prioritize them and even manage to not have duplicates. But then we ask – is this the order we should go after these features? As we discuss them, we realize that a lower ranked feature would actually cause some unblocking of key system debt which would enable higher ranked features to be done more quickly. Or we have a higher ranked feature which has a dependency on some system which has a delay we can’t unblock. It’s even possible something is higher ranked because of negative connotations (maybe fines or some other bad outcome) but lower ranked features actually generate enough revenue to cover the bad outcomes for a little while.

So next time you are struggling with a prioritization session, let the duplication happen, and then talk about sequencing. You might find it changes the conversation into something much more productive!

If you’ve enjoyed this, feel free to check out all the Faster Friday videos on my blog, or reach out on Twitter at Cory underscore Foy or via email at hello at coryfoy dot com. And be sure to come back on Friday for another Faster Friday!

{ 1 comment }

Mapping Mondays – Gameplay

Happy Mapping Monday! This week starts a new series of videos highlighting how I apply Wardley Mapping concepts for my clients and how you can think about them for your own business. This week’s video covers the basics of Gameplay, highlighting the idea of separating out and being deliberate about Where you go after opportunities versus How you’ll actually act.

The links at the end of the video are below, along with a complete transcript. If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com.

Links:

Transcript:

Happy Monday! Welcome to a new edition of Mapping Mondays. I’m Cory Foy, and in today’s video I wanted to cover Gameplays and why you should care about them when you’re thinking about strategy and action.

When I say gameplays, I’m specifically referring to types of actions you can use to act towards a goal. In other words, this is How you would go after a market. As an example, you might use an Education gameplay to help customers understand a market better – and why your company is the best choice. Or you might use a Fear, Uncertainty and Doubt play to “help” customers see why your competitor is bad.

This chart, from Simon Wardley, also mentions a critical piece of information – these are Context Specific Gameplays. What does that mean?

If we look at John Boyd’s OODA loop, what it means is that we’ve Observed the situation, we’ve Oriented Ourselves to it, and we’re making decisions about how we’re going to Act. But throughout it we have the context of where we are in our environment, and the best place to take action. Or putting it another way

Separate the Where we’re going to make a play from the How we’re actually going to Play

Let’s take the Tea Cup example from Simon. Wardley Mapping gives us context for our components and how they’ll evolve, which presents us options for Where we can play. Gameplay (and Doctrine, which we’ll talk about in another video) provides us actions we can use together to form a hypothesis of action.

If we wanted to tackle “Tea”, we have several plays. We could leverage Brand and Marketing to keep our product top of mind. We could use FUD to subtly suggest problems with ours competitors products. We could create constraints by purchasing key elements of the market, or make directed investments in growing key capabilities. We can also use Differentiation to offer innovative ways of making the tea, or exploit constraints in the supply chain or our competitors to move faster than they can.

All of these have options and tradeoffs, but now we have options and hypothesis we can test

Similarly if we instead decided to attack Hot Water, we can still use Brand and Marketing and FUD, but also do things like Create Artificial Needs by suggesting people should only drink “Sun Filtered” water. Or use a Standards Game to define a specific way water should be heated. Or be a first mover with something like “all our water is heated in a carbon-neutral way”.

Summarizing a little bit more, and tying closer to how I see strategy built, let’s say we wanted to do something in IOT. We can use a map to look at the landscape and figure out strategies, and even identify likely areas that will be places we can be at the forefront of evolving. But all of this is just “where” we attack. We still have to figure out what gameplays will be options for that play – and evaluate whether they match our business strengths and market needs.

If you’re interested in more, check out my talk from several years ago, as well as Simon’s blog post on 61 different forms of Gameplay. And check out his book in progress as well as the Wardley Maps wiki. Or if you’re interested in mapping your own organization feel free to reach out via Twitter or email hello at coryfoy dot com. And be sure to come back next Monday for another Mapping Monday!

{ 2 comments }

Map of the US showing connections from Raleigh to Atlanta to Toronto to San Francisco to Salt Lake City to Raleigh Nearly my entire adult life I’ve traveled in some form or another. In a band you drive on tour, and even when I was dating my wife I would drive from Florida to Virginia nearly every other weekend. So when it comes to traveling I have a very experienced sense of what it’s going to take when I decide “drive or fly” – and usually that means I drive if I can get there in 5 hours or less.

In our organizations, we face similar decisions – typically the “build versus buy” decision. When we want to do something we have to figure out whether we start an internal initiative to build it or purchase and configure something from a vendor. Or in a larger context, whether we simply acquire someone already in a space we want to be in.

In the book Stand Back and Deliver: Accelerating Business Agility Kent McDonald and Neil Nickolaisen present a model called the Purpose-Based Alignment Model for aligning business decisions around one of two purposes – market differentiation or maintaining parity based on the mission of the business.

Four quadrant chart with the X-Axis as "Alignment to Business Purpose" and Y-Axis as "Market Differentiation" with the quadrants showing "Partner", "Differentiating", "Who Cares?" and "Parity"

The goal is to help us figure out how we should make certain “plays” in our business. I’ve talked before about developing a map to understand what plays were available in a hypothetical situation where the CEO has come to us wanting to do “something in the Internet of Things space”. At the conclusion we had the following map:

Image of a value chain with customer at the top and an x-axis that goes from Invisible to Visible, with an added y-axis called Evolution that has Genesis, Custom Built, Product and Commodity as steps

We also said we could make a play for the measurement, configuration and communication components. But what wasn’t answered was how we should make those plays. Let’s place those components into the various quadrants based on who we are as an organization:

Same chart from earlier with IoT Device and Measurement in Partner, Configuration and Communication in Differentiating, Server and Network in Who Cares, and WiFi and Security in Parity
  • Both the Server backend and the Network don’t really differentiate us in the market, nor do they really push who we are as an organization forward. So really what matters is whatever works for us.
  • Wifi and Security do matter, because people don’t want to run ethernet cables outside, and they don’t want their devices hacked. We don’t need to do anything super innovative here, but we should be on parity with other offerings
  • Both the IoT Device and the Measurment components aren’t really a core part of our business model, but they do differentiate us in the market. Therefore we want to find a trusted partner to build them or let us buy from.
  • Configuration and Communication are a core part of our offerings, and differentiate us in the market, so we should ensure our focus is on these.

Does this mean we shouldn’t buy things to help us with components in the Differentiating quadrant? Not at all! Instead it means we shouldn’t just outsource it – we need to own the Intellectual Property so we can drive the evolution of the component. Basically we want to develop the capabilities in those areas, so we should invest in building those capabilities out.

Graphic showing the Wardley Map and the PBA model with a line showing configuration is the strongest play we have in each of them

Taking together with the Wardley Map we can see that so far we have a strong agreement that the play we can make is in the Configuration and Communication spaces. And we have a sense that rather than purchase that capability, we should own that expertise in-house, either through building it, or acquiring a company who has it.

On a lower level, I tend to use this model as a way of helping smaller organizations figure out where to spend their time. For example, if their strong innovation comes from user experience, then they may find strength in partnering for development. However, if the innovation comes from the development they are doing, then they should focus on growing it in a high-quality way.

For more information I’d recommend picking up Stand Back and Deliver: Accelerating Business Agility or skimming Kent’s article on it. You can also watch a talk I gave on combining mapping, purpose-based alignment models and the Business Model Canvas. Finally, if you’d like help mapping your organization, give us a shout!

{ 0 comments }

Mapping Your Way To Success

Google Map picture of an island in a lake in an island in a lake Ever seen an island in a lake in an island in a lake? This unusual combination exists, and you can go check it out. I included a map above for you to find it. Go ahead, I’ll wait.

Did you find it? Chances are, the “map” I gave you wasn’t very useful. It showed the picture of the feature I wanted you to see, but didn’t include any context as to where it is at in the bigger picture. Nor did it include any sense of direction to know how you can get from where you are to where it’s at. If instead I gave you a link to the Google Map of it, you could then zoom out to understand the context, and plot where it was in relation to where you are.

We often operate as businesses with similar types of limited context. We have a feature that sounds great, but no sense of how we get there, or whether that would be the right thing to do with what we have. For example, if you are in Europe, you’ll need an airplane (or at least a boat!) to see that particular island. But if all you have is a bicycle, then you might want to look for something a little more accessible.

A couple of years ago I gave a talk about figuring out what things a business should go after. It started with the notion of mapping the landscape and what options were available – known as Wardley Mapping. The basics are that you start with the needs of the situation, visualize the components needed to meet those needs, and then map out how those components evolve to understand what “plays” you can make.

Let’s say our CEO wanted to get into the “Internet of Things” space starting with a device that lets people measure the weather and automatically report it back (We’re leaving out the process we used to come to wanting to do this, which in most businesses amounts to basically throwing darts). We’re supposed to start with user needs, but since “IoT Device that Measures Weather” is our charter, let’s start there.

Image of a value chain with customer at the top and an x-axis that goes from Invisible to Visible

In the above image, the Customer “needs” an IoT Device. But from there we start getting into some interesting things. The IoT Device needs ways of measuring the weather, configuring the device, and communicating the measurements. In turn, communicating the measurements requires a server to talk to, WiFi to talk over, and security to make sure no one hacks in. Of course, both the Server and WiFi require a Network to talk over.

At this point we’re only marginally better than the initial Google Map image we started with at the top. Sure we have a pretty picture, but it’s not telling us much. So let’s add the concept of motion – or in this case, evolution.

Image of a value chain with customer at the top and an x-axis that goes from Invisible to Visible, with an added y-axis called Evolution that has Genesis, Custom Built, Product and Commodity as steps

Now we have something interesting. It turns out that there aren’t really any measurement devices out there for IoT devices, so it’s in its Genesis. The IoT Device – along with configuration and communication – all exist, but need to be custom built. However, the protocols for communication, including WiFi and Security, can all be purchased as Products, and both the servers and networks we’ll talk to are basically commodities we can just use.

It’s interesting because we start to see where we can make a play based on who we are. For example, one should never get into a land war in Asia, nor should one fight a battle for something that’s a utility unless you have the resources to back it up (For example, Verizon has products specifically for IoT networks making that probably not a good decision to break into as a startup).

But the measurement, configuration and communication pieces will all eventually evolve into products. That means we can have a strategic advantage by figuring out how to lead and accelerate that evolution. So while measurement might not be something a lot of IoT projects would need, they almost all would need Configuration and Communication.

How we make those plays depends upon many other elements, such as how they align with our business purpose, and how they fit into the capacity we have. But at least now we know how we can dazzle our CEO’s desire to have an IoT weather product – while still making it something that stands a chance of being a smart play into the space.

If you’re interested in learning more, start with Simon’s introductory mapping post as well as his book in progress. You can also see the slides and videos from my talk. And if you’d like help understanding your organization, give us a shout!

Update: I said above that seeing the evolution is “interesting” – so I recorded a little video to dive into that a little deeper:

{ 1 comment }

Building Trust Through Cadenced Retrospectives

One of the hallmarks of effective teams is trust. This applies not just to the interpersonal relationships between team members, but also to the relationship the team itself has to other teams and the rest of the organization – especially management. In a low trust environment, any attempt to bring about new changes, especially from an external perspective, are going to be hit with a double-whammy: People are naturally resistant to change, but especially when they feel they don’t trust the reason, or the change is being brought onto them without any recourse.

To help overcome resistance, one of the first things I establish in organizational change is a mechanism to give teams control over their destiny. I want it to have several components:

1) It must be a “heartbeat” review – something that happens on a regular cadence the team expects
2) It must be driven by the team
3) It must look at what the team expected to happen
4) It must let the team decide how to change things to fit their operating model

Taken together, teams can rapidly discover how to incorporate surprisingly significant change in a short amount of time. The specific process I use follows the concept of a retrospective – but I’m often quick to point out that what teams normally call a retrospective usually ends up as a gripe session rather than a regular opportunity to reflect on processes the teams want to try. Done well, it encourages the notion of experimentation, because no process is ever permanent.

For example, let’s say someone on a team wants to introduce the concept of No Estimates – breaking work down into similar sized chunks – to their team to help solve some issues they are having with sizing things in story points. The team agrees to try it, and at their first retrospective two weeks later they review how it’s going. The facilitator first starts with a simple 4-column board:

Board with 4 columns labeled Expect, Well, Less Well, and things to try

The team starts with the first column: Expect. The facilitator asks: “What did we expect to happen over the past two weeks?” The goal of this column is to review the hypothesis of the experiments we took on during the last cycle. In this case, the team expected to see a reduction in time spent estimating stories.

Next, the facilitator asks the team to talk about the things that went well. I find it important to start with the good in sequence – especially in a low-trust environment – to get people focusing on positive things initially. The team mentions that it felt freeing to not have to size things from a relative perspective, and that the goal of decomposition made it clear what their goals were.

With the positive elements identified, the facilitator now moves on to the things that were not so good. The team mentions that it was not always easy to get things into similar sized chunks without splitting things arbitrarily. It also felt like they got less done because when they counted the number of stories completed it was a lower number than the story points they normally complete.

Finally, the most critical portion of the retrospective, which is what experiments the team wants to run this cycle. In this case the team agrees that they found the previous experiment fairly interesting, and feel like they still have some learning to do to get No Estimates right, so they want to keep the experiment going for another cycle, along with trying some different decomposition strategies.

This process creates a feedback loop where every process the team uses is only ever in place for one cycle, giving them the opportunity to not be afraid of trying something new and that thing being now forever a part of their process. For example, maybe a team feels standups aren’t useful, so they can try not doing standup for a cycle. Or they want to try pairing, or Test-Driven Development. All of these things can be attempted for a cycle or two, with feedback going to the whole team about how it is going.

While the cycle feels very Scrum-like, one doesn’t need to be doing Scrum to have cadences. A team doing Kanban, or Waterfall, or any process can still establish an explicit policy of having a cadence for retrospectives. In addition, teams may choose to have additional retrospectives to focus on different areas – say, after a release which may incorporate additional exercises. I’d recommend the excellent Agile Retrospectives book for additional retrospective ideas.

Finally, any kind of retrospective does rely on some degree of interpersonal trust within the team. If your team doesn’t have that trust, or it’s a high-emotion retrospective then it’s going to take a little more time to establish that trust. Members want to see that they are going to be heard, that action will be taken, and that they won’t “get in trouble” for their thoughts. I generally recommend bringing in an outside facilitator – either an external facilitator, or at least someone from outside the team. But regardless, as the facilitator you have to make sure that your role is actually facilitating, and not participating. If you feel the need to jump in, be explicit to the group about switching roles, and maybe let someone else facilitate.

Change can be quite difficult, but establishing a process where people feel in-control of the cadence and application of that change makes implementing significant change that much easier. Keeping that process regular and consistent helps increase trust and familiarity. That trust is extended when people understand what they expect to get out of the change, can discuss the impacts, and have direct input into how to best implement the change in their sphere of influence. Taken together teams can come together and make amazing things happen.

{ 1 comment }

Waterfall, Agile and Lean (Oh My!)

Georgia WaterfallFor many people, the word “Waterfall” causes a visceral reaction – especially in the context of projects and organizations. Unfortunately, I’m starting to come across more places where “Agile” causes the same reaction of disgust and fear. The fundamental problem is that we’ve let bad management hide behind methodology and frameworks.

At their core, Waterfall, Agile and Lean represent three modalities of project delivery – either Sequential (Waterfall), Iterative/Incremental (Agile) or Continuous (Lean/Kanban). If the problem space you are delivering within is well-known and needs a sequential process, then use one! For example, if we have to move a group of people from one office to the next, there are defined tasks that have to be done in certain timeframes in a certain order. Or perhaps we are adding analytics to an existing application, but we know what the analytics are, where they need to go, and the order we want to implement them in. Again, a good fit for a sequential process.

Brushing barbecue sauce on a giant mess of cooked chicken But what if we aren’t so certain about the order or value? In that case, we want to decompose the work into increments, each capable of allowing the realization of value once deployed, and then build it iteratively – a great fit for a number of agile processes. For example, we used to cook over 2,000 lbs of barbecue chicken for the 4th of July. We would divide the chicken into increments – basically as much as would fit onto one cooker – and then constantly inspect the chicken and adapt to the conditions. We would then pull chicken off one cooker at a time, and once off, the chicken could immediately be sold (value realization!).

Or maybe we have a software project where we know the overall value potential, but not exactly how to build it. In that case, we want to see how we can divide the goals into increments that help test the value potential once released, but we still want to build the pieces inside of it iteratively, constantly inspecting and adapting so that the discovery process doesn’t slow us down.

Peach Cobbler in a glass pan But what if we aren’t even certain of the value – or even if the idea we have can be built? In that case, we don’t have the ability to define value criteria or increments – we instead have to focus on continual delivery and discovery to find the business model or business value case. This is common in startups where an organization is searching for a repeatable business model. There’s a notion in kitchens of tasting as you go to make sure you have the right balance of spices or flavoring – an example of continuous delivery. Or maybe we’re attempting to disrupt a legacy market, and don’t know exactly how customers are going to react, or what they may even need. In that case, we need a model for continuously testing, iterating and responding.

When we step away from the words, and we instead focus on the modalities – sequential, iterative/incremental, continuous – we can even start to see how things can be combined. For example, maybe we do have a sequential process, but we can still focus on decomposing and delivering it in increments. Or maybe we need an iterative cadence, but want to deliver continuously.

One of my favorite conversations was with a director of a $50mm project I was coaching. He had just taken over the entire project, and I was talking to him about agility. “I don’t believe in Agile,” he told me, “because I’ve been plenty successful with waterfall!” I asked him to tell me how he was able to see such success in waterfall projects, when so much of the industry talked bad about them. He said, “Well, we would define and lay out the plan, and every 2 weeks we would inspect the plan against what had actually been done, and then adjust the plan based on what was actually happening.” I told him I would happily do that kind of waterfall!

So don’t try to “Be Agile” any more than you should try to “Be Waterfall”. Instead focus on the modalities that make sense for your project and organization, and how the principles, values and practices from other modalities can be combined – so you can “Be Successful”.

{ 1 comment }

Incremental versus Iterative: The Church Analogy

Along the path towards agility inevitably one comes across the terms iterative and incremental. I have seen many cases where the terms are used interchangeably, even though the mindset behind them is pretty different. To understand how, let’s introduce Roberta and the Church Analogy.

Picture of woman holding a computer and talking

Roberta (in our analogy) is the lead pastor for a rapidly growing church. Her current congregation is usng every inch of space in their current facility, so they know they need to expand and build a brand new campus. But she still has to balance repairs and upgrades to their current facilities, since those are going to continue to be used while the new campus is being built.

Pie Chart showing examples of categories like existing maintenance, new buildings, etcIn our organizations, this duality of building a new campus versus maintaining the current one comes across as building new features (or gaining new capabilities) versus maintaining existing systems or running the business. Some percent of our budget will be used to fund maintenance (sometimes called “Keeping the lights on”), and some percent will be used to fund things that will help grow the business. The goal as a business leader is to make sure that the funding percentages balance out the needs, and that what gets funded in each bucket is done in a way that moves us forward as quickly as possible.

So back to Roberta. She has a plan for handling the existing buildings, but is trying to figure out the best way to tackle the new campus. She has a list of all of the things they are going to build there:

Building plans showing the sanctuary, gym, office and activity fields connected with walkways
  • A new Sanctuary, which will be where Sunday services are held, as well as special events
  • A new activity field, where they can hold outdoor activities like Soccer, softball, or picnics
  • New administrative offices for the staff
  • A new multipurpose building with a gym and classrooms

Right now they meet at a local school, and they have office space they are renting, which also has a hall they can rent out for special events.

The above list are incremental pieces of the entire vision. By completing any one of these, the overall vision gets moved forward. But which one should be first? Or should they build them all before taking advantage of any of them?

Group of women leaders sitting around a conference tableTo answer that, Roberta and her team of leaders needs to know what their needs are as an organization. She knows they want to grow the number of people that can attend (and for sure not lose anyone because it is too crowded). She also knows that the current flow on Sundays doesn’t work well because, well, they’re meeting at a school that was not designed for their needs. She also knows that if they keep growing and not moving, they may run into fire code problems with too many people. And finally, all of the money they put into the school is money not going towards their future.

These criteria can be mapped to the kinds of things businesses look at:

  • Growing the business
  • Retaining existing customers
  • Improving how the business runs
  • Regulatory compliance
  • Cost reduction

With her criteria in mind, Roberta and her team rank the things they want to build:

  • A new sanctuary would help with the overcrowding of services, but would not help with many of the other activities and events they want to host throughout the week. It’s a specialized building, so it ends up at the bottom of the list.
  • The new activity field would enable a lot of outdoor events, but would need shelter in the case of rain, as well as bathrooms and other amenities that were planned to be handled by having the activity field near the multipurpose building.
  • The administrative offices aren’t a dire need – the space they have now works, although the hall rental can be a pain, so it would be good to have some place to hold those events.
  • All of the factors point that the multipurpose building makes the most sense to have at the top of the list. It will give them a place to meet (during the week, as well as on Sundays), provide the amenities for the activity fields, and solve the need to not have to rent the hall.

Roberta and her team feels great about this ordering. Within 12-14 months they’ll have a fully complete multipurpose building with a gym, classrooms, and amenities.

If only they hadn’t stopped, they would find an even better solution.

Minimum Increments

Child kicking a soccer ballIt turns out that one of the big gaps in the community they serve is a lack of soccer programs for youth. There are several programs they can partner with that would draw in a large group of people who could all be potential attendees of the church. But the season starts in 5 months, and they aren’t planning on even starting the activity fields until after the gym is built.

Looking at the requirements for the soccer program, they have the following requirements:

  • 2 soccer fields (which don’t have to be regulation size)
  • Some sort of a shelter
  • Access to bathrooms

Taking the multipurpose building as a whole, Roberta’s team can work with the contractors to figure out smaller pieces of it they can build. The contractors state that the entire foundation has to be poured at one time, but they could then build just the bathrooms and extend the rest of the building from there. There would be a slight increase in cost to do it that way, but they could have the foundation and bathrooms done in 2 months. In the meantime, Roberta talked to the contractors about the fields – they could easily build a single regulation-sized field in two months – it wouldn’t have the lighting systems in place or the sprinkler systems, and they may have to dig up the field after the first soccer season to install those.

What is happening here is that Roberta and her team are taking the initial increments and understanding (with expert help) how they can be decomposed into smaller increments. They are then looking across all of the areas and composing a minimum increment that will solve a need or gain a capability for their organization when it is done.

Construction Begins

Laptop computer sitting on a desk with hands typing on it

With a plan locked in place, Roberta funds the plan, and work begins. The foundation pour goes very smoothly, and the walls begin being built. One afternoon the contractor calls Roberta and her team to the job site:

Hi Roberta! I know that we’ve spent a lot of time looking at plans, so what I wanted to do was have you take a peek at the progress early on to make sure this is looking how you imagine. I had the brick layers build up just to the door frames and window frames, and given where you have the activity field, I wanted you to see if this matches what you expect.

This action by the contractor involves building the first pieces iteratively, by putting a little in place, and then seeking feedback. The first iteration – putting up the door frames and windows – doesn’t give a completed increment. But it does give room for feedback from the customer (in this case, Roberta) and encourages everyone to be on the same page before moving forward.

Similarly in our organizations, we want to strive to be as iterative as we can in building increments. Specifically we want to build small slices of functionality that can be shown. My dear friend Jared Richardson refers to this as Tracer Bullet Development where each iterative slice gives us increasing information and confidence that our increment is on target. Even though the contractor could have built out all of the walls before seeking feedback, by doing the minimum he could in as integrated of a way as possible, he allowed rapid feedback and adjustment – even in a construction project!

Pulling It All Together

Roberta was able to take advantage of a new opportunity by knowing what her goals were, what capabilities were needed for those goals, what increments built those capabilities, and how the increments themselves could be decomposed across her vision into smaller increments, and then composed together in a new way. Once the increment was funded, her team was able to take advantage of the contractors iterative approach to update things with new information.

Graphic showing goals mapping to capabilities, which map to increments, which then combine into minimum increments

It can be easy for organizations to do an initial decomposition into ideas, call those “increments” and feed them to teams, especially if those teams are building it iteratively. But as we saw with Roberta and her team, being able to go one step beyond that – knowing the capabilities, decomposing the increments themselves and using the visibility across the portfolio to recombine them into increments that form exactly what we need to take advantage of market opportunities – is a level of agility that can transform businesses.

(Note: The pictures of “Roberta” and her team came from the amazing “Women of Color in Tech” project offered under a CC Attribution license to #WOCInTechChat. Thanks – they’re amazing!)

{ 1 comment }

What Is Agility?

In my last post, I gave some examples of the difference between Implementing Agile and Transforming to Agility. But like the term “Agile”, agility is an often overloaded term that means different things to different people.

When I talk about agility to clients, the conversation focuses on the agility of the business, which is different than, “we’re delivering what the business is asking us in an agile way”. Organizational agility goes far beyond the team and encompasses several different areas:

  • At the business level, the executive team is thinking about gaining capabilities by focusing on smaller increments of work that can be done in less than a quarter. The entire portfolio is sequenced to fund initiatives that take advantage of market opportunities, meet regulatory needs, and move the business forward across divisions and teams.
  • This means that specific skills are needed throughout the lifecycle, so managers focus on growing skill sets and getting the right people available at the right time by building teams or working with vendors. One specific change here is how job descriptions are written and performance reviews are implemented to focus on collaboration instead of solely on individual contribution.
  • At the team level, all of the things we’re used to still apply: good development practices, iterative delivery of work, high visibility in short cycles, integration of design, testing, development, analysis, etc. If teams are producing large, stinky piles of poo, they’ll either sabotage the efforts above, or end up being replaced.

  • At the technical level, the view becomes about technical capabilities across the portfolio, and how business needs either innovate or reuse these capabilities. This includes strategic architecture, systems evolution (and retirement!) and organizational adoption and change towards DevOps, Microservices, Mobile-First strategies, etc.

Woven throughout this is the principles of Lean Thinking – how quickly and smoothly things flow through the cycle, how we visualize bottlenecks, and how we continually learn and improve.

Amazing things happen just by gaining agility at the team level, or scaling the team level. But a business firing on all of these cylinders is an amazing thing to watch.

{ 0 comments }