Archives for July 2019

The one thing Steve Jobs did that turned around Apple

July 26, 2019 by LaunchTomorrow 2 Comments

After a nasty battle with Apple shareholders, Steve Jobs, then the original founding CEO, was ousted. He went on to create NeXt computers (later acquired by Disney). In the meantime, Apple drifted as a company. It proliferated product lines. Lost focus. And the share price entered a death spiral phase. A few years later in 1997, he was recruited back to save the company from very poor public share price performance.

“Saint Steve” at Macworld 1998

When we got to the company a year ago, there were a lot of products. There were 15 product platforms and a zillion variants of each one. I couldn’t even figure this out myself. After about three weeks. I said, “how are we gonna explain this to others, when we don’t even know which products to recommend to our friends?”

In this keynote at 1998 Macworld, he announced early successes, such as a 3rd consecutive profitable quarter. In my opinion, one of the most powerful parts of his talk was the following grid:

In effect, after a strategic review of all 15+ product lines, Jobs decided that these four were the only products worth focusing on. Consumer was aimed at consumers and education. Pro was aimed at publishing and design. Everything else was shut down. Here was his rationale:

As a matter of fact, if we only get four, we could put the A-Team on every single one of them. And if we only have four, we could turn them all every nine months instead of every 18 months. And if we only had, four we could be working on the next generation or two of each one, as we’re introducing the first generation. So that’s what we decided to do: to focus on four great products. And the first one that we introduced of course was the Desktop Pro product.

Notice that the main practical reason Steve Jobs cited for this change is the reduced product release time, or cycle time. Or low velocity in agile terms. He could release a lot of resources. Focus them just on these 4 great products. And get out of the bureaucratic quagmire that was holding the company back.

This was the kind of “zero-based thinking” decision that a hired gun CEO would be afraid to make, but a founding CEO could find the courage to do. To implement a company redesign and rethinking from first principles, rather than just tinkering around the edges. Steve Jobs knew what life before Apple was like, because he was there. And he already had a successful “go” at building the company. So it didn’t take much to identify that the company needed to be slimmed down and focussed in order to become stronger.

Of course, there was uproar amongst developers with vested interests in existing product lines. To a lesser extent, among clients of the cancelled products. But this marked the beginning of Apple’s long climb to a corporate icon and stock market darling.

<< Help Yo' Friends

How to derive expected velocity from strategic dates

July 19, 2019 by LaunchTomorrow Leave a Comment

The contrast between ideal and real is powerful. Makes you focus.

The promise

what actually happened

By not paying enough attention to the gap between the ideal and real, you may end up with a complete blowout like Fyre Festival founder McFarland. I heard of it only long after it happened by watching the Netflix documentary. Clearly I’m not the brightest in terms of social media usage.

The biggest takeaway from the Neflix documentary I had was around McFarland’s unwillingness to face the operational realities of what he was promising. Which ultimately led to his downfall. He kept pushing back on anyone who brought him bad news, telling them to “stop being negative” or just firing them. If he had taken in the feedback earlier, he and his team could have avoided the whole blowup.

I’ve found a simple tool to help straddle the vision with operational reality.

I first heard of it from a relatively older book called Lean Thinking by Womack and Jones. Basically, it should be possible to measure what the average output rate should be in order to meet customer (or executive sponsor) expectations. They call this takt time. The term originated in Germany in the 1930s, and was basically used as an output “pulse” benchmark.

The example they used was that of a bicycle factory. In short, “takt time synchronizes the rate of production to the rate of sales to customers”, according to Womack and Jones.

Your riskiest assumptions are probably related to your prospects and customers. Establish empathy quickly with your target prospect, figure out what's valuable, and get your innovation into the market.

While initially bicycles were built in larger batches based on the orders coming in, this usually caused internal operational conflicts if multiple customers had expectations of delivery. Moreover, it usually took weeks to deliver anything. And usually the orders were late.

Bikes in Amsterdam Centraal — Photographer: Raphael Nogueira | Source: Unsplash

