Scrum Master Tip #3 : Explain, Exemplify and Pratice

Being  a Scrum Master means a lot, if you do the right things.

Being a Scrum Master is like being a leader: you won’t drive the car, but you’ll set on the passengers seat and you’ll help the driver take the best route and be prepared for the risks of driving: without of course scaring him too much else you are the danger!

If you can’t seat quiet and you need to do the driving, then

you’re not a scrum master,  you are my granny.

You  should get your own car and do the things you like the way you like: it’s called self-employed.

Or, of course,  if you rather  rely on a professional driver (who probably has had more accidents and tickets than me) he will take you where you want, but the way he wants, the way he knows.

The tricky thing about being a Scrum Master is that you’ll have to grow faster than all other around you. You need to excel yourself, be prepared to suffer changes and embrace debate. You need to believe and understand things before all around you do, and while you do all this, you need to be open for all new things they will also teach you.

So first: Understand who you are:  Are you a team driver,  are you a solo driver or are you a driving teacher?

I won’t tell you what a Scrum master is or should be.

What you are is bigger than what a Scrum Master is, so what you are comes first. Then depending on whom you are,  you’ll be able to be a Scrum Master or not. But you know what? That’s not important. Important is to be happy at your work and do your best. To learn and to wake up the next morning knowing you did a good job and wanting to go to work again.

Now imagine, nevertheless the kind of driver you are, that you have this team you want to teach.

You don’t have to teach them. You WANT to teach them.

How will you do that?

1) Explain, Explain, Explain, …

If you want to help someone you need to explain the basics. Right?

Why you are doing that, why are we doing that, why do we need it, why this might be the best way to do it, what’s in it for them, and… most important: What they thing about all this?

After talking (experts sometimes call it conversation) , what’s next?

2) Exemplify, Examplify, Examplify

How do you explain Tarzan how he can wash his teeth? (If he wants to of course)

You can do it in different ways, but  the most efficient, in a way he would really get it, might be if you exemplify.

People need to see meaning and results on things (even Tarzan).

If you show an example you’ll be providing the evidences the brain needs to know things may actually work out and turn out to be just the way you are saying.

So..  Exemplify!

Next Step is one most people forget..unfortunately. Practice it is.

3) Practice, Practice, Practice, Practice, Practice, Practice, Pra…

Practice as much you are able to,  with more examples, specially real life scenarios. I guess experts would call it: Put in practice your learnings. Experience in order to learn with mistakes.

Whatever! Like driving, riding a bike, killing zombies, washing teeth, playing the piano, writing posts, attending meetings… you need to practice in order to succeed more often.

Dear Scrum Master, Team leader, Someone willing to help the team:

Explain First

Then Exemplify

After, don’t stop Practicing with them.

 

Changes- why they are so difficult

I know this is a question that puzzles you as much as it puzzles me.

I know you need people around you to change, or at least to embrace the idea that the world is constantly evolving.

I know how frustrating it is to know an answer (right or wrong- it doesn’t matter actually) to share it and to see reluntancy in someone else’s eyes. If they would only listen! We don’t need you to do it from night to day, this ain’t FEDEX, we just want  you to listen and give it a thought.. maybe recognize that there is life beyond your cottonish-belly!

But that day never comes.

And then you, a great thinker,  end up as a brainless zombie or as the bigger Cottonish-Belly of them all!

Now, listen to me.

Changes are not easy.

Ok let us start again. After Adam and Eve being so boring,  God gave it a thought and as a funny guy he his, he said: No way, too easy, let’s start from a draft. Hey Lucy, come here, let me see your drawings baby! Ohhh so cute…ah ah ah. He laugh for 7 days they say.Then

GOD created US: The monkeys.

 

 

 

 

 

 

 

 

( Meet the Monkeys.. To make it sound more scientificish, let’s call it: The Primates)

 

Being The Primates, we evolved, we got to stand up, lost some hair and.. also we got fat and clownish (although less funny).

