Handling a 60% contributor

Photo: José Manuel Suárez

A 60% contributor is a person that is not contributing to his or her best abilities. This has a big impact on any team, but most importantly,  it is a bad situation for the person himself/herself. Handling this type of situation is maybe the most important part of the job when leading a team.

The situation is both common, difficult and important to solve. I will share some thoughts on "how to" in this post.


It is a sensitive topic, so I will spend some lines introducing why this is so important, common and difficult.

Important: In a situation where a person is underperforming, this has a big impact on the rest of the team in regards to motivation, trust and ability to deliver. In the end, this also affect the ability to fulfil the organization's purpose and to deliver customer value. The most important aspect is the one of the individual that is underperforming: I believe that all people want to live their lives to their full potential, and work is an important part of life. This situation is therefore one that has no winner: neither the environment nor the individual. It is a leadership responsibility to address this as quickly as possible: Habits, also bad ones, grow fast, and there is a chance of getting stuck in the mud.

Common: During a lifetime, most people will experience problems either personal or at work. This could be anything on a range from lack of initiative to serious medical conditions. It can be physical, psychological, legal, addictions to gaming/drugs/alcohol, issues in close relationships, or at work: conflicts, lack of motivation, stagnation, wrong position/environment or company. It could also be nothing serious at all: just ignorance of the impact of one's own behavior.

Difficult: Each situation is unique; the manager and the employees are different, the history, relationships and context vary in each situation. It is also much nicer to bring good news. Handling tough situations are more demanding.


Each of these situations are unique, still some takeaways are generic:



Picture: momentum.se

1: Prepare

Communicate the problem clear and concise:

• To avoid uncertainty and misunderstandings: use solid situations that you have experienced
• If you are vague, this will only lead to misunderstandings and does not make a solid foundation to find the right solution, it even might feel like the Spanish inquisition

Possible solutions:

• Think through the boundaries and limitations that neither of you can change. Prepare to ask the employee to think through if this is something that he can live with.
• Think through what you would like to achieve (first meeting, follow up/next steps)
• Look up any supporting services that your company can offer (medical, legal, coaching, psychologists etc)

Prepare to listen:

• Prepare yourself mentally that all these thoughts are just a preparation: the key to any solution is in the hands of the employee: there are several aspects that you do not know -or solutions that you have not evaluated
• Prepare yourself to listen actively

Key focus of the meeting:

• What is the topic (max 3-4 bullet points)
• As important: How to handle not related issues that may come up (you can use a "parking lot" for issues not related to the key focus area. Parking lot items must be dealt with in a separate track)
• Plan to have the meeting early in the week
• so that you are available to clarify or follow up

Find the right words:

• If you are more experienced, you can think of difficult situations like this, where you handled it well to the best for the individual, the team and the company.
• If you are not as experienced, you could
• get help from HR
• practice (role play with a colleague), try to have both the role as yourself and as the employee, and see the effect different approaches has. Find words that is best aligned with your intention
• practice alone: talk to a chair or a mirror
• Write down a summary (pretend it is after the meeting). Did it capture what you wanted? Did you focus on things not related to the focus area, which you should not have spent time on?

Photo: Richard Ling

2: During the meeting


Introduction
You need to get the scene right: find the balance of being honest and direct on one side, and to create an environment for dialogue on the other.

You need to spend enough time on finding a common ground where you both see what is the challenge, and at the same time emphasize more that we now start working together to find a solution. I have good experience emphasizing my good intentions for the person and for the team, and by this avoiding to bring out  defense mechanisms.

• solid examples/your observations
• you want find a solution/how can you help/how can you work together on finding a solution

Know your responsibilities
As a leader, I have a responsibility of the work environment and things at work -at the same time, the leader does not need to know all the details on employee's personal issues. In situations where the employee is going through a tough time, he might not evaluate clearly if the details revealed might feel awkward for him afterwards. It is a good idea to say that you do not have the expertise on the matter, and offer the contact details to any professional aid the organization offer.

Main part of the meeting
The best solutions are the ones that comes from the employee. To facilitate in order to get to this is the main contribution from the leader. There are several solutions:

• temporary arrangements to help out for a difficult period in the employee's life, if that is the case
• find a solution to get the motivation back, if that is the issue
• sometimes change of environment could be a good solution

End
End the meeting by a summarizing what have been discussed and next steps.
If something needs to be communicated to the rest of the team, agree on what that should be.
It can be a good idea to send out a summary of the meeting afterwards.

Good luck!



Picture: favim.com

Handover: "us" and "they"

In October, I got this question: “Can you help us to make our hand over process work?"

Interesting question!



Many agile-religious-people will automatically answer that there should not have been a hand over process in the first place. I think there is no such thing as "should not" in IT or in organisations in general. There are many very valid reasons why things evolve into what they are, and most organisations do have some form of hand-over at some level.  The challenge is therefore; what to do within this scope?

Interesting topic!!

This organisation have looked at what is the root cause of this situation in the first place:

• Optimisation for silos; this have ensured high quality of technical expertise, but also not optimising for the whole value chain
• The needs of the customers have been primary focus (very important!) now the focus needs to be on the longer term and market transitions as well (also important!)

 

Then the organisation looked at next steps:

• Acknowledgement of situation
• Management decision making for long term solution (including some reprioritisation)
• Communicate the target picture
• Involvement
• Firefighting: Add people with great people skills that can fix things between departments and make people talk to each other, and just make things happen
• Start working on the long term solution

Being part of this now, make me reflect on the whole "us" and "they" as a topic. And I do not think there is one single organisation completely without this challenge in one form or another. The big question is; how to deal with it?

I remember back in 2003, when I was fresh out of university with my masters degree, and got my first job. The company I worked for had recently re-organised from service-centric units to be divided into three departments: development, maintenance and operations.

We believed documentation to be the main API between the development and the maintenance parts of the organisation. To make software from development/projects work in production, the maintenance department only needed to list specific requirements to them –and perform audits.

This created an optimised environment for both projects and maintenance, however we also got some frustration based on the "us" and "them" feeling:

Frustration in the projects: somebody from the outside (the maintenance department) came in and disrupted the flow they were in. Lots of the requirements were way out of scope (not part of the contract) and presented in a not so collaborative manner

Frustration in the maintenance department: why did not the projects take into account how the systems were to work in the real life (real servers, real security, real logging, real installation files that actually work at night in the short and few hours of downtime the SLA could allow)

However, we also had some great people on board, that helped us remember that we were in the same boat:

I worked with a great project manager who repeated her mantra; “We have a shared goal here, for our customers and for our company. How can we make this work together?” This is a great take-away, and I have brought it with me and thought of it every day since. This learned us to see that we were part of the same problem and the same solution.

How to change the “us” and “they” mentality is only possible by working together. Working in different departments might work only if:

• the managers are well aligned and share the same goals.
• people from all departments are included in the project work during on a regular basis, at least weekly
• people from all departments are informed, before it is strictly necessary, and kept in the information loop.
• I do not think it is possible to over-share! invite to reviews, send out summary e-mails, drop by for coffee, have lunch together
• people from all departments are invited to parties, kick off and other events 
• do not underestimate the importance of team t-shirts :)

 

 

A great exercise is to think this through on a regular basis:

• Where in my organisation do we have "us" and "them" challenge?
• What can I do to improve the "we-are-in-the-same-boat"-spirit?

Presentation skills -and how to improve

Last week I did a talk at Smidig2013, and I did my best to use the presentation skills I learned earlier this year in a practical training class. You can find the talk here (in Norwegian). In this post I will summarize my notes from the presentation skills class:

1) Body language:

a) Standing still:

Stay still and firm when you talk. Be grounded on the floor.

I had a tendency to sway, both in hips and in knees. In the presentation I held last week, you see that I do this a little bit in the beginning, then remembering to stand still.

b) Moving around:

It is great to use the whole floor, do this: talk, move, talk. This means do not talk when you move, and it is ok to move and turn your back to the audience, but do pause the talking when you do this.

I have a tendency to much more swaying when I move, so for me, it is more important to focus on a then on this.

c) Arms

• do not touch yourself (not in the face or anywhere else.)
• you may have your arm(s) straight down beside you
• or you may use your hands to gesticulate –not in front of you, the best is using large movements out to the side (feels wired, but looks great, use video and record yourself and you will be convinced)

For me, I have focused on the first one of this, I am aware of the last one, but think this is hard. Most of my gesticulation is in front of me.

d) Words

Skip all words that do not have a meaning. Words like “ehm”, “sure”, “right”, “like” and so on. It is much better to pause and to have just silence. It feels strange, but sounds great!

After practising this and recording myself, I have been aware that silence is definitely my friend. When I need to think, it feels like minutes, but in reality, it only takes seconds. A pause only makes the content standing out.

2) Content

When all the rest is in place, off course content is the most important part of the presentation.

a) Introduction part one

(10-30 seconds) Get on the same page with the audience, let the audience know that you know the context and domain, and get each and one of them to buy in to the idea of you being able to contribute in the area of topic.

For me this was an eye-opener. Before I attended this class, I had the impression that it was smart to present any controversial ideas or summarise the whole point of the presentation in the introduction. Big mistake!

b) Introduction part two

(10-30 seconds) Let the audience know what they can expect during the presentation, i.e.: “in this presentation I will start by examining the three different options, and summarize pros and cons. I will also present the recommended solution and how to bring this forward”

I did not know how important it is to let the audience get a sense of what to expect, and this being key to engage the audience during the presentation, making them curios.

c) The PowerPoint

Who are the slides for? –It is not supposed to be for the presenter J The audience are only capable of either reading or listening –not both at the same time.

If it is important that the slides capture content for people not present (it is going to be sent out) consider making two separate slide decks or provide the extra content in the “notes” section.

I have fallen in love with pictures on my slides only. This is also what I used in my presentation at Smidig 2013. These are three slides from that slide deck:

 

 

d) The end

Summarize your point and present next steps or actions that the audence should take.

 

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!