No matter how good we are today, there is some way in which we could be better. Let's consider how...

Hero culture is a situation where one person, or a small number of people, take on the majority of the work, and others start to step back. If you hear things like =E2=80=9Cthese people don=E2=80=99t pull their weight and I have to do everything for them=E2=80=9D, you may not have lazy people at all. You may have the effects of hero culture destroying the teamwork that you should have.

I=E2=80=99ve written about hero culture before and I=E2=80=99ll let you read it there instead of repeating it.

It=E2=80=99s quite common to have a team of people where there is one senior person and many less experienced people. This arrangement does not necessarily mean that we=E2=80=99ll start to develop hero culture, although it=E2=80=99s a very real possibility and something we need to watch for.

Left unchecked, hero culture will result in the =E2=80=9Chero=E2=80=9D burning out and everyone else so thoroughly disengaging that nothing gets done. Nobody wins when we let hero culture take over.

Last week, I read Shatter the Hero Culture: Organizational Strategies to Boost Teamwork, which is the first book I=E2=80=99ve seen on this topic. The author does an excellent job of explaining the fundamental problem and providing specific steps for undoing it.

I see hero culture at just about every company I work with. Sometimes there are just one or two heroes and sometimes it=E2=80=99s everywhere you look. If you see it in your environment, this book may help.

In the days that we wrote user stories on physical cards, we deliberately handed out small pieces of paper and large sharpies. We wanted fewer words on the card and set up the conditions to encourage that.

The card was intended to be the promise of a conversation, not a detailed requirements document.

People who write stories in systems like Jira often miss that point. Those tools allow us to write novels, and so we do.

Why does that really matter? We have to figure out the details at some point anyway, so why does it matter if we do it up front in a detailed document or later as we=E2=80=99re about to build it?

It=E2=80=99s a question of risk management. The risk in this case is that we=E2=80=99re building the wrong thing.

Back when agile was first starting, the Standish Report consistently reported that 30-50% of all features that were specified up front were never or rarely used. That=E2=80=99s 30-50% of our analysis work being complete waste. One of the goals of agile was to drop that percentage significantly. To only work on items that would be used by our customer and that would therefore be valuable.

We talk a lot about the flow of value through a system but a feature that doesn=E2=80=99t get used isn=E2=80=99t valuable. We don=E2=80=99t know if it=E2=80=99s valuable until it=E2=80=99s in the hands of customers and we discover if they even use it.

In the early stages of planning, we have so many ideas and while many of them will be valuable, some won=E2=80=99t. Given that we=E2=80=99re are constantly learning as we deliver more pieces of value, the longer we can wait before making the next decisions, the better we=E2=80=99ll able to predict if a thing really is valuable.

So we want to defer as many decisions as we can. That means deferring all the effort we put into all the specifics of the story for as long as we reasonably can. This means writing as little on the card up front as we can, and deferring all the details until the time that we absolutely need them.

The card is now =E2=80=9Cthe promise of a conversation=E2=80=9D, that we=E2=80=99ll have at the right time.

For more information on anything I normally discuss or you'd like to know how to reach out to me, then see my follow up page. I offer training and consulting services around all of the things I discuss here and would be happy to help your organization.

Also, if there's something you would like to see in this newsletter or would like me to share insights on, feel free to reply to this email, and I'll see what I can do.=C2=A0

Was this newsletter forwarded to you and you'd like to sign up for your own copy? Sign up here.

Reminder that all your products, including Flow Metrics Basics can always be found here.

Mike Bowler