Getting ROI out of a Happiness Wall

There are so many people on this world and they already had so many great ideas. It is tough to come up with something completely new. But, that’s OK. We have a saying in the Netherlands: “better well stolen than badly invented”. OK, roughly translated that is. It is not necessary to re-invent the wheel every time if a good wheel already exist out there that you can just use. Moreover, combining two existing wheels sometimes just makes a better wheel and allows you to feel creative as well.

Jurgen Appelo combined the Feedback Wall and the Happiness Index into the Happiness Wall. I really like the idea, it is simple to implement, simple to use and provides powerful feedback.

(Website Management 3.0,

A former colleague of mine was using a Return On Investment (ROI) diagram in his meetings. When people left after a meeting, he would measure their perceived ROI. He asked them to place a dot along an ROI line. The ROI line consists of line going from a very low ROI, to a very high ROI :). The closing question could for example be: “for this hour that you spent here in this retrospective/meeting/event, how do you measure your return on investment in regards to time spent here? Are you super happy and it was really worth your time, then put a marker on the top right. If you feel, man what a tedious boring meeting, put a marker at the bottom left. So please put a marker when you leave the room.”

When you ask me to fill in how happy I am after drinking some beers with colleagues that I really like, I will say probably very happy. However, is the ROI high or low? Or when you have a meeting and the ROI was high, but the meeting itself was so boorrrring, will you attend next time?

Is happiness in itself feedback enough or should you also combine it with the ROI that people experience? I believe the goal of meetings should be to organize them in such a way that they make people feel very happy and that they have a high ROI for participants. A very high happiness score and a very low ROI…. well maybe next time just plan an evening out with your colleagues? A low happiness score and a high ROI… well it will probably result in people complaining they have too many meetings. I believe the fun factor should always be present in meetings.

What I now did was to combine the Happiness Wall and the ROI diagram. How much did you like the meeting and how high was the ROI? Using this approach gives me insight in both how fun it was and how high the ROI is. This provides me a bit more feedback about the meetings or workshops. Moreover, people can write feedback on sticky notes or just put one sticky note on the wall to present their happiness/ROI ratio.

In the example below, people really liked the session. However, the ROI was so so. Excellent feedback in this case, because we were doing a tryout of a new talk. For a talk we really want the ROI to be high. Happiness being so so s OK as long as the ROI is excellent.
When you have a meeting/workshop/presentation/etc. think upfront what score you would like to score. Is the ROI important or is the Happiness score more important?

Did I invent something new? Nope, just combined two existing tools. It works for me, maybe it will also work for you, just let me know what you think of it.

Giving Feedback Without Fear

Distributed teams pose their own challenges. One the challenges I want to discuss today is people in a distributed team giving feedback to each other. Early in our professional career, we learn not to use mail to provide feedback. Mail is not good at conveying emotions so you should always do it face-to-face. Only use mail if you are going to deal with facts. I still agree with this, but only when you are working as a co-located team so with people at the same location and with people that see each other regularly. I worked with teams in India, the US, Belgium and Romania and it is sometimes very difficult to find the time to provide instant face-to-face feedback. There are loads of reasons for this such as time-zone differences, public holidays or just busy agendas. Feedback is best served hot. It should always be given as quickly as possible. When giving feedback to someone about something that happened a week ago, the feedback has lost most of its value.
So, if feedback by mail is seen as poor communication, and there is a big risk of misinterpretation of your message, how do you still do it?

What I found very useful is using the feedback wrap as described in #Workouts by Jurgen Appelo. It is a wrap, not a feedback hamburger: “You did a great job last week, oh by the way how you could write that piece of code, but still a big thanks for the great paper you delivered this morning.”

The feedback wrap will give you a structured approach to provide feedback. It will help you make your feedback more constructive and it will minimize the risk of miscommunication. The feedback wrap has five steps:

  1. Describe your context
  2. List your observations
  3. Express your emotions
  4. Sort by value
  5. End with suggestions

When I worked as an Agile Coach at a certain company, there was a VP Product Management that lived abroad with a time-zone difference of 9 hours. As you can imagine this person had a very busy agenda. It was extremely hard to get a Skype meeting with this person. The company was just getting started using Story Points and this particular VP had decided to use the number of story points delivered by the teams as an MBO for the Product Owner of that team. When I heard about this, I thought…, well let me not repeat what I thought… let’s just summarize it as “Jeezzzz…”. So, I decided to give him feedback about this. Note that I actually had no real involvement with this person: I was not coaching him, I was not hired by him, I had not met him in person (yet)… so how to give feedback and make sure he would not be upset, or worse? I was a bit afraid to give him the feedback.