Then something really strange happened -  Some Monkeys got smarter than others – My bad!  I Meant

-  Some Primates kept being as they were while some others changed.

Why? Well because they rather be slim,  hairy and .. they don”t mind bending over.

And what I want to tell you is: THAT IS OK!

Think about it: why not accept them as they are? Won’t we be happier if we keep the world as an ecosystem?

So, the problem here is you. You are not accepting this. Sometimes, standing still is also changing. Cause the world keeps spinning. You need to change yourself by accepting they are also changing, although not at the same speed, efficiency or way you’re doing.

This was the first thing I wanted to tell you: If they don’t want to change – let them be. Don’t chase. Let them come to you. If they don’t, never mind… you still have millions of Monkeys needing your help.

NOW, the hard stuff: what about when you have to work with them?

Well, then you should remember one thing:

Although Wikipedia says:

“World wide more than one in three people in most countries report sufficient criteria for at least one at some point in their life. In the United States 46% qualifies for a mental illness at some point. “

You should consider that people around you are still healthy. So, being healthy, smart and evolved monkeys – why the hell can’t they make changes smoothly? why is it so difficult?

Well, remember when I said we are primates? that’s still true. As such, part of our brain keeps information vital to our survival- to keep us safe. So, what’s keeping you safe nowadays rather than having our predators inside cages? Of course! Knowing everything around us. If you know stuff around you, you feel safe, you feel in control and so you keep your survival instinct is steady.

Now imagine what may happen if I go to the monkey and tell him he must change the things he does and how he does it.

Bang! Bum! Crash! Monkey brain goes nuts! there are all this flash-lights (kind of Brain radiator) saying your getting in danger!

First reaction: Monkey says no, Monkeys fight you if you insist, Monkey runs with Banana.

If you find the right tune to talk to the Monkey, in time, showing with examples and real case scenarios, supporting and giving him lots of bananas from other sources, then the Monkey will have the physical and psicological strenght to replace the info he has stored for so many years in his brain.

Think about it. Let this banana grow in your brain.

See ya!

Cátia

Ps: Yes, I could have named neuro-cience in this post and add scientific credits and links, but then again.. that would be too easy and way less fun for me. Primates!

Agilitypedia – User Stories

What are user stories

A user story is simply something a user wants.

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

In short, user stories are very slim and high-level requirements artifacts.

Why Stories?

• Words are imprecise:
  “Entree come with soup or salad and bread”
  What does this mean? : (soup or salad) and bread OR Soup or (salad and bread)
• Everyone understands a story – user, customer, developer..
• User stories lead to participatory design
• Stories focus on value (end user needs) and not technical requirements
• Enough info to understand What customer wants
• They are not detailed enough to limit Team’s decision on how to do it

How to write US

A format that can be used is 3c’s : Card, conversation, confirmation

Card
This step is about materializing the Item – writing down the Story text on a index card

from:http://www.agilemodeling.com/artifacts/userStory.htm

As in example above, you can write your user stories using the format: “AS A.. I WANT.. So that…”,
but you can also use others as “Given… When… Then…”
Or …
WHATEVER MAKES SENSE – a story that:

• is clear for everyone,
• clearly states the end-user need/ request
• makes sense to everybody and so all agree with that description

HINT Not rarely I’ve seen some US that are so straight forward that after a few iterations no one can remember what was the end-user request. Be concise and objective, but write down the US is a way that anyone can read it and understands what needs to be done.

Along with the Story you can also add the Story number, Priority, Size and Conditions of Satisfaction.

Conversation
This is the MOST IMPORTANT step while writing/ analysing User stories:

Conversation between Customer (PO) and people doing the job (architects, developers, testers, writers,..) is vital and will define the success of all activities.
Discuss and get common understanding at least on:

• US scope
• Conditions of satisfaction
• Assumptions

Also this is the right time to make clear any dependency specially between teams – If your team needs to talk with or work with some other team, this should be written and acknowledge by all. Inter working is a must in such a big company and within such complex and geographically spread projects as ours.
A great way to perform this conversation step is to specify the user story by using examples (end user examples) – this way everyone will have the same understanding on what is to be achieved.