Instead, by figuring out that the average expected output rate was that of producing one bicycle every 10 minutes everything became much simpler. In effect, if the factory could guarantee a “pulse” of output at that rate, they would be certain to meet typical customer expectations. This required a significant change in the floor layout of the factory, upskilling employees to be more flexible, and change in production processes.

Here is a smaller scale example of the change in mindset of what needs to happen at the factory, in order to deliver to a takt time:

Same amount of time, different workflow, different results

But ultimately they invested enough time and effort to get to the required level. Which meant that their customers always got the right number of bikes on time. Which was a big change from before.

How does this work?

Let’s say you need to deliver 59 orders of 192 bikes on average in a year.

takt time = available time / customer demand

= 235 business days / 40

= 3.98 days per order ~ 4 days

If the bikes are relatively similar across the board, you can reduce it to a much more granular per bike time:

4 business days/ 192 bikes

= 6 * 8 * 60 = 1920 minutes

So effectively to meet this level demand the factory needs to deliver 1 bike every 10 minutes. This is a pretty objective measure and one which is observed every 10 minutes, so there is a high frequency of potential observations. You’ll know pretty much in real-time whether that pace is being achieved or not, by looking at a well-placed stopwatch.

Obviously the aggregate volume of orders may increase or decrease over time, and takt time will need to be adjusted so that production is always synchronized with demand. The production slots created by the takt time calculation are clearly posted so everyone can see where production stands at every moment. This can be done with a simple whiteboard in the product team area at the final assembler, but will also involved electronic displays in the assembler firm and electronic transmission for display in the supplier and customer facilities as well. Womack and Jones in Lean Thinking

Once this number is calculated, you have a clear operational benchmark you need to hit. Most likely, you’ll need to change how you work, in order to make it possible to 100% complete one bicycle, if you are used to batching productions of approximately 200 units. But from a monitoring perspective, it becomes a powerful and objective way to know what is happening on the factory floor.

An even simpler example

Let’s say you’re running a hamburger stand for 4 hours a day.

What is the takt time for 50 customers? 75 customers?

Time available is 4 hours (240 minutes)

50 customers – takt time is 240 / 50 = 4.8 min

75 customers – takt time is 240 / 75 = 3.2 min

From a management perspective, you need to organize the process, system and people to deliver a hamburger within that time frame, if you want to be meeting demand as it comes in. In practice, these are averages and people might clump up and have a lot come at once, particularly if you are doing a good job. Having long queues can also be a marketing strategy. But from an operational standpoint, you have a pretty clear benchmark of how much time you have to service each customer.

The new technology case: B2B enterprise software example

In fact, with new technical products it’s relatively easy to know if your operational realities are misaligned with the same approach. Break down and contrast the expected velocity of a new product team with the rate at which they were going. (all assuming they’re building the right thing of course).

After significant deliberation for a few years, an executive team at a client finally had a view on what needs to built. There was a decent technical hypothesis for how it could work. On the market side, they decided that current clients are the best initial adopters, as they are likely to pay. But that meant the new product had to “hold water”. So we looked at de-risking the technical and delivery risk, since that was the biggest concern.

At this stage for the purposes of takt time, we were treating the project sponsors as one client, even though the product ultimately needed to be sold to a wider market. Together with around 10 experienced people, I was thrown in to figure out how to deliver on the big product vision by the given date. We started digging deeper into exactly what software needed to happen.

What actually needed to be built to fulfill the vision.

As frequently happens in these scenarios, the number of features to deliver on the vision was surprising. Or at least it even surprised me how much needs to be built before we got anywhere useful.

There was a gap between the wished for ideal and what was really possible:

We broke down the product vision into stories, and started estimating roughly how much work this would be.

The key variables here are:

Story points: ye olde mesure of complexity and “cognitive load”
Elapsed Time: both for values you expect and how long you are taking so far (if you’ve already started)
Start and Release Dates: Start was obvious. Release date was given by the executive board.

Sizing the scope by numeric gut feel

At that point, we had hashed out all of the bits and pieces and important edge cases, that coming up with a range worked as an outcome.

