I write this under the self-experienced impression of transitions in software creation from waterfall to somewhat scrum-alike. But, the point is of wider, more general validity, especially for once successful organizations.

I write this in English, because several words I intend to use are of double or triple or slightly different meaning in German – greetings to Doosie.
So, to work it out more precisely, I do it in English.

Let’s dive into the topic

Imagine there is no knowledge, no experience and nobody You can ask. What are the states an action can result in?
Success – failure and undefined (unknown, something in between, future will show …).

Imagine further, to keep it simple, the chances are distributed evenly.
So, the probability to succeed is not what You might intuitively think by 50:50.
It is 1/3 (33%)!

 

1. 33% chance of failure
2. 33% chance of success
3. 33% chance of undefined!

 

 

Let’s go one step further and imagine there are some players in the field of Your business. In “scrum by the book” it is the scrum-team consisting of the PO, the developers and indeed the Scrum Master.

But, if You face a formerly somehow successful organization there is “the management”, residing somewhere “above” in the pyramid of that organization. In reality, it is represented by at least one manager who sponsors “all this”.

Imagine, they are all partners that are “all equal”. Don’t laugh at that point. There are lots of organizations where managers treat their “managees” 😉 as equal (not as sub-ordinates!) and vice versa. They are all of best intentions – as far as they can look, think and act.

But, in fact the power is divided and so are the individual chances to win. It is divided in one quarter to the manager, one quarter to the PO, one to the dev-team and one to the scrum master. They all together have a chance to succeed by 33% (remember: no knowledge, no experience, no one to ask, no “guiding star”).

Each of these four involved parties have a chance of roughly 8% to do it right – 33% divided by 4, because only if everyone does it right the probability of 1/3 chance to win is fulfilled.
“Surprisingly”, the chance for an organization to survive the first seven years on the market is measured “in reality” at somewhere between 5 and 10%.
That’s what I got aware of in a recorded speech of Gunter Dueck. When I find the time to do some research on this, I will link sources. Until then – just believe me. 🙂

If You are one of the developers in the team, You share something between 5 to 9 times a quarter (something between 2% and under 1%) of the chances to succeed.
It seems that You are pretty f**** up.
And that might explain why some people in a group of workers (not a team, yet) imagine themselves to have no power at all!

Your chances are bad and what will You do about it?

When someone faces uncertainty and has only the abstract imagination it might could fail, most people return to the point where they believe they were “safe” and therefore believe they are safe. That is human – stupid.

But are they successful in doing that? No, they are just not dead … yet.

How often You can afford do go forth and back until Your resources run out?
One time, two times, three times?
And where does that behavior brings You to? You might intend to save resources and will not do any step at all.
But what You forgot by this is fixed costs of living!
You consume – energy and material and time to live by just being You!

So, You have the obligation of life. You have the unspoken duty to gain some use of Your pure existence.

So, face the challenge to preserve what You have by obtaining what You go for.

Why startups apply “the new” easier?

Startups do better in applying the most recent hot shit.
Because, there is nothing, yet. There is nothing to fall back to, nothing to rely on, nothing to go back to when the times get rough.

And the mature organisation? Was it so bad in the past?
Obviously “we” are not so bad – we survived until now – we are not dead in present!

Have a look at some biases that might explain why You are in trouble. Probably not today, but tomorrow or next year.

What can everyone do? Iterate!

First of all, be aware of Your bad chances to win.
From the moment, everyone accepts that and considers it in daily acting, You first have the chance to win by intention – not by random.

Now, everyone can and must concentrate (not focus!) on assuring success.

Good news: You can increase Your chances by teaming!

First of all: connect to Your co-workers. Make sure You understand where You (singular) are and where everything should lead to.
Second, and most important step: Make sure, everyone else share the same understanding.
Hint: Tuckman-Stage 3 “Norming” or contracting.

Remember: You head the uncertain.
What no one needs is the unspoken certain and the spoken uncertainty.
You have to get certain about the certain!

