How to get rid of forced ranking; story from the trenches

All companies have boundaries; things that you just have to live with. Values are essential in this context; you use them to know when to fight, what to accept and when to move on.

This is a true story of getting rid of Forced Ranking: A group of colleagues challenged our 70.000-employee-company-boundaries based on our values, the values of the team, and the values of the company:




Forced ranking
this is also known as vitality curve, forced ranking, forced distribution, rank and yank, and stack ranking.

The concept was made by Jack Welsh in the 80's, and the point is to divide and label employees into three groups: the 20 % top performers (that should be rewarded with bonuses and stocks), the 70% majority, the bottom 10% (that should leave the company).

I do not see anything positive about labelling all employees with grades like this. In a high performing team it does not make sense to label 70% as average!!! Who wants a team where 70% are dis-satisfied?

This labelling system break trust between leaders and employees, between peers, and create economic incentives to be in a weaker team. It prevents collaboration, learning and teamwork.

The system is also linked to goals and this create a system of goals that everyone make sure they meet ( = weak goals and not revealing the company's true potential). If the achievement of goals is linked to compensation, the intrinsic motivation is replaced with money motivation, the extraordinary work is replaced with average performance that is aligned 100% to the plan rather than aligning to adapting to constant change and stretching for the extraordinary.

Ok, so what to do with this?

1) research
I knew in my heart that forced ranking was wrong, but had to put my thoughts into more precise wording. I started to write down my thoughts and searched to find what others have said and done in the matter. I found some great material:

• Edward Demming's book Out of the Crisis
• Daniel Pink's book called Drive, here is a ted talk and a RSA animate of it

2) reality check
I also talked to my peers (other team leaders and project managers). This was disappointing, because half of the people I talked to did not see the problem at all. One person with 50 employees and several managers reporting to him said to me: "if this was a problem I would have known".

But (of course) I did not give up, and I focused on the ones that did see the problem and could help in finding a solution.

3) proposed solution 
I worked close with two peers, and together we made a three-slides-deck describing the problem, effects and possible solutions.

4) escalation
We presented this to our site manager, and he accepted it and scheduled a meeting with our General Manager and Senior Vice President.

5) case closed?
Our GM and Senior VP joined forces with their HR representative, and we were able to get rid of the whole rating system!

Hurray!!!

So, when you meet a boundary that you just think is important enough to fight; I encourage you to do something about it. It is in your company's best interest. Use your values as a guideline :)



Have a nice weekend!
Eira

Change: story from the trenches

Marc Garlic/Science photo

This blog talks about three lessons I have learned about the change process. The examples are from when I introduced Scrum into an existing team.

Change is so interesting because it happens all the time, and this is true also for the work place: The last three years this is some of the change I have experienced:

• being project manager for a team that changed from developing a soft client (sales numbers of 1,5 million clients!) to develop sw for hardware
• three sw teams being merged into one large group of over 80 people
• lots of changes in the culture and organisation due to the acquisition
• not to mention change in sales processes and marketplace

 All this -and more -in just 3 years!

Forestwander Nature Photography upload bot

I think change is interesting and fun, it can absolutely form the basis for new opportunities and growth. Both on a personal, team and organisational level.


So, let's go back to the "introducing Scrum into an existing team" story:

  

1) Team involvement

How did  the idea of implementing Scrum come up in the first place? It was based on some challenges that (almost) all of the team members agreed was painful. The situation was long release cycles and huge instability in the code base during this development cycle. It was hard to get the code stable before release. And it required lots of time -both hours and calendar time to get to the point of having the overview of bugs -both the number and scope of those blocking the release. (= big risk!!)

However, there was no agreement in the team on how to solve these problems. To see if Scrum could be a solution, all the team members attended a scrum master two day class and we looked into benefits, pitfalls, principles, techniques and vocabulary. We decided to get "all in" for 6 months, and then evaluate if we needed to do major changes (during this six months, we did make adjustments based on retrospectives, but only within the principles of Scrum). Like a Chinese saying: First learn the rules, then break them.

I can imagine several other variations of this where the team buys in on the principles of Scrum, while the business side and management parts of the organisations might not. In that case, I believe the part of using some of the existing challenges as a starting point for change is still a valid case. Then being smart and deliver value on a frequent basis and build trust, and take it from there.

2) Do NOT put up the "here comes a big change" sign

My mistake in this process was to do exactly this: I held up the sign of change, emphasising the parts that was the "change" bit in how we did development.