Confirmation
Agree on acceptance tests, that in the end will confirm we build the right thing the right way

Everyone from the Scrum Team agrees on US scope, assumptions and how this US will be accepted.

A good story has six attributes:

I ndependent – does not depend on other items
N egotiable – it’s not a fixed contract – through conversation a simpler definition (or acceptance) can arise
V aluable – to users or customers
E stimation – it can be estimated
S mall – can meet DoD in less than a 1/3 of sprint by the team working together
T estable – acceptance tests are clear and can be automated
If the Story is not INVEST(ed), then it should be refined during Refinement session (or grooming).

HINT During US discussions (planning, refinement, demo, ..) there’s a lot of information going on, and sometimes, we miss to take notes and write down everything we decide about that Us: dependencies, assumptions, tricky stuff, ..whatever! So, my Hint to you is: don’t stop taking notes – write down or take pictures of all being discuss because you’ll need it later and you won’t remember . I wouldn’t .

Material

Blogs

Check out Mike Cohn’s Blog as one of the most concerned writers on US_
http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements

books

User stories applied Mike cohn
Agile Estimating and planning – Mike cohn
Bridging the communication gap
Writing Effective Use cases – Alistair Cockburn

Bill Wake – INVEST Technique

Did you say Increments or Excrements?

I’m from the north of Portugal. That isn’t good nor it is bad, but it means something.

http://animals.nationalgeographic.com/animals/mammals/tasmanian-devil/

People from the north have a temper. Also they say exactly what they think and, they mean whatever they say. This may be a problem, specially now that I’m working on the south.

Let me tell you about the south. In the south people don’t exactly say what they want the way they want. They say something close to what they want, without saying it.  People from south don’t use bad words. Actually, they might consider themselves as more polite than people from north- which will curse you and nail you in case you do some stupid thing.

Are they actually more polite? Can you say you are polite if you are not saying, straight forward, what you want, feel, think?

People I talk about this always say: it’s about education- you can say whatever you want without using bad words.. but what the hell? Why should I? Aren’t words just..words?!?!! … Why should one stop using words which clearly define his state of mind and purpose? Why start using hollow sentences which mean nothing nor make other fell a thing?

When people say: oh..I can see you are from the north… well, I’m sorry but… I can see you are from the south too. And that may not be a compliment.

Now let’s look how what I say and the way I say may has an impact in teams -

When I say:

” Looks like we are not keeping up our plan nor our quality. Maybe you could review some practices, probably I can help.”

They think:

“Yadda yadda… same talk. I don’t care if we loose that customer, we’ll have others.

Someone, somehow, will always guarantee my job. Worst Case Scenario if I’m fired I’ll get some extra money. Next time do a better plan you sucker!. “

 

When , on the other hand I say:

“This shit will make us lose our last fucking customer you bastards, we fucking need to do something about this shit..what a mess!!

C’ mon!! what will we do to clean this shit?”

The team gets it. And they do something. They know it’s a dangerous situation that may take us to unemployment. They know I’m worried. They know I’m counting on them and..they know  I expect more from them because I know they can.

Of course that this is not always 100% true. I’ve met some southerns that curse more than I do ..and I love them..actually they are the only one’s I get when they are speaking. Cause they say what they mean. I know they are not deceiving me. They are honest, rude maybe, but honest and simple.

When we have honest and simple opinions its actually pretty easy to do the right thing. If, on the other hand, we first need to understand the message, then  we are loosing time to effectively change things for better.

I found my self with a ridiculous challenge, after 5 years living in the south (and loving it) . I don’t know what or how  I should say some things to some people:

If I was from the South:

- ” This isn’t eaxctly an increment… see you don’t have any value, nor the work is done. It’s just a fragment of something that actually does not work”

- “I can explain you again..oh ok, you don’t need, yes of course, You already know it…sorry.. you are a CSM..oh! great… so you know it all”

