≡ Menu

FASTER Fridays – Story Points

Happy Friday! This week’s #fasterfridays is a great watch if you have hidden work in your teams. We talk about using story points – as opposed to hours – to generate insights across some different categories of work. 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, and welcome to another edition of FASTER Fridays! One of the insights I like to help organizations with is an understanding of how they spend their time. But there’s a catch – measuring how people spend their time is itself an activity, and if done in too much detail, or with too much burden, can cause its own set of problems.

To solve this, I use something with a lot of information already out there – story points! I really like them because after the initial figuring out of how they work, teams can run with them. Unlike how story points are taught, I want teams to try story pointing lots of activities – not just user stories.

As an example, let’s say we think we’re spending a lot of time on maintenance activities or paying off technical debt. We would put a card in whatever tracking system we’re using – from Jira to Post-It Notes, and size it like any other work. We can then see the balance of feature work to maintenance work to see if we’re investing properly.

I also like using them for bugs, defects and escalations. Traditionally these are trickier because it’s hard to know up front how long it will take. So what should we do? Post-size! That’s right – I’m not trying to get teams to be clairvoyant – instead trying to get them insights they may not have.

Combined together, we can generate pictures of how teams spend their time. And across clients I tend to find interesting correlations between teams which have a healthy balance of maintenance work and feature work – when that investment is skewed towards feature work, we tend to see time spent in escalations and defect resolution rise.

But that’s not the only picture we can tell. Sometimes it’s not about the mix of work, but about the types of activities highlighting organizational or tool gaps. This graph shows similar point tracking, but categorized into value work – which would be feature, maintenance, tech debt – and enablement work – in this case, work setting up environments for deployment, manually testing deployments, etc. What we found is that the lack of a staging environment was costing this company around $2mm a quarter in enablement work when they did their deploys. We were able to use these insights for cost justification for a new staging environment, and also were able to show the associated drop in costs once it went online.

Finally, I’ve been asked before about why not simply use hours and time tracking. There’s two reasons for that. The first is that it can be a burden to collect at that level, especially for teams. But the bigger reason is that I often work hard to keep executives from wanting all estimates in hours and Gantt charts. If we switch back to hours-based estimates and tracking, even for something like this, it says that points and relative sizing are not good enough for “real work” and can end up with them totally ignored.

So if your teams seem to have lots of ancillary work stealing time from what they want to be doing, try capturing and sizing it, and then looking at the aggregate numbers. You might find some really interesting insights that open the doors for adjustments and improvements in the way you work.

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!

{ 0 comments }

Mapping Mondays – Value Chains

Happy Mapping Monday! Today’s #mappingmondays video goes back to basics and covers the notion of looking at User Needs as well as constructing a Value Chain and ultimately turning it into a map by applying various aspects of motion and direction to the components. 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:
Over the past couple of weeks we’ve talked about various Gameplay and Doctrine in relation to Wardley Mapping. But all of this makes a critical assumption – that our maps are solid. But we haven’t talked as much about what is in these maps or how they’re formed. So let’s touch on the core of building a map – the Value Chain.

In its simplest form, the value chain starts with a set of user needs and lists the components necessary to deliver those user needs – and the components necessary to deliver those components. As an example, let’s say I wanted to write a hit song. I’m going to need music and songwriting. And I’m also going to need a way to record, publish and distribute the music. For song writing I’m going to need a sense of musical theory, as well as research into what constitutes a hit song right now. We can go further and talk about instruments, lessons, recording equipment and many other components.

So far we have a graph of components connected to a single user need. Is this a map? No, not yet. One of the key distinctions Simon makes in his discussion about maps is that we need direction and movement to turn a graph into a map. The primary axes we see are component evolution from Genesis through Utility, and – less important – the visibility of the components. But do these have to be the only directional guidance? Not at all! We could try overlaying things like Roger’s Diffusion of Innovation Theory (made popular by Geoffrey Moore in Crossing the Chasm) and looking for components getting ready to “Cross the Chasm”. Or we could overlay the Dreyfus Model of Skills Acquisition to think about how we help our users progress in their knowledge of the components. The point is that we need directional capabilities for the components to understand how they’ll move in our space and where we can make plays at.

Speaking of users and their needs, we started with a single user with a single need. But often we have more than one user – or even differentiation between customers (people who buy our product) and users (people who use our product). They are going to have a variety of needs, and it’s worth mapping out those needs and the components necessary to look for overlaps and strategic advantages. Make a product compelling enough and your users can override the challenges in procurement and purchasing. Or make it easy enough to purchase or integrate and it might become a de facto standard even if the users don’t care for it.

But ultimately it’s important to have hypotheses and test them out with maps. If you think you have a strategic advantage, that advantage should be articulated on a map and obvious when it is. And then spend a little more time trying to poke holds in that obviousness.