Don't do this!
Picture: denstad.com

I soon found that a much better approach was to build on the smart things and good principles that was already implemented by the team and being a part of the team culture. I did this by pointing to the evolution part, building gradually on the great things that was there already, not mentioning "change" at all.

One example is the short feedback loop. This team had the best culture on writing automatic tests, not one commit during the last year had been committed without tests. To release to a friendly internal gang (we called them "the gang of five"), was however not something that the team wanted to do at all.

Rather than emphasising that releasing every sprint to the gang of five as a new idea, it was much more successful to get people on board by answering the question: "We have done a great job of getting a short feedback loop into our continuous integration system. How could we involve "customers" into a short feedback loop as well?"

Evolution brings out less resistance than revolution

3) Focus on the intentions behind, empowered teams find solutions
Each Scrum team decided if/how to do estimations. The group as a whole did not do estimations before we tried Scrum, and there was different opinions in the group whether or not this was something they wanted.

The intention of release planning, backlog refinement and estimations are for the team to get on the same page of what is this project all about. What is the order of doing things? What do we believe make sense in order of milestones? What options do we have to make different choices; could we do less on one part in order to get something else in? (I do not believe customer value is the only aspect to consider when prioritising the backlog, but also risk, a mix of smaller and bigger epics/user stories/tasks, motivation/competency in the team, and if the user story is understood)

On the question on "do we need estimations or not?" we rather asked other questions:
How can we get on the same page on what the different user stories is all about? How can we as a team get to understand intentions of user stories and get to the "why" part of them? How does the team have the same understanding of the acceptance criteria?
Could using numbers or size help us in explaining to each other what we are thinking? Here there was different answers in different teams, and we tried out different solutions (no estimates, t-shirt sizes, ideal days, variations of relative numbers).

One team wanted to discuss the topic (it started as quite a heated discussion by the coffee machine). This is what I wrote in the invite to the estimation-discussion-meeting:

Estimates are lies, and estimation is waste
-Unknown

Plans are nothing, planning is everything

-Eisenhower                                           

We ended up doing estimates not for the estimates own sake, we did estimates to get on the same page in the team.

One of the release plans we made in the process
of getting on the same page (3 scrum teams, 25 people)
The picture is taken mid release, this is capturing finished
 work and guesstimates.

More info on change:
Kotter international: 8 steps of change
Toyota kata



How to control everything in your project!

Guess what!? I have discovered a process that let you control not only timescale, budget and quality but also scope, risk and produced benefits!

During the initial project stage, the business side will know all these aspects and make the well-informed decision to start the project or not.


And this process is called Prince2


By now, I guess that you have realized that I am not serious.

I find it a bit strange that people buy into this illusion, that it is possible to know all these aspects up front.


On the other hand, I find too many agile practitioners being too fundamentalists in their approach to agile. We have to take into consideration that organisations do have some boundaries that they need to adhere to. Not everyone can or will go all in from day one.


I think one solution is for the Prince2 fanatics to emphasize the “management by stages” which equals “embrace uncertainty”.


I also think Agile fanatics should be less fanatic in their communication, because what is the result of fanatic communication? People that already think the same way as you; they will nod, whereas the rest will dismiss all you say.


Prince2 provides a common vocabulary that is great when communicating, and the agile community provides the values and methodology that we need to deliver (the right) software.

I think we can use both to get where we want. We just need to

• be practical about implementing Prince2
• not getting bureaucratic
• emphasize the flexibility that is built in
•  implement agile and lean into this super-thin framework   

    

After all: this is what we want:

“Speed, Quality & Low Cost are Fully Compatible
Companies that compete on the basis of speed have a big cost advantage, deliver superior quality, and are more attuned to their customers' needs.”

-Poppendieck

Have a nice weekend!

Cheers,

Eira

-Prince2 certified, agile at heart

The crazy agile project family

Two months back my husband and I wanted to fix some major issues in our everyday life, experiencing too much stress and even passing it on to our kids age 4 and 7. We did not find any solution, and discussed back and forth. Then suddenly, we had a breakthrough:

Me: What would you have done at work? If you joined a project as a leader of a team, with the same level of stress, what would you do?

Him: I would not take on as much in the sprint

Me: Ok, what else?

Him: I would reduce the product backlog

Me: Ok, great. How?                                          

Him: By visualizing the bare minimum on a board, and use that as a starting point

Me: Great idea! Let's do it: not take on as much each week, reduce the backlog and get a board

 