I started my mail with providing some context first. I was in Eastern Europe at the time and it was hot, more than 34 degrees Celsius. Therefore, I had already slept badly for a few nights. I told him this for starters and I also told him that I was a bit annoyed about some discussions with some people, and what the impact was for me. So he knew I was not in my best mood.

I then shared my observation with him. I kept it as clean as possible, and presented it just as a fact. I said, I learnt that story points are being used as MBOs. The real description of the observation was a bit longer of course :).

After sharing this, I described what it did to me, in an emotional way. An observation is an observation, when you describe it correctly, there is no discussion possible about it. Your emotions are your emotions. No one can say your emotions are wrong or not allowed. They are your nonnegotiable feelings. I simply stated the observation that story points are used for MBOs which made me feel sad and also a bit upset.

In the description of the feedback wrap, you will find that the next step in making the wrap is too sort your observations by value. However, I often also find it valuable to take some extra time to give some more information about the situation. In my case, I explained my feeling upset by stating why it is a bad idea (IMO) to use story points in combination with MBOs. In short, I was providing my reasons for feeling sad and upset about the observation at hand. When you provide feedback, you also need to try come up with suggestions. The VP was trying to motivate the product owner to increase the output of the team. I made the suggestion that we could introduce a Definition of Ready to improve the efficiency of the Scrum Team and therefore also the output. Finally I offered my assistance to implement the Definition of Ready approach.

So I sent the mail and waited… Would he be upset, disagree, escalate to higher management? Within a few days I got an answer from him. He agreed with me and he thanked me for my feedback. He changed the MBO directly and wanted to think about how to implement the Definition of Ready.

I am not saying using the feedback wrap will always give you good results. However, it will help you to provided feedback in a structured way.

I realized that using some kind of template makes it easier to provide feedback. But as with every template, it is just template. Use it as a starting point and change it when you need to change it.

One other important lesson is: take your time. Do you know any people who tell you to just write a quick mail? Trust me, writing a good email, and definitely a feedback wrap, is not done in five minutes. Make sure you take your time, writing a good email can easily take up to 30/45 minutes.

From OKRs to Weekly Tasks

Objectives and Key Results (OKRs) are a popular technique for setting and communicating goals and results in organizations. Its main goal is to connect company, team and personal objectives to measurable results, making people move in the right direction. A big part of OKRs is to make sure that each individual knows what’s expected of them at work. OKRs are public knowledge and are available to everyone, so that teams can move in the same direction and people can know what others are focusing on. OKRs consist of a list of objectives, and each objective then usually details 3 to 4 key measurable results. Each key result has a progress indicator or a score of 0-100% or 0 to 1.0 that shows its achievement. See this infographic for more about OKR history, users, quotes, best practices and examples. You can read more about OKR at this page of Weekdone or in workout Metrics Ecosystem of Jurgen Appelo. If you are more into YouTube, check out this video:

Now, I enjoy having structure in my daily work/life, and according to my girlfriend I sometimes enjoy it too much :). I use (my version of) GTD, in combination with Evernote to organize my daily work. Last year, I started experimenting with OKRs as an addition. I like the OKR approach because it adds a higher level of planning and focus to my work. However, I was sometimes missing the link between my OKRs and my daily work. It happened a few times that I forgot about my OKRs and did not focus on them for one or two weeks. I know, my fault, but still…

I believe that you should be doing things at work that give you energy. Of course, we all have to do boring tasks sometimes. But in the end, I want to leave office with the same energy level as I came in, or even more energy! I also want to find out about what kinds of things gave me energy this week, but also have an overview of things that gave me energy six months ago. I am quite a structured person but it also partly serves to compensate for the fact that I sometimes forget things, sometimes even important things. About this fact, my girlfriend also has an opinion ;). So, remembering what gave me energy six months ago is hard for me. What are the small things that gave me energy, things that boosted my day? Why do I want to know this? There are moments that I don’t do anything, but just want to look three, six, or even nine months back and see what I did back then. What can I learn from it?

How did I solve these two issues: forgetting about my OKRs and wanting to keep track of my energy levels during the week? By simply printing the OKRs and pinning them to the wall next to my monitor? I am sure that this will work for a couple of weeks but then I won’t see the note anymore. It will have blended in with all things on the wall. Perhaps by setting a reminder in my calendar to review my OKRs daily? Sure that will work for the first days but then the reminder will pop up during a meeting and annoyed I will dismiss it indefinitely (and forget about it). So after some thinking and reading, I came up with the Energy Log. Below you can find a sketch of my current Energy Log. Current? Yes, current, it constantly evolves. More about that later.

Let me explain this log. It is not that difficult 🙂

Upper top left is where you just write the week number. Top right, it’s you write down your current OKRs. Below the week number there is a graph. For every day you keep track of your energy level, I keep a scale between 0 and 5. Place a dot when you come into the office in the morning and again place a dot when you leave the office. Connect the dots and you have a graph displaying your energy levels of that week.

