How to Talk to Yourself

Bob Hubbard:

The truth changes. “I think I can” learn new ways to improve my personal operating system. Check out David’s latest blog post.

Originally posted on Blog: Intent-Based Leadership:

When talking with others the words we use matter a lot, and they matter when talking to ourselves as well.

View original 194 more words

Why Motivating Others Starts with Using the Right Language – @99u

Bob Hubbard:

Language is important, especially for leaders. more good stuff from David Marquet.

Originally posted on Blog: Intent-Based Leadership:

The seven members of the offers team gathered for their weekly standup at the New York-based technology startup. There had been misconnects the previous week with the email marketing team and the design team resulting in an inconsistent message that didn’t showcase some of the best offers the group had worked to secure.

View original 1,092 more words

Fix the Environment, Not the People. 4 Levers for Affecting the Culture.

Bob Hubbard:

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 UniversityKeep 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

Matthew E May Advises Us to “Boot Your Root (Cause)”

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 Highway: The Least Popular Mario Kart Course

Bob Hubbard:

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:

terrible chart

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.

Highways!

View original 1,798 more words

“Too Busy” is an Issue with Clarity, NOT Time

Bob Hubbard:

Great insight from David Marquet!

Originally posted on Blog: Intent-Based Leadership:

Be attuned to when your team members are opening the door for help.

View original 229 more words

Write a Great User Story

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> .

Examples:

  • 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).

In Rally, this template should be entered at the top of the Description field. This sets the tone for the details and acceptance criteria, which will be entered below.

Click to read the full story: https://help.rallydev.com/writing-great-user-story