Then I thought: how can we hide that board from our friends and family visiting us??
My second thought: You are old enough to live the way you want, aren’t you?

 

This is our scrum board

At work one of my best capabilities is to focus on what is necessary, focus on the most important stuff. I usually find myself visualizing to others (stakeholders, team, product management) the consequences and opportunities that we have in the project, getting everyone on the same page: prioritization is key, and it is not in our interest to hide our head in the sand pretending we are able to do everything. 

At home, I found it much harder to leave out what I thought I needed! I just need to remember what I usually say (and do) at work: saying no to one thing is to say yes to something else! Lots of great stuff happens when we say no.

Now we are running Scrum for kids - agile family - lean living

True ownership (notice the drawings)

Short disclaimer: we are not running true Scrum, but the potential is there: weekly plannings, weekly retrospectives, I think we can get even more of this incorporated into our family life. (and become even more crazy!)

getting more lean!

Mer smidig? -del 3: Tillit og ledelse

Alle team og bedrifter har rammer å forholde seg til. Vi begynner nå å vite mye om smidig, lean og ikke mist scrum -men noen lever med rammer som gjør det vanskelig å få ut de effektene som er mulige. Her tenker jeg å skrive om ett aspekt som er helt vesentlig i smidig, og som alle, uansett ståsted, erfaring med smidig eller hvilke rammer som gjelder, vil ha mye å hente på å jobbe med!

Temaet er Tillit og ledelse


Tillit kan man som kjent ikke kreve, det er noe en får. Spørsmålet blir hvordan. I prosjekthverdagen tenker jeg at det to helt grunnleggende ting som gjelder for å få tillit i organisasjonen, det er leveranser og kommunikasjon.

Hva kan du gjøre for å levere hyppigere og mer synlig? (se her for eget innlegg om temaet)

Hva kan du gjøre for å bli bedre på kommunikasjon? Hva er viktig for dine stakeholdere? Kan de inviteres på review? Kan du sende ut en kort oppsummering på mail? kan du oppsøke kaffemaskinen der de er? kan du ringe dem? har du prøvd video? Vet du hva de er opptatt av? er du god nok på å få frem poengene kort og konsist, og ikke minst fengende?

Tillit på prosjektnivå:
Min erfaring er at når prosjektet klarer å levere verdi hyppig, og kommunisere godt, da får man tillit og ikke minst handlingsrom til å gjøre skritt i riktig retning som igjen gjør en bedre i stand til å levere bedre og så har man en super spiral gående! Det er lettere å få aksept for å ha et tydelig fokus og scope når omgivelsene føler trygghet på at dette er noe som blir levert.

Tillit på individnivå:
Dette er relevant også på individnivå: en ting er å være god, en annen viktig ting er faktisk å jobbe hardt. Snakker ikke om å være på kontoret sent og tidlig og slite seg helt ut, men snakker heller ikke om å komme sent, gå tidlig og ta halve fredagen fri. Trening (holde seg up to date og øve), hygienefaktorer (at man tar seg av koden), og innsats (tiden som legges ned) skiller de som er medium til de som er virkelig gode (og som holder seg gode). En forutsetning for et high performing team er når hver enkelt er seg bevisst dette og sin påvirkning på de andre.

Tillit i et prosjekt er altså både mellom prosjektdeltakere og ledelse, mellom prosjektmedlemmene og mellom prosjektet og organisasjonen. Og dette må fungere på kryss og tvers :)


Hva med ledelse i prosjektet?

• Empowerment av teamet, det er teamet som bestemmer
• hva som skal være med i sprinten, 
• hvilke team som jobber med hvilke oppgaver, 
• hvordan oppgavene skal gjøres, 
• tidsplaner som er realistiske og som teamet kan tro på
• det brukes ikke estimering for å holde enkelpersoner/team "accountable"  (estimering: kun som verktøy for kommunikasjon, synlighet, risikohåndtering og prioriteringer)

• Ta med teamet på reisen for å forstå visjon, hensikt, rammer og mål for prosjektet
• alle får et ektefølt personlig eierskap

•  Vær en spydspiss for kommunikasjon innad i teamet og utover til eksterne

• Reflekter over tillit på en jevnlig basis, hvor fungerer det bra, hvor må det jobbes med? (f.eks tillit mellom enkeltpersoner i teamet, dette må også håndteres)

 Tillit: et spennende teama; og som med mye annet begynner det med leveranser og refleksjon :)