If I was from the North

-  “Did you say Increment or excrements?”

- “CSM? my dear, we can’t even learn how to wipe our ass in 2 days.”

You may disagree… I actually don’t care. Oh! sorry, I’m in the south: I’ll carefully take in consideration your opinion but I don’t know if I’ll be able to answer you back.

Remember: Words are just… fucking Words! Make them mean something.

Definition of ready

What is that?

Definition of Ready (DoR) is the sum of conditions under which User Stories (US), Product Backlog (PB) or Sprint Backlog (SB), must be so that the team can start the work.

Definition of Ready  is also known as Readiness Criteria.

Let me explain with an example :)

Example

Imagine my team noticed we missed our sprint goal due to 2 reasons:

•   Some committed US were really important but they were not yet clearly defined
•   Our SB had some weaknesses : hidden tasks and we committed to more than we actually could deliver.

Because we are a proactive team and we want to improve(imagine that :) ), we decided that we should do something about this. So during retrospective we defined a list of conditions for the US to eb allowed to get into our SB. Along with that, we also defined some conditions for our SB to be considered ready for us to start a sprint with it.

Our readiness Criteria for User stories was:

1.  US is defined (The PO clearly knows what he wants and added it to PB as a PBItem)
2.  US acceptance criteria is defined
3.   US dependencies defined
4.   Conditions of Satisfaction defined
5.   Team knows how to test
6.   Team knows how to DEMO

This meant that we could only commit to US following those 6 conditions.

For our Sprint Backlog we defined :

DOR for SB:

1.   SB contains all work the team is doing- incl. maintenance and big meetings
2.   No hidden work – if we know we need to do it we write it down (even while Sprint is going on)
3.   We commit only to US that meet the DoR we defined
4.   We know our Team capacity before committing
5.   We consider our velocity before commitment

So, if our Sprint backlog does not commit to these 5 conditions, we can’t say we are done with planning, nor we can start the Sprint.

Who defines DoR?

Scrum Teams define DoR.
Scrum team = PO+ Dev Team + Scrum Master.

In the SB case we could do this without asking for PO opinion, has this is related to Dev. Team self- management and self- organization :).

But regarding US or PB is really a must to do this with PO. Else we’ll keep on failing this conditions, failing our goals and undermining our relationship.

 Hints

If, in a first approach, you don’t know how to define your US DoR, use Bill Wake’ INVEST technique.

US readiness criteria:
*I* ndependent – does not depend on other items
*N* egotiable – simpler definition (or acceptance) can arise from conversations, and that is acceptable
*V* aluable – to users or customers
*E* stimation – it can be estimated
*S* mall – can meet DoD in less than a 1/3 of sprint by the team working together
*T* estable – acceptance tests are clear and can be automated

Velocity

What is Velocity?

The truth is: Velocity is Velocity.
And Velocity is measured..as velocity is.

How do you measure your velocity while driving? (Considering the velocity counter is broken) :)

You are driving for the last 2 hours, you’ve done 160km until now, so you know your average velocity is 80km per hour.

If your final destiny is about 200km away from your starting point:

• You know you will likely get there in 30minutes or
•  If you stop now you have already gone through 160km or
•  If you need to fuel up and stop in 15minutes, you can say you’ve done 180km

Same goes with projects:

•  Team velocity is the rate at which a team delivers Stories from Product backlog.

If you know your velocity, you’ll have an idea on:

• How much value you’ve delivered until now (in Story points and Done US)
• When you’ll be able to deliver all US in the Product backlog
• How much SP will you be able to deliver by a certain date

How do we calculate velocity?
Simple! We do some simple math:

Scenario : Our team delivers 3 US. The Sum of their Story points is equal to 20.

• Our Velocity is then 20.

If next iteration our team delivers 30SPs , then our Average velocity is 25.
(20SP+30sp) divided by 2 Iterations = 25SP

Fig1: Awesome hand-made Velocity chart

Velocity is the number of story points completed by a team in a iteration.

