The truth changes. “I think I can” learn new ways to improve my personal operating system. Check out David’s latest blog post.
Language is important, especially for leaders. more good stuff from David Marquet.
Originally posted on Blog: Intent-Based Leadership:
View original 1,092 more words
I hear leaders talk about the need to “change the culture”. Since leaders are in charge of the culture, I recommend this great post for everyone aspiring to improve their environment.
Originally posted on Blog: Intent-Based Leadership:
Editor’s Note: This post is part of the series “Disruptive and Innovative Culture Change,” a weeklong effort co-hosted by Switch & Shift and the good people at Culture University. Keep track of the series here and check our daily e-mail newsletter for all posts. Don’t subscribe? Sign up.
We know that environment has a large impact on people’s behavior, yet as leaders, we are often too quick to blame a behavior on the person rather than the culture we’ve created. This is easier, because while they are responsible for their behavior, we are responsible for the culture.
View original 702 more words
This is a great post from Matthew E. May on Root Cause Analysis.
Boot Your Root (Cause)
Thursday, June 4th, 2015
Process improvers the world over rally around root cause analysis as if it were the Holy Grail of all things organizational. But is it?
Understanding the root cause of a problem certainly makes sense in the context of a present day situation carrying the potential for a correct answer or solution. In the process improvement world, problems center on reducing some form of excess, which comes in several traditional flavors…all of which center on something not working as well as it should be in a perfect world.
But the one critical place in business where root cause analysis has no real place is in strategy formulation.
I’m sure I’ll be taken to task on this by the lean/kaizen/six sigma crowd, but bear with me, because I’ve witnessed repeated attempts to apply root cause analysis to strategy, only to be met with derailment and eventual failure.
The difference between a fix for an existing process or pain point and a set of choices about the future is night and day. Process problems are generally focused inward on activities you presently control. Strategic problems are generally focused outward on the future, and forces you cannot control. In process improvement, you’re pursuing perfection. In strategy formulation, there’s no such thing as a perfect strategy, so you couldn’t pursue one even if you wanted to.
If I own a traditional taxi or limo company, for example, I don’t need to know specifically why Uber entered my market, only that they did, and that my market share is dwindling and my growth and profitability is eroding.
Looked at another way, all strategic problems boil down to a single root cause: customers are finding superior value elsewhere, from a competing offer.
This may seem blazingly obvious. But that doesn’t seem to deter organizations (and their consultants) from applying traditional problem solving to strategy development, spiraling ever downward in an endless series of “why?” questions. The result is an emphasis on drafting a perfect plan and a futile attempt to craft a detailed articulation of the perfect future for the company.
It’s unnecessary, mostly irrelevant, and doesn’t work.
Click here to read the post on Matthew E. May’s blog: http://matthewemay.com/boot-your-root-cause/
Kanban works… it’s just hard to explain how. This post may help.
Originally posted on Empiricism Ops:
I’ve been reading a really excellent book on product development called The Principles of Product Development Flow, by Donald G. Reinertsen. It’s a very appealing book to me, because it sort of lays down the theoretical and mathematical case for agile product development. And you know that theory is the tea, earl grey, hot to my Jean-Luc Picard.
But as much as I love this book, I just have to bring up this chart that’s in it:
This is the Hindenburg of charts. I can’t even, and it’s not for lack of trying to even. Being horrified by the awfulness of this chart is left as an exercise for the reader, but don’t hold me responsible if this chart gives you ebola.
But despite the utter contempt I feel for that chart, I think the point it’s trying to make is very interesting. So let’s talk about highways.
View original 1,798 more words
This is a great post from the folks at RallyDev!
What is a user story?
A user story represents a small piece of business value that a team can deliver in an iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:
- The brief description of the need
- The conversations that happen during backlog grooming and iteration planning to solidify the details
- The tests that confirm the story’s satisfactory completion
Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:
|Independent||We want to be able to develop in any sequence.|
|Negotiable||Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.|
|Valuable||Users or customers get some value from the story.|
|Estimatable||The team must be able to use them for planning.|
|Small||Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.|
|Testable||Document acceptance criteria, or the definition of done for the story, which lead to test cases.|
Why use user stories?
- Keep yourself expressing business value
- Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
- Avoid the appearance of false completeness and clarity
- Get to small enough chunks that invite negotiation and movement in the backlog
- Leave the technical functions to the architect, developers, testers, and so on
How do I write user stories?
When getting started with stories, a template can help ensure that you don’t inadvertently start writing technical tasks:
As a <user type>, I want to <function> so that <benefit> .
- As a consumer, I want shopping cart functionality to easily purchase items online.
- As an executive, I want to generate a report to understand which departments need to improve their productivity.
Try to avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system. Not all actors are end users. For example, a role could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper).
Click to read the full story: https://help.rallydev.com/writing-great-user-story