‘“a lack of connection between innovation teams and their parent organization. Teams form/and are taught outside of their parent organization because innovation is disconnected from other activities. This meant that when teams went back to their home organization, they found that execution of existing priorities took precedence. They returned speaking a foreign language (What’s a pivot? Minimum viable what?) to their colleagues and bosses who are rewarded on execution-based metrics. Further, as budgets are planned out years in advance, their organization had no slack for “good ideas.” As a result, there was no way to finish and deploy whatever innovative prototypes the innovators had developed – even ones that have been validated.”’
Original source: How to make innovation programs deliver more than coffee cups
“Accounting drives metrics. Metrics drive culture. Culture eats process for lunch.”
Don’t let accountants drive your innovation.
Original source: The Cost Center Trap – LeanEssays
“It’s not about productivity; it’s about value-tivity. Productivity represents the capacity to increase output for a given level of input. But this output can also be rubbish, which adds no value to the business.”
Link to original
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
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”
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
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.
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.