Why do we need it?

•  to predict how much scope can be delivered by a specific date or
• to predict a date for a fixed amount of scope to be delivered
• to understand our limits while defining the amount of scope we will commit for a sprint

What influences my velocity?

As in a car trip, there are things that may influence our velocity

• Road Blocks – aka Impediments
• Fuel – aka motivation, what drives us :)
• Experience from driver – knowledge/expertise/Competence developer
• Car conditions – Dev environment
• Road visibility – Project transparency
• Road Directions – project objectives
• Traffic/driving Rules- Processes
• Destiny – Product

So think, if all those things are in a bad shape, or without a proper definition, visibility, your velocity decreases. Same goes on with projects.

Can I consider incomplete US?

No, you shouldn’t.
Incomplete is Undone. Velocity is about Done US delivered.
Some reasons why you shouldn’t do it:

•  We can’t really figure out how much is ready and how much is not, it will be a wild guess
•  We may be lead by a sense of false accuracy and precision,  given by the use of fractional numbers
• Incomplete means the US has still not value for the customer.

What should I do then?

Break User stories in smaller ones. This way it will be easier for you to add them in a sprint and manage to deliver them.

Teams and their velocity

Should bugs and maintenance be considered as Velocity?

Yes if you estimate their size in story points.
It’s work delivered right? Although with no direct value to customer, it’s indirectly associated with value delivered.
The proper way to handle this is: don’t create bugs :) use zero-bugs & prio1-fix-bugs policies. Whenever a bug pops-up: finish it!

Should I compare team’s velocity?
NO
Why?
Well, because we work with Story points. As such we work with relative estimation – We compare User Stories with each other, having as basis a reference User story the team picked up.

The Story Points of that reference US can be anything. A team can say that the reference-User Story  is equal to 400SP or equal to 2SP… it can be anything! It actually doesnt matter because we work with RELATIVE ESTIMATES.

The goal  is not the number itself – the goal  here is to use this US as a reference and use it to estimate others by comparison.

So, how could we compare velocity in this case?

Team A is delivering 800SP and Team B is delivering 30SP, does this mean A is better than B?
I don’t know! And I don’t Care… each team is comparable only to itself.

Velocity is not used as if we were racing against each other, Velocity is used to help us improving our timing – to help us getting better and better and speed up.

What about teams working with same Product Backlog?

Well, this is then a different case:
It is nonsense to have teams using different comparing units for the US in same product Backlog. We use SP to predict how much scope we’ll be able to deliver by a certain date or to predict when we may be able to deliver the scope – so if we have more than 1 team working in a backlog and they use different size for US, we won’t be able to do this predictions.
In this case, teams must get together and define a Reference US. After they should decide what’s the size of that Us in SP. Then, on every refinement, the teams, or their representatives, will estimate having as basis the same US and same Size for comparison.

Then, in this case, can I compare teams?

Nope. Why would you? Maybe some are delivering less SP because those US were not well estimated comparing to others. Or maybe, that team is helping other teams or paying more attention to testing, refactoring, coding standards… we don’t know do we? You should compare a team with itself, and dig out why the team is slowing down. Most probably you’ll see there are several impediments you need to take care.

Each Car has its own characteristics: we need to get the best from each..and know that if we push it to hard we will probably break the engine.

Help teams excel, don’t punish them.

Humans are humans and we are (gladly) different from each other. You’ll always have teams performing differently from each other- and that’s not necessarily bad. We just need to find out each team sustainable pace and keep them moving. Driving our company further.

Material for you to read more about it

Blogs

Mike Cohn’s Blog: http://blog.mountaingoatsoftware.com/tag/velocity

http://agilesoftwaredevelopment.com/tags/velocity

Books

User stories applied Mike cohn
Agile Game Development with Scrum
Scrum and XP from the Trenches – Henrik Kniberg although he refers velocity is The amount os DP the team _believes_ they will deliver – which is not exactly what we consider – we consider the amount our delivers effectively.