You do not have to protect against insecurity.
Everyone has to assure, You (pl.) are on safe ground.

Now, You can take one step in the direction, everybody (consent-driven!) assumes to be the right one.
Where are You now? Success, failure, undefinable?

Success: congratulations! Go ahead.

Failure: step back, exactly that step You made and go a (slightly?) varied direction next time.

Undefined: now, You are in real trouble!
Why it is “undefined”? Did You succeed and cannot notice? Did You failed and do not know? Did someone (You!) missed to define criteria to identify success or failure?

What can You do in Your particular role?

Remember, You are all equal in front of the uncertain. You all do not know.
Beware of mixing it up with the not-yet-experienced certain Your co-workers can share knowledge of.

Managers: appreciate results! Even failures.

Remember: results are certain – expectations are not!

By gaining results You gain knowledge. Knowledge gives You a position from where You can choose direction.
So, welcome any early result and propose (sic!) directions everyone – including Yourself – needs.

Product Owners: focus on small steps!

What is about the “big story” which You expected to be “the great success” but could not be completed the way You “expected”?
It is still rubbish (not waste/muda!) and in many cases a dead end in the development of “Your” product.
You fired lots of resources through the chimney, because of Your personal hubris.

Customers decide about success and failure! So, ask them often and ask them early to save resources and get directions.

Developers: ask all about the “seem to be self-evident” stuff

What might be self-evident for You must not be self-evident for all the others (co-workers, PO, managers, customers etc.).

Did someone ask for consolidation of style sheets of some external bought templates?
Someone might do in future, when changes occur more often. But now, at the very beginning of the approach?

Scrum Masters: let fail happen early!

Jan Fischbach reported a quote of Jeff Sutherland to me: “scrum is a feedback machine”. By doing scrum, You have the chance to get feedback more often and in better bitable chunks than doing any other “project management method” known, yet.

Sprint length

How long should a sprint take then? Remember, the result of a sprint is a potential shippable software. So, propose (not decide!) a sprint length in which the dev-team will be most certainly able to deliver usable software – with all that test automation, user probing, staging etc.
And suggest a sprint length that corresponds to the amount of uncertainty!

Most sprint lengths I experienced and heard of were two weeks. Just like everybody silently agrees that length. But is that right in any case and stage of Your development?
In the beginning, everybody needs direction within their individual uncertainty. As the project gets a little more mature, You can focus on reducing overhead (reviews, retros, planning meetings) and extend sprint length. So, why not starting with a really small backlog (one to three or five items) and a sprint length of one day? Or even one week?

Switch to Kanban?

And from the moment as the team is “ridden in”?
Make Yourself unnecessary and let the organization get rid of Your role?
Depends … for some (software) products, Kanban approaches might work. For some aspects in software development (“support”, “hotfixing” etc.) that might also be suitable.
Why? Because, these actions target to regain a certain, known, defined state.
But, as long as Your organization deals with the “real uncertain”, You should stay on the “real” scrum approach. With or without You as an individual.

In the end … some math again

If You accept the 33% chance in success, You surely want to increase Your chance. Where can You tweak?

First, it is all about effectivity

Tweak on efficiency not before You reach total effectivity.

Increasing efficiency first makes sense when everybody can swear on doing the right thing.
If You do the wrong things more efficient, who would appreciate that?

But You do not need to wait for the product to be the perfect right.
You can start at areas of Your environment i.e. meeting habits, review facilities, deployment, test-automation or comparable “easy” tasks.

Let’s come to “everybody”

You might be a little perplex on Your chances (Your personal share of one quarter of 33%). So, what can You personally do?

• Make the divided chances one again.
  That increases Your chance by 3 to over 30 times – depending on Your role and the number of dev-team members.
• Make everybody (manager, PO, dev-team, scrum master) heading in the same direction.
• Make everybody agree on the approach!
• Make everybody agree on the project target/s.

And always remember: Your chances are bad – assure that You take them!