In the bottom you keep track of the tasks you are working on. How detailed they should be? That is up to you, but I don’t add the task: Going to the reception to ask for new scotch. Following the Description column there is a small column where you can write a + or -. Use it to indicate whether a task did contribute to your OKRs or not.

In my previous iteration of the Energy Log, the OKRs area was not there. I just had two graphs, one for keeping track of my energy level in the morning and one for keeping track of my energy level in the evening. This didn’t work because it was hard to see how my energy levels developed during the week. And, I realized I had to add my OKRs, so I merged the two graphs into one, making room for the OKRs.

What are the advantages for me? I see my OKRs a few times day and whenever I update the task lists, I see my OKRs. For every task that I log, I think about whether it added to my OKRs or not. There are days that my work doesn’t contribute to my OKRs, which makes me think about what I need to focus on next week.

Now when I look back six months in time, I can clearly see what I did and whether it gave me energy or not. I am aware of every week that contained tasks that gave me energy as well as the weeks that did not. I have a big pile of Energy Logs, (of course also in Evernote 🙂 ). I discovered for example that my energy increases during the week, I never realized that.

You can take it one step further and share you log with your colleagues. At one moment, there was a colleague who asked me why I had such a bad week? I was wondering how did he know? I found out that he saw the Energy Log on my desk, and sometimes looked at it. It was pretty low that week and we had a good talk about it.

Here you can see a real life example, I created an excel file for printing the log, you can find the log here.

I keep track of the different days by marking the next day with a small dash. In the end, it is all about self discipline as with all logs. When you don’t have the discipline to keep track of the work you do, it will not work to review the form a couple of times a day.

So what does the Energy Log give me in the end? I learned that I should start the week easy, my energy levels rise during the week. So I schedule complex problems or difficult decisions in the middle of the week. I learned that repeating tasks don’t rise my energy level but that helping people gives me energy.

What do you think? Would this help you to link your tasks more clearly to you OKRs and keep focus on your OKRs? Just let me know or share your best practices.

Action: “We should improve communication”… yeah

I assume most of you have attended one or more retrospectives or read the action list of a retrospective. If you were lucky the retro as organized as described in the book Agile Retrospectives: Making Good Teams Great by Ester Derby and Diana Larsen. Setting the Stage, Gathering Data, Generating Insights, Define Actions and Closing the Retrospective. The outcome should be an actionable item list.

Should be… I have seen many action lists that have actions like:

  • Developers should write more unit tests
  • We should improve communication
  • Management should support the team
  • Product Owner should improve the user stories
  • etc.

I think you recognize this kind of actions. How many of those actions were really completed? I suspect most of these actions were not completed and popped up again in next retrospectives. It is hard to change, Jurgen Appelo wrote a nice small book about How To Change The World. Easy to read, and it can give you some tools to change things.

What I would like to address in this blog post is the way how we write down actions. Getting Things Done (GTD) defines Projects and Actions. Example of GTD projects are:

  • Get new staff person on board
  • Orchestrate a one-hour keynote presentation
  • Finalize computer upgrades
  • Get proficient with videoconferencing
  • Finalize employment agreements
  • Get comfortable with new contact management software
  • Finalize staff policies and procedures

According to GTD a project is any desired result that requires more than one action step. Looking back at the actions that described above, in my opinion every action needs more than one action step to have result. So we can conclude that we often see projects, described as actions, as results of a retrospective. It is OK to describe projects but also describe the next actions to get results. Realize also, a project will need more than one action to get results.

GTD can help. GTD defines actions and it is advised you use special verbs to describe your actions. Verbs you can use are:

  • Print
  • Type
  • Draft
  • Review
  • Call
  • Read
  • Meet
  • Email
  • Edit
  • Talk/Discuss about
  • Set up
  • Create
  • Find
  • Research
  • Send

An action should start or have a word like above. That makes an action actionable and something you can really execute. Furthermore, realize that most projects will need more than just one action to get results. As retrospective facilitator or team member challenge the team / help the team to identify the actions to get a project moving.

The challenge for you as retrospective facilitator? Check the action list after your next retrospective, are there actions or projects on the list?

A nice blog about this topic is:

No please.. don’t give a commitment.

Within RES Software we organize every month guild sessions. A guild session is a meeting with all the professionals who work in a certain area or people who are interested in this area. We have for example guild sessions for developers, testers and scrum masters.

Every guild organizes the sessions differently. The goal of a guild session is to exchange experiences and grow knowledge in that area. It is not an update meeting about the projects where everybody is involved in.

In the Scrum master guild every participant has to facilitate a meeting. It was my turn to organize the guild session of last month.

