scruminfo.com

A very simple technique to find out the root cause of a problem is to use the 5 Why’s. The number 5 is
just a general guideline and sometimes it may take a lot more or a lot less “why” questions to arrive at the root cause for a given problem.
The beauty of this technique is that it is so simple and natural, we learnt it when we were kids yet so many of us have forgotten its effectiveness. It can be used at an individual level or at a team level to reach consensus of a root cause. At a team level the diversity and different angles allow for a more interesting analysis.

The 5 WHY technique:

STEP 1

Write down the problem

STEP 2

Ask WHY is this problem occurring? Write the answer down

STEP 3

If you or the team do not deem the answer the root cause of the problem, then repeat STEP 2 until you finally
realise the root clause.

EXAMPLES:

Problem:
“Our testing activities are taking very long to complete”

why:
are our testing activities taking so long to complete?

answer:
our testing is very manual

why:
is our testing manual ?

answer:
we dont do automated testing

why:
dont we do automated testing?

answer:
we do not have testers with automation experience

Problem:
“Our tyre costs for our large mining trucks are double the cost of previous projects”

why:
are our tyres costing double for this project?

answer:
they are been replaced quicker than before

why:
are they been replaced more often than before

answer:
because there is more wear and tear

why:
is there more wear and tear than previous projects?

answer:
because the previous projects had smooth roads

why:
did the previous projects have smooth roads

answer:
this project terrain and geology is different and more rocky

why:
have we not made the roads smoother for this project

answer:
there was no initial budget set aside for this as we used the previous project costs as a baseline

Filed under: Techniques | Comments Off

Not sure if anyone has ever written a scrum poem so gave it a crack …..

It is a thing called scrum and
this is how it is done.
We talk and discuss
Then we create a product backlog without fuss

A backlog has many items , they call each one a story
and its not a document thats gives the author 400 pages of glory.
On our backlog we keep it simple, non-ambigious and plain
and this way everyone remains relatively sane

A story is a simple statement that tells us to talk more
It lets us collaborate rather than document pages up to four
The story states the fact and is easy to understand
Its not something that is confusing or grand.

For each story We ask for simple criteria on what our customer will accept
this removes long paragraphs that are confusing and inept.
So when you see it and go “oh now I see”
You wont ever want a big document again from me.

The backlog is simple even executives can read it without pain
The backlog for our customers so much to gain.
So once they see its effective way
Most of them go specs, get rid of it I say.

Each item on the backlog proritised so high value first
We work on these in order so we satisfy our customers thirst.
The customer can change their mind, they are realising what they need
And for us we embrace it, it means their project does not bleed.

So we hold a meeting and all of us talk, collaborate and share
we decide what can be done from the backlog, as we care.
We decide what is feasible and what can be done
We select the challenge and know this will be fun

So our team we commit to deliver features in a set time
its called a sprint or iteration and it works just fine.
As the team choose what and how we give you a result
we just ask you trust us, dont interrupt and cause insult.

Every day we have a meeting
We unfortunately dont provide any form of seating.
We only let those in who are accountable and care
Any intruders well for them they may get a stare.

From our daily meeting we highlight what is blocking us or making us slow
Then those with the responsibility to solve it off they go.
This lets the team carry on and produce working software
This lets your project keep moving, as we are always aware.

We use the best practices decided by the team
We talk, share , have fun and strive to our customer’s dream.
At the end of this time we show what we have done
We always give you something that can potentially run.

At the end of this iteration we have a restrospective meeting
this time we do provide seating.
We sit down and think back to what went right, what was not efficient
then we produce actions to improve us and not make us deficient.

The next time comes straight away and we start it all again
And each time we learn and as a customer features you gain.
And your product comes to reality and you see it emerge
and now you know why you have value and you did not have to splurge

Filed under: Scrum Articles | Comments Off