Why Big Companies Need Lean Startup Techniques, Gartner

A lead-gen-y blog post, but with some good stuff, e.g.:

  • “Gartner estimates by 2021, more than 50% of established corporations will be leveraging lean startup techniques at the business level to increase the pace and success of business transformation.”
  • Nice MVP/small batch framing: “A critical challenge for many organizations will be adopting radical MVP thinking in the business (not just in IT). Businesses must define what is the least investment needed (in time, budget, resources, etc.) to test the most uncertain assumptions for the new product or service.”
  • And a mini-case study of the Queensland state government which ain’t half bad.

Source: Why Big Companies Need Lean Startup Techniques – Smarter With Gartner

Silos are often defined and enforced by workstream (in)visibility

The primary measure of progress for the Scrum Team is working software, but the primary measure of progress for the Product Owner is user stories that are “ready,” which is a very nebulous concept.

a Kanban board can make a cross-functional team feel more like a reality. In a large organization, where there are specialist systems, software, hardware, and test engineers, the various disciplines are usually not going to start performing work in each other disciplines, no matter whether or not they are on the same agile team. But by working off the same board, at least they are in the position of being able to visualize each other’s work and see how what they are doing contributes to the success of the whole program.

the advantage of lean and Kanban approaches is that they make explicit and visible the full state of a program in a way that encourages people to make good decisions for improvement to the process as a whole rather than optimizing for one part of the process. This includes the poor product owner, whose work is finished before most agile boards start.

From: “The Case for Lean: Capturing Business Work”

Team work bringing down the average

The workers were told, essentially, that they were to be rewarded for collective achievement rather than individually. So instead of maximizing individual satisfaction, which often comes through competition with other people, employees considered their impact on colleagues. The theory, which plays out in the results, is that with relative rankings, top performers reduce their effort to avoid hurting their co-workers’ egos and to prevent schisms in the team.

That’s kind of sweet actually. One would also think that the incentives are disconnected from the thing you’re trying to fix: if you had to pay for all that fuel yourself, out of your take of the margin, would you be more efficient or less? That’s probably unreliable as well. Also: you’d think these tricks of fleet management would be long solves, e.g., all that lore about UPS and Fedex trucks. But, there’s probably tons of ongoing change and variability in all that.

Also: notice the Big Data angle, the technology that enabled the study.

Team work bringing down the average

Data is easy

We live in a world of data overload, where any argument can find supporting data if we are not careful to validate our assumptions. Finding information to support a theory is never a problem, but testing the theory and then taking the correct action is still hard.

From Lean Enterprise.

How a BigCo actually got some innovation done – The Longer Story of Crowbar

Here’s the slides for the talk I gave this morning on lessons learned from working on a DevOps product in a large company, that is, Crowbar in Dell.

The abstract:

Sometimes it seems like It’s near impossible to get anything innovative, interesting done in a large company – it’s as if BigCos are goaled to prevent just that. While you can’t type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps!

I’m amazed when I find a skunk-worked project that’s blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it’s even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You’d never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the “real story,” being at Dell now after six years at RedMonk covering tech from the outside, I’ll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company.