marriage-652124_960_720I decided to discuss the topic commitment. Commitment in a Scrum context. We had a great discussion and it made some people think about commitment. I would like to share the session with you and maybe you also start thinking about the word commitment.

What is commitment for you? Take a few minutes to describe the word commitment for you. Is a commitment equal to a promise? Is a commitment mandatory? Can you deviate from a commitment?

When you search in Google on the definition of commitment you will get the following definitions:

  1. the state or quality of being dedicated to a cause, activity, etc.
  2. a pledge or undertaking
  3. an engagement or obligation that restricts freedom of action

I think the last definition comes most close to the definition as most people use it in a Scrum environment. However, should a commitment restricts freedom of action?

For most people working with Scrum the definition is something like: “Sprint commitment means, that a team promised to finish a fixed number of stories in the next iteration.”

I assume you have some experience with Scrum or software development in general. How many of the following situations do you recognize?

  1. I believe estimations are always wrong. As a team you should try to get 80% of the estimations close to correct in 20% of the time. Whatever you try, you will never get estimations that are 100% accurate (besides the fact this should not be the goal). How can you ask a team to make commitment on results when we all know estimations are just an estimations and never 100% correct?
  2. Management, Product Owners, Stakeholders, etc tend to push teams in some organizations to commit more than they would like to commit. Which team is able to say no to the CEO when he comes in and pushes the team to take that one extra user story? We all know the CEO should not do this, we all know the team should say no, that the scrum master should step in but how many teams really say no or how many scrum masters will step in and discuss this with the CEO? I think there are many teams, especially new teams, who will do what the CEO says and commit to some more work.
  3. People tend to be optimistic and for some reasons developers seems to be more optimistic than other people, especially when it is related to make estimations or commitments. Additionally, there are even optimistic developer…. you guess what kind of commitments they make. The intention is good. However, they will time in time be too optimistic about their commitment.
  4. People get sick and they, normally, don’t inform team members when they will get ill. It will happen unexpected.
  5. It is a good thing that many projects and software products have perfect up to date documentation. However, it seems that sometimes assumptions made on existing documentation are incorrect. The architecture was not as it was described in the documentation, the regression test plan was not updated with the last changes in the software.
  6. The product owner comes back from a visit to a prospect and he needs really one extra user story to be realized in this sprint. If he is able to show this user story, the prospect will buy the product.
  7. High priority bugs will occur and in some situations team members will need to help out. They will be involved in a task force or have to visit the customer site to solve the problem.

To summarize the above, unexpected things can and will happen! That makes software development fun and challenging 😉 However, why do we ask a development team to make commitment when we now these unexpected things can and will happen?

In the Netherlands we always talk about the weather. You want to start a conversation, just mention the weather. The weatherman gives a forecast several times a day for the next hours, days and weeks, Why does he give a forecast and not a commitment? Too many factors that will influence the weather.

When one of the above things will happen a team will probably make not their commitment. This can result in finger pointing to the team, why did you not reach your commitment? It does not matter if a team did deliver 95% of the commitment.. they did not deliver their commitment. Product Owner and/or management will be upset and/or disappointed by the team, the team did not deliver what they committed. In this discussion often the 95% they did deliver is forgotten. It is only about the 5% they did not deliver.

It will be no surprise this will have a negative impact on the morale of the team. They did everything what is possible but because of unexpected things they were not able to deliver their commitment. That is not fair!

Another thing that can happen in the next iteration is that a team will take shortcuts in the quality. Management expects a team to make their commitment, so the team will make their commitment…

I am not unique, more people realize giving a commitment for an iteration is a bad thing. In the begin Scrum talked about commitment. In the current Scrum Guide commitment has been changed into forecast! The Scrum Guide states:

“During the Sprint Planning the Development team works to forecast the functionality that will be developed during the Sprint”.

The following process is described in the Scrum guide:

“After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provide guidance to the Development Team on why it is building the Increment.”

Not a word about commitment anymore!

The product owner and management should care about predictability. It is like a long-term stock investor, they don’t care so much about fluctuations with a day, week or even month, they care about the stock performance over a quarter or a year.

A team should become a reliable partner that is able to forecast their work for several sprints. This will give the business the opportunity to make a forecast for the release. A team should be demotivated by the fact they don’t meet their commitment for one sprint.

A nice quote that I found on the Internet about this topic:

There is no precise prediction of the future in Agile projects. This is a fact you have to accept, if you cannot accept that, you can not work agile.

Wait, don’t forget you can the word commitment! Commitment is very important. I want teams to commit to:

  • deliver an usable increment at the end of an iteration
  • work and grow skills like a real craftsman
  • continuously inspect and adapt
  • the Agile manifesto and values

Commit should be done on behavior, not on the outcome of process.

What is your opinion about commitment?