Gut feel after a workshop is a good estimate, even if you don’t have all of the details handy. Without a workshop…sure I can come up with numbers and estimates, but probably not that useful.

Start Date in this case was the next business day after workshop.
Release date was given from upstairs.
In terms of story points, to avoid giving the impression that this is a precise value because it’s a number, I like to provide a range. The range consists of a pessimistic (higher) and optimistic (lower) value. If I feel confident, the range will be narrower. And the opposite.
Once you have the range, figure out the total number of minutes in between the start and end dates.
Finally calculate what the implied pace is per story point. In other words, for each story point, how many minutes do you need to finish one on average (assuming the planned release date is fixed). This is called takt time in lean circles.

Case study

In the above case, we’ve got an expected takt time range between 85-109 minutes per story points. This is just an expression of either market or senior executive expectations. This analysis gives you something to contrast with what you actually observe on a continuous basis.

Simple stuff right?

Well, we were already a few sprints in at the point I’d done this analysis. Turned out we were clocking in at a cycle time of 174 minutes per story point. On average.

This type of contrast is enough to trigger a discussion. Certainly that’s what it did at the time. Ultimately, it became clear that a lot had to change if we really wanted to hit the desired dates. Or that they were just plain unrealistic. Which is fine as an outcome up front. It’s better to know that earlier to at least have the option of digging in a bit more.

In this case, we needed to improve our velocity 2.2-2.8x given both scope, date, and team composition were fixed, as we were already signficantly beyond that initial start date. And assuming that complexity estimate range in story points was accurate.

Takeaways

Of course this opened many exploratory discussion threads–in terms of what to change in the company and workflow. And how to change them. Primarily, though, it defined the scope needed as an outcome of a larger delivery system. This system was clearly inefficient. More importantly, it wasn’t up to senior stakeholder expectations.

Since we were able to highlight this pretty early, it gave us a much better work environment. Accountability become palpable. Because we were open about the unrealistic expectations before they crippled us. And objectively communicated what our current resourcing and capabilities would mean to business outcomes.

What I liked most about takt time was that it gave a clear performance benchmark for the entire team to work towards. And for me to help them get there. It helped prevent miscommunication, blame, guilt, and lots of other nonsense that would happen without this kind of an objective measure. And having a healthy and productive workplace is an ideal worth pursing in my eyes.

<< Help Yo' Friends

The only KPI checklist you will ever need

July 12, 2019 by LaunchTomorrow 1 Comment

If you have a little bit of time left, how about start writing your own bucket list — Photographer: Glenn Carstens-Peters | Source: Unsplash

This week, I’ll be a bit more concise than usual. 🙂

Metrics need to be:

Actionable: help drive activity or decisions, e.g. ratios “What will I do differently based on this information?”
Forward looking: observable now yet indicative of what will happen, e.g. nr of prospects
Representative: the number is tied to the actual thing they are meant to capture
Easy to observe/gather: defined well enough an intern can go and check them
Comparable over time: ideally they can be collected in real time/daily, and you can do cohort analysis with them to see how the change as you experiment
Mutually agreed and checked regularly with team and decision makers
Objective: not based on estimates which can be wrong or biased
Tied to the customer and customer needs
Tied to learning/improving continuously

Metrics can be tied to operations, learning or finances.

If learning-based or early stage, look at metrics on a per-customer basis. Once the exchange of value works for each customer, look at growth metrics.

Nuff said.

<< Help Yo' Friends

How to analyze the impact of velocity on your release date

July 5, 2019 by LaunchTomorrow Leave a Comment

While “agilefall” has many well documented downsides, I’ve found a counterintuitive bright side to the following aspect of it: “We have a product backlog with priorities, but we start working on a release with a long list of features already committed to the business.”

In this case, we have a pretty detailed view of scope as well as developer estimates of complexity. There is a lot of data to crunch.

From a pure business perspective, the key variable that matters is the release date. Dates have a significant implication for the rollout across the company and existing client base. Here’s a few business reasons why:

