I love to measure things. I can look up the temperature in my house for the last two years. Did you know it was 16.5 degrees Celsius on November 2, 2017, at 02:12 AM? I track the downloads of my book Doing It. 2736 downloads up and till 2018-05-20 7:02:00. I measure the steps I take every day, did you know I took 287.216 steps in October 2015? As I said, I love to measure things.
I hear you thinking… nice Ralph but how is this going to help me as a professional? Not. It is not going to help you. The more important question for me is, how is this going to help me as professional or person?
Silence… I don’t know. I don’t see how the history of the temperature in my living room is going to improve my life. I don’t see how the number of the steps from the past is going to improve my health in the future.
If you are a lead or manager, you probably need to create a report every week. Maybe you have automated it, and you created a dashboard. A dashboard where management can check the metrics of your team or organization. Regarding that dashboard, sorry to disappoint you, but I expect your manager hardly ever checks the dashboard.
Take a look at the report. Which data is there? Probably data that is easy to measure. Like the living room temperature, the steps I take, etc. We tend to create reports on things that we can measure easily. Often these measurements are related to output. Something happens, and some data is available. We call these indicators, lagging indicators.
Lagging indicators are often easier to measure, but it is hard to make a change in a process based on lagging indicators. For example, I measure the temperature in my living room, but the temperature is something that already happened. I can’t change it anymore. Measuring the number of new hires is also a lagging indicator. It already happened. You can’t influence the process anymore.
We also have leading indicators. Leading indicators say something about what is going to happen. For example, the temperature outside could be a leading indicator of the temperature in my living room. When the temperature outside is 35 Celsius or more, I know the temperature in my living room is also going to increase. If the influx of candidates is growing in an organization, I can expect the number of new hires also going to increase.
I will give you another example. I try to maintain a stable weight. A lagging indicator is measuring myself every day. It already happened, there is nothing I can change anymore. A leading indicator could be to measure my activities, and food I eat during the day. These are leading indicators. I know when my activities decrease, the number calories increase, my weight will probably increase.
The question is when you look again at your dashboard or report, what kind of indicators do you have? Leading or lagging indicators?
Would you like to learn more about good metrics? Join my workshop on July 3rd in Utrecht. More information can be found here.
One of the views of Marti, the Management 3.0 Monster, is Align Constraints. Align Constraints is for me about the behavior of people, but also about direction. In a Management 3.0 environment, there are maybe teams who are self-organizing, and also self-steering. These are two different things!
Self-organizing teams are common practice nowadays, definitely when an organization has implemented Scrum. As it is written in the Scrum Guide: “Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” These teams are not self-steering! They don’t decide themselves where to go. They only choose how to go, when the Product Owner has decided where to go.
As an organization, you can go one step further, and also create self-steering teams. Scary of course… how do you know they will walk or maybe even run in the right direction? You don’t, that makes it scary. When you would create self-steering teams, and they would go into a direction you, as manager, don’t like? What to do? You could step in, and order them to go into the “right” direction. However, by doing this, you just destroyed the self-steering team. It turned out it was not self-steering. You decided to step in…
If you are going to work with self-steering teams, it would be wise to implement a Delegation board. Also, understand your role as manager in the delegation board. Also, you need to make there is a clear vision and purpose for the organization. This will give the team a direction.
However, there is another thing that is required for self-steering teams. Metrics! No target-setting based on metrics, but metrics to understand what is happening.
There are 12 Guidelines for good metrics. If you keep those guidelines in mind, it helps you to develop useful metrics. Metrics that a self-steering team can use to find out where they are going and how they are performing.
Guideline 1: Measure for a purpose.
What is the reason you are measuring? Can you give a reason in a few seconds? If not you should question your metric.
Guideline 2: Shrink the unknown.
Always measure from multiple perspectives. Not just measure one dimension of a system, but try to measure various dimensions to understand what is happening in a system.
Guideline 3. Seek to improve.
How does the metric help you to improve? Is it an actionable metric? Or just a metric to make you feel good?
Guideline 4: Delight all stakeholders.
An organization is a complex adaptive system. There are many people and systems involved. You can’t please everyone, but you at least want to know when someone is getting unhappy.
Guideline 5: Distrust all numbers.
In the end, numbers are just numbers. Do you really believe 42 is the right answer? Always keeping your mind when you see numbers.
Guideline 6: Set imprecise targets.
Every process has a biorhythm. Every process always has deviations. Do you want to focus on every difference? Or just the significant exceptions?
Guideline 7: Own your metrics.
Involve the team, if possible ask the team to create their own metrics. By doing this, the team knows what is measured and will also get maximum insight into the data.
Guideline 8: Don’t connect metrics to rewards.
Do I really need to explain this?
Guideline 9: Promote values and transparency.
Make sure all your metrics are visible for everyone, but also work on values that promote correct behavior.
Guideline 10: Visualize and humanize.
Nowadays, you can create pivot tables in six dimensions, use extreme colors, almost an art itself. However, it is not the goal to use all features in Excel, the goal is to make simple to understand.
Guideline 11: Measure early and often.
Depending on your goal, you need to think about the frequency. Would it make sense to update traffic information in Google Maps every 1 millisecond, or would every five seconds also do?
Guideline 12: Try something else.
After a while, that can be any time, your metrics won’t give you any useful data anymore. The system changed, or it adapted itself to fit into the metrics. Time to change, an experiment with new metrics.
12 guidelines that can help you to improve your metrics. You will need good metrics to work with self-steering teams, to understand what is going on. These guidelines can help you to develop useful metrics.
If you want to learn more about this, feel free to reach out to me!
As maybe most of you already know, the Happy Melly One team is completely distributed. In case you didn’t know let me tell you about our team.
We cover four continents, five time zones, six languages, and eight people. The team, in different settings, has been working together since 2011. You can read more about our team members on this page.
Our zookeeper is Lisette Sutherland. She recently published a book about Distributed Teams. We are not going to promote the book here, but in case you are interested click here. Lisette interviewed more than 100 people. Asked them about their experiences with all kind of different setups of remote teams. The Happy Melly One team is of course also mentioned in her book.
We do everything remotely and use all the best practices regarding remote working.
We always use webcams when we are in a meeting. Webcams are turned on, no discussion about that. Even when one of our team members is still in bed (and decently dressed, no worries). We all have the best headsets; we even once ordered a headset for a team member who didn’t think they needed one (they did!). We all are aware a perfect internet connection is essential.
We use the best tools available, and fit for our team. We use Slack instead of email; all information flows through Slack. Even when you have a question for one person we use Slack. We are in love with threads in Slack. We use Zoom for meetings. It is reliable and always works. When on a group call, you are not affected by the lowest bandwidth of one person (like Skype). Also, the gallery view of Zoom is great because we can see everyone on the call at the same time. We use IDoneThis to have asynchronous conversations every day. We use Bonusly and Kudo Cards to give each other compliments and feedback. We have introduced the concept of a proposal document to be able to make decisions in a distributed team. We use Google Docs for collaboration on documents. And most of all, we apply the concept of working out loud. Yes, we are definitely a showcase in Lisette’s book as proof that remote teams are possible and can be effective.
So far, so good… So what is the problem?
We did not realize that it could have been so much better all these years. This is also described in the book as a must-do and it’s one thing we didn’t do until January this year.
In-person retreats! Sorry if you expected something more shocking. It is that simple.
As I said, we all agree that remote teams can be as effective as co-located teams, however only when you realize it is not like working in the office. You need to set up extra tools, working agreements, hardware, etc.
However, getting together now and then, and looking each other in the eyes while discussing difficult topics, partying together, and being able to work for hours in a row together on a topic is important.
We believe that as a team, we made a huge step forward after our last retreat. One of the most important conclusions from that retreat, which was our first, was that we need to do this every six months.
So our next retreat will be in Dublin at the end of June. Again a weekend of building relationships, working for hours together, being able to make decisions and most of all, having fun. Last time not everyone was able to make it, we had three people joining remotely, this time almost everyone will be able to make it!
So remote teams are great, but meeting each other a few times a year makes things even greater!
It is true… development teams don’t like me as Scrum Master. They blame me, they tell me it is my fault, they tell stakeholders that Ralph the Scrum Master said it was not good enough. Probably making the stakeholders think: “Who is that guy to decide if it is good enough?”
Why do they don’t like me? Because after one sprint of hard work, I am the one who tells them that they are not allowed to show the results of their hard work to the product owner and stakeholders. It is me who is so black and white. It is me as Scrum Master who doesn’t understand that they really worked hard and even did some overtime!
Sometimes the product owner or some of the stakeholders ask me “Ralph, but why not, this seems so unfair?”
OK, let me explain why sometimes I am a horrific Scrum Master in the eyes of the development teams.
We all know these projects where the team reports 80% of the work as done, and when the software/framework is done, we can do everything we need to do, and even more. OK… sounds good, so let’s just wait until that final 20% gets done. For some reason, however, that last 20% of the work will then start taking 80% of the project time.
What will happen when a development team shows work done during the sprint that is not really done? Maybe they even say, it is not completely done. Trust me, when stakeholders leave the room, they will remember the software that has been shown during the demo. They will forget that small footnote, it is not done yet. So the impression is, the project is on track, everything was done.
The team will still need to finish the items that they showed during the sprint review (not sprint demo!) The work that is not done could pile up, and it will take a few days in the next sprint before they can start working on the new sprint goal. With a bit of bad luck, this will get worse over time, and also influence the velocity.
The most important reason I forbid teams to show work that is not done at the end of the sprint, there is no learning! No reason to improve! Scrum is for me all about making things visible, being transparent, and inspecting and adapting. If we don’t show to each other that we don’t have items done, why improve?
Let me tell you about a few recent examples, where I coached teams and made them have a bad day because of this.
One team committed to two items in one sprint. They estimated the items to be around 40 points. The team believed they were able to make around 80-100 points in a two-week sprint. I told them upfront, guys it could be smart to split up those items. Either the team was too stubborn or I did not explain myself clearly. The day of the sprint review came and I asked hey guys, what are you gonna show during the sprint review? Those two items? Are they done? Yeah, almost, 90%… Nope, you are not gonna show them. I used my veto and forbid it. The team was upset and blamed me explicitly during the sprint review. Fine, no problem for me. Guess what happened in the next refinement session… they split all big stories up into small stories.
A second case. One team had a big dependence on a visual designer. However, this person was overloaded with work and also reported ill a few days during the sprint. The team said we can show and report it done during the sprint review. The only thing we need to do is to do the styling, but we can explain this and do it next week. Well sorry again team, but you are not gonna show these items. They are not done. I would like you to report why it is not done, though, because of your dependency on the visual designer. You should make the organization aware of this problem, by mentioning it during the sprint review, and the impact, it will get attention. There was a second team who reported the same issue. The result was that the management team looked into, and started to get some extra project funding together to get an additional visual designer.
To make this all work, make sure you have a good Definition Of Done. The Definition of Done is used to decide if an increment or backlog item is done. In a very transparent way, the Scrum team should know what the Definition Of Done (DoD) is. As Scrum Master, you can refer to the DoD and not just because “I say so.”
I hear you thinking, Ralph, Scrum is all about inspecting and adapt, and you throw away this opportunity. True, I throw away THIS opportunity, but the moment I tell the team no you are not gonna show it, I also ask them to schedule a meeting with the Product Owner asap to show the progress to him. Furthermore, I advise them to have regular meetings between Product Owner and team members to discuss progress. The sprint review can and should be no surprise for the product owner.
What do you think, do teams don’t like me for a good reason?
The title of this blog post triggered you: Either you agree, or you disagree.
Let me first explain in a nutshell why you need agile, and then how it relates to HR.
I have a background in software development. Many frameworks in software development assume they can predict the future. In other words, they think projects can be managed entirely by making big plans, introduce hand-over moments, etc.
In the nineties, we had the Software crisis, the software was always too late, and quality was too low. The industry had to do something. There were two ways to go: one that would introduce even more frameworks, steps, documents, etc and the other is what we now call agile. To me, agile proved about realizing that you need to use an empirical approach to manage complex projects.
What makes those projects complex? I could name a wide variety of things here, but one of the most important factors is the fact you work with people. You simply can’t manage people like a machine. Nowadays we call this management 1.0, and you can read all about it in the works of Frederic Taylor.
In my career, I worked with many people from Human Resources, Human Capital and probably there will be more different names for this department. I don’t like it when people talk about ‘human resources’, but in this blog post, I will refer to HR as the organization who in most organizations needs takes care of hiring, career development, salaries, firing, etc.
All those organizations had one thing in common. They worked with corporate models for personal development and reviewing people. At every organization, HR created a framework to help people grow and to help managers to review people. In most cases, HR headquarters created it, sometimes assisted by a fancy consultancy company. The HR department then would develop this model further for all employees, and because they realize they have different functions, they described a lot of skills, competencies, levels, etc.
When we execute technical projects, we use an empirical approach. We are transparent and inspect & adapt. We understand that we need to be flexible, that we need to embrace change and realize that every project needs a different approach. We come to understand that there is no magic approach that will solve everything.
So why does HR still believe that they can develop a framework that can cover everything related to people? Why do they develop one size fits all frameworks that all departments need to use? Why do get agitated when a manager decides to disagree with the HR model?
I think the time has come for HR to use a different approach.
HR has a lot of knowledge about local employee laws, skills, competencies, and people. I am not saying they are prutsers. Definitely not! I am just saying they are using the wrong approach.
Why not create some guidelines, or principles on what you expect managers or teams to take care of? I think it is very useful to use a model in some cases. Nothing wrong with that.
HR should ask teams and managers to think about how they are going to help people develop themselves. They should offer their expertise when asked for by teams, tribes or departments. They should give teams and or departments the freedom to develop their own approach.
Isn’t this very ineffective or inefficient you may ask? Perhaps, I am not saying you should not talk to each other and learn from each other. However, I believe it should mostly be a bottom-up approach. When a manager does not know where to start, HR should definitely help that manager. They should help the manager develop a framework that fits the manager’s department or team. In doing this, there is nothing wrong to be inspired by frameworks that are used by other departments or teams.
So why is HR not doing this?