If you’d like to learn more about Value Chain Mapping and User Needs Analysis, you can start with Simon’s seminal post on it as well as the chapter in his book. You can also look at some ideas from Jeff Patton and his User Story Map. And finally, check out both the Dreyfus Model of Skills Acquisition and Moore’s Crossing the Chasm. 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 applying mapping and strategy within your organization 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.

{ 0 comments }

FASTER Fridays – Relative Sizing

Happy Friday! This week’s #fasterfridays touches on one of the more challenging parts of software development – estimation. We talk about Planning Poker, and then touch on Team Estimation which approaches estimation from a different perspective with the same goals. 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! Welcome to this week’s FASTER Friday. When I first created Mapping Mondays and Faster Fridays, I knew I was creating a commitment to be able to deliver two videos per week. That commitment wasn’t based off of a wild guess – I had an idea of how long things would take – estimates if you would.

In our teams, we also want to be able to understand what we’re able to commit to. There’s a large variety of ways of doing this – from Cycle Time to Story Points both of which I have articles I’ll link to. Interestingly both methods require a form of sizing – for Story Points to get the actual story point, and for Cycle Time a way of understanding different sizes of work flowing throughout the system to know what our expected Cycle Times are.

Unfortunately, the primary way we talk about sizing work is using Planning Poker. Planning Poker – which is a great exercise – is where a team has a deck of cards following the modified Fibonacci sequence – 1,2,3,5 and so on. They then pick a story from the backlog, read it, discuss it, and then vote on it by each member picking a card and then everyone showing their card at the same time. The lowest and highest then talk about their perspective and there’s a revote, with the goal to get consensus.

However, while notionally we use this as a sense of relative estimation and sizing, the mechanics require us to already have a notion of time mapping in our heads. So instead I try a Team Estimation game which removes points completely until the very end. Here’s how it works.

We still start with some backlog of work we want sized, and we still pick the stories up one by one and discuss them. But then instead of voting on story points or t-shirt sizes, we lay it down in a column. We then lay the next one either below, to the left or to the right of the first one, depending on if we think it’s about the same size, smaller or larger. We then continue going through this process until all of the cards are in columns.

At this point, if we’re primarily focused on flow and cycle time, we can ask whether there’s enough difference for us to track them separately. However, if we want story points, we can now use planning poker to size each column, instead of each card.

What’s nice about this method is we have the ability to insert columns during the initial process, or consolidate at the end. Basically we can focus on the cards and how much work is in them rather than trying to map to a specific pointing process. We also don’t have to be strictly linear in our sizing of our columns.

So if you or your team find yourself struggling to size work, try not sizing it and merely placing it instead. It might help drive out the conversations around the items, putting the focus on collaboration instead of points.

If you’re interested in more, I go a little more in-depth in a some blog posts on sizing, even sizing in Kanban. I’d also recommend checking out Mike Cohn’s “Agile Estimating and Planning”

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!

{ 0 comments }

Happy Mapping Monday! Today’s #mappingmondays video covers a very powerful gameplay called Innovate-Leverage-Commoditize where you allow others to figure out the market for you, and then simply commoditize what they discover. 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, and welcome to another edition of Mapping Mondays! Often when we look at Wardley Maps, we look for opportunities to act by moving components between phases – productizing a custom built component, or driving a component towards utilities. But what if we can get other people to tell us where we should make our plays with minimal investments on our part?

That’s the heart of a specific gameplay known as Innovate-Leverage-Commoditize. Many of us are familiar with Amazon, Google and Microsoft’s products which provide computing power in the cloud. We can think of this as a utility – basically something we just turn on and off like electricity. If we’re not one of those providers, we can use this to our advantage. Often companies in the Genesis or Custom Build phases are looking for products or platforms they can use to build things with. So let’s take a space that hasn’t been commoditized and expose an API – in this case, we’ll expose social media feed access as an API, built on top of compute as a platform.

We then launch this API to the broader world, and people begin taking advantage of it, building interesting new mash ups of data, all using our API. We’ve now enabled a whole series of innovations to occur on top of our platform – meaning we’re both an enabler and have the ability to see the metadata of usage to analyze where the really interesting moves are.

As we see usage continue to creep up, we Leverage this data to spot patterns. We then move up the stack a level and fully Commoditize a portion of that – potentially disrupting other business models in the process. Now we’re even more entrenched in the market because we’re the default information provider and we have the core products. If we’re following good Doctrine, we’re doing this in a way where we are also a joy to use, so people are more likely to keep building on top of us, allowing us to continue exposing other high-order APIs, watching people use them, and then leveraging that knowledge to Commoditize additional markets.

The tricky part about this is disrupting this flow once it is in place isn’t a matter of outcompeting in parallel. You have to clearly map your market and understand the higher level components and the plays necessary to productized or commoditize above the currently commoditized layer, effectively attempting to control the information flows above the platform. This can take some really forward thinking, but without it you might end up continually playing catch up.

If you’d like to learn more about ILC, Simon Wardley has a great chapter in his book on it, as well as a fantastic Twitter thread. 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 applying mapping and strategy within your organization 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 – 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 }