marketing and sales plans need to be made (since they’re separate “workstreams”)
overall costs and ROI of the program changes
coordination and resources need to be shared/reassigned with other internal teams

And most importantly, the date is completely non-technical. Anyone who graduated from primary school can understand it. So the nice thing is that the release dates help focus the discussion on what matters, while only needing to go into a minimal amount of technical detail.

Making the relatively liberal assumption that scope will not change, it’s possible to generate a pretty decent forecast of the date.

Moreover, it’s possible to model the impact of a higher or lower average future velocity on release dates. In other words, if there is a need for a plan, you can make the entire plan using the following approach:

dependent variables: incremental release dates
independent variable: hypothetical velocity

And then look at what happens to the release dates as you vary velocity.

unsplash image feeefeedbedb — Photographer: Waldemar Brandt | Source: Unsplash

The entire plan fees like an accordion which can be pulled out or pushed in, depending on your assumptions about velocity. If velocity is high, the releases are close together. If it’s low, they’re quite spread apart.

Here’s an example of a quick model I did by exporting my data from Jira and using Excel’s scenario manager:

velocitysensitivityanalysis ebeebaccdfcbcc — Type caption (optional)

By varying that one number and holding scope & team constant, the dates which are hit for each release change significantly. Let’s get into how to do it for yourself first.

Case Study

We’ve defined, broken out and even estimated scope for this program. It contains hundreds of stories (tasks really) related to the delivery of a big infrastructure. All of this is being tracked using a standard agile tool called Jira, with relevant details attached to each story.

Here’s the type of analysis we’ll need to do as an interim step:

versions ecbcfaacfac — Type caption (optional)

The unit of effort measurement here is the “Story Point“, an abstract measure of relative complexity of a piece of work. This is quite common in agile circles, to help give the delivery team a safe way to discuss and size the work, without biasing it towards what stakeholders “want to hear” and to help them “save face” if a complex task takes a long time (even though it wouldn’t necessarily be obvious to a non-technical person).

The key “number behind the number” here is the velocity. It’s expressed as the story points completed per unit of time. In this case: one week. Velocity tracks increments of fully complete work that has been specified, developed, checked, and signed off.

If we estimate the story points for each task up front, it’s possible to observe velocity as the team works on the scope. Basically, you see performance as the change in that number over time.

On this project, we are tracking velocity in weekly increments. This gives us more data points and increases our confidence in the numbers faster than if we were calculating it on a monthly basis for example. More observations, higher confidence–statistically speaking.

In the example above, the actual team doing the work has been delivering at a rate of 27 story points per week. But what if the average future velocity was higher or lower than that?

Step 1: Pull out the scope sizes from Jira

For me, the fastest way to get to the real numbers is to pull up reports. At the moment, most of the modelling we are doing is based on the Jira versions (fixVersion). Previously, I’ve used Jira epics using different reports.

reports fdcafaaccead — reports on left sidebar

Then choose the version or epic report:

versionreport eedbcafeaaada — here in a drop-down

And finally pull out the actual story points completed in the version:

completedstorypoints feefcbbeeffe — Type caption (optional)

And incomplete:

incompleteSP dfebbcbfbfde — Type caption (optional)

And finally the number (count) of unestimated stories, as delivery teams tend to push back on spending too much time estimating rather than doing the work:

unestimatedissues cdceebaeecdaddcc — Type caption (optional)

Remember to exclude any known bugs as these will typically have 0 story points anyway, and use your judgement for other issues.

Type these into Excel (yay data entry!):

inexcel step befadefad — typing in numbers from that report

Step 2: Create a key assumptions section

Hah! The ‘A’ word.

In your spreadsheet, put in an assumed value for the unestimated stories as the average size (in story points) of issues and the expected velocity for your delivery teams:

aumptions afbacaafcfcde — Type caption (optional)

Step 3: Fill out the remaining formulas to estimate your release date

Essentially, once we have the estimated total scope and velocity, it’s just a matter of dividing the former by the latter, to generate the number of weeks of work remaining:

firstversionestimate dfffdbddbadb — Type caption (optional)

Here are the actual excel formulas I used to generate the magic date:

firstversionestimate formulas cffadbfeaacfafdfb — Type caption (optional)

Step 4: Rinse and repeat for remaining versions on your backlog

Essentially, you are holding the team, scope, and velocity constant and using your estimates to figure out when you will be ready to release each version. This is, of course, based on what you know now, which is subject to change. 🙂

versions bfdbccacbaaaa — Type caption (optional)

The formulas are more or less the same throughout the versions. In this case, I’m assuming the team will finish version 1 and move immediately to working on version 2, so column I needed some adjustment.

versions formulas eccfbcdeceddd — Type caption (optional)

Step 5: Kick up the What If analysis using Excel’s scenario planner

First move your cursor to the variable you want to model, in this case your velocity assumption:

movecursor ecdbcaccdadcf — Type caption (optional)

This is the “independent” variable in statistical terms that you want to vary, in order to see how it affect the dependent variables you care about: the completion dates.

whatifanalysis dddadefdc — Type caption (optional)

This is probably one of Excel’s most powerful non-quantitative easter eggs. While allowing you to vary individual values, you can extrapolate impacts that reach far beyond what is possible (for most humans) intuitively.

selectscenariomanager afdbfdadeffacaaefcb — Type caption (optional)

Within there, choose the Scenario Manager, and the following comes up:

blankscenariomanager defdffc — Type caption (optional)

Click add, and then use the cell you selected previously as the main variable to vary:

baselineveloctity ddcbeafeed — Type caption (optional)

You can call the scenario whatever you want that has business meaning to you and your company. Then enter a value for this scenario in the next prompt:

enterscenariovalue ceafaba — Type caption (optional)

And then do this again for a few other scenarios. In this case, I created a higher velocity at 60 and a lower velocity at 20. This range is so wide, simply because I have no data to go on, so I’d like to explore the optimistic and the pessimistic scenarios.

When you have all of this done, and the scenario manager is correctly set up, click on summary:

scenarios bdaacdfdb — Type caption (optional)

Based on that, Excel asks you which cells in the sheet you actually care about when you are varying scenarios (the dependent variables):

dependentvariables dbcebddbddc — Type caption (optional)

And after you hit OK, Excel hangs for a bit and returns with the following magical table:

scenariosummary bfcfdabfedefb — Type caption (optional)

This gives you a sense of how different average velocities will affect your delivery dates and plan. It gives you a qualitative feel for what would happen anywhere within your range, too, by looking at the outer boundaries. It’s enough for you to take and present to stakeholders in terms of what the velocity number actually means, what tradeoffs might need to be adjusted, what resources added, and all of the other things which might need to be changed to influence velocity.

Of course, you’d want to make it a bit prettier and clarify what these things mean:

velocitysensitivityanalysis aacdeedcbdeb — Type caption (optional)

Ok, now you’re talkin’! So we are finally at the velocity accordion state. Depending on what velocity we end up getting out of the team, these are the dates we expect to hit for each incremental release. As you can see, the difference between doing the entire scope at a velocity of 20 vs 60 is over an entire year out. Even if all of the details of what is delivered are exactly the same, done in exactly the same order, by exactly the same people, there more than an entire year of difference in the final release.

In other words, detailed planning this far into the future should not include commitments to dates–even if you do have your entire backlog defined and specified and you’re hoping it’s “accurate”.

Figuring out your velocity and how to increase it has much greater business value (bringing release dates in) rather than trying to specify and estimate everything up front to the utmost detail.

This is particularly true in a corporate context with large budgets and a need for “saving face” in case the product isn’t fully perfect before it’s even discussed with prospects or existing customers. It’s much better to commit to small increments of work that are then tied to specific customers needs, as that is the shortest path to revenue in an enterprise sales environment. On top of that, focus on managing velocity and not detailed planning, as that will get your product out there faster. Ultimately your customers could care less how detailed your release plan is; they just want a product that addresses their needs.

Keep following the story

I’ve written a book on speeding up innovation. Check it out over here.

<< Help Yo' Friends