No estimates; hype or not?

#NoEstimates seemes to be the next big thing in software development

Is it because

estimates are lies and estimation waste ?

-hey: wait a minute! I have seen value in the estimation process. This post shows the difference.





The first thing to figure out is: Why do we estimate in our team? Is it due to lack of trust, and the urge to micro manage and illusion of control, not focusing on value? in that case, maybe solving the underlying issues should be the number one priority :) just tossing away estimation will not solve any of these more severe issues.


On the other side; estimations might be for the internal use in the team. An estimate is a solid number, it is something that all team members can relate to, and figure out if the team has roughly the same understanding of

• the problem
• and solution,
• what is out of scope,
• what is needed,
• what is nice to have,
• what is over-engineering,
• what are the risks involved,
• what dependencies do we have,
• what test coverage and state is in this part of the code,
• how familiar are the team members with the code, domain and goal.

In other words: Estimation can be used as a means for communication within the team.

And: Only a limited number of software development challenges has a fixed scope. To discuss in the team what is the smart thing to do is a positive effect of valuable estimation.

 

The impartant question is this: Does estimation give you true value? If not, see if you have more severe underlying issues to deal with and get rid of your estimation process.

How to master the power of «No»

It is easier to say yes than to say no. But remember:

Saying "No" is not having a bad attitude. Saying "No" is making a choice.  

Every good software project has some people that are great at making choices

This is how to do it:

 

I often find myself talking with business people. And usually they want everything in the whole world (at once): they want all the functionality you can think of, there should of course be no bugs or downtime in the system, and they want it all as soon as possible! This is especially true at the start of any project, or early in the release cycle.

Delivering software boils down to the ability to say no to some really appealing features. These features will not make it into the next release –a harsh truth. And we leave this out in order to secure and deliver what is even more important.

 Sounds simple, but it is hard in real life!

Why is it hard to say no?

• You feel better if you say yes –in the short term. In the long term you will need to handle to much, and you will see some of your things slip
• You make the requester happy –in the short term

What is the art of saying no?

Ignore the instinct to get the rush of reward when you say yes. Think of the implications:

• Reprioritization is always possible :) It is all about doing the right stuff first, and not fall into the trap of scope creep
• What stuff will need to slip?
• What will be the implications for the customers, the organization, the employees, the short term and the longer term?
• What is most important?
• Do not bluntly say “no”. Start with your purpose (your shared goal), what options you have and implications.
• Ask back: what is more important?
• And a really helpful question: is this a showstopper?

After this exercise, you are back on the same page on what is most important and how to move on. You are helping each other to focus on the right stuff and you have the right amount of work to keep the flow. This is a great place to be!

"No" means "Yes" to something else!

·         No to random interruptions scope creep

·         Yes to the right focus

·         Yes to flow

·         Yes to shorter releases

·         Yes to fewer bugs

·         Yes to reprioritization

·         Yes to take something else out

photo attribution

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.