Grow a Growth Mindset Organization

It is no surprise, but everything is changing faster and faster nowadays. In a report by McKinsey, the authors talk about there being four disruptions impacting the global economy, and one of them is the accelerating technological change.

I did a lot of recruitment interviews in my career and one of my favorite questions during a recruitment interview is: “How do you keep your knowledge up to date?”

Taking into account that everything is changing ever more rapidly and that you need to keep up to date with the relevant developments in your profession, learning is mandatory. Keep developing your skills is mandatory, but what if you believe that you can’t keep developing your skills? What if you believe that what you can learn is limited?

First, let’s take a look at some theory. Professor Carol Dweck did research about development. According to Dweck, individuals can be placed on a continuum according to their implicit views of where ability comes from. Some believe their success is based on innate ability: these people are said to have a “fixed” theory of intelligence (fixed mindset). Others, who believe their success is based on hard work, learning, training, and doggedness are said to have a “growth” or an “incremental” theory of intelligence (growth mindset). [source wikipedia]

As always, it depends on many factors what your belief will be. Do you believe you have a fixed mindset or a growth mindset? I think everyone will say they have a growth mindset.

It is the same with Theory X and Theory Y. Are you an X Person? Nobody is an X person. Still, organizations treat their employees like they are X people. Treating people like X people implies you don’t trust them, believe they are only motivated by money, etc. I believe if you don’t trust your team members, you can’t trust them. It will become a self-fulfilling prophecy. What if the same could happen with learning?

What if an organization believes that most of their people have a fixed mindset? Maybe they will not say it out loud or do it on purpose, but what if they treat their workforce as if they have a fixed mindset. If so, why would they invest in personal development more than needed? Why would they organize exploration days? Why would they give team members time off for personal development?

Organizations who believe in a fixed mindset also don’t appreciate failures. They don’t believe a failure is a learning opportunity. It is a sign you don’t have the knowledge, it is a failure.

Let’s look at the growth mindset organization. What if an organization believes people have a growth mindset? Managers will stimulate people to learn, and employees want to grow themselves. Exploration Days are organized and people join because they like to learn and explore new stuff. The organization is not afraid of mistakes: nobody is perfect and mistakes are an opportunity to learn. People celebrate learning!

Dweck believes that the growth mindset will allow a person to live a less stressful and more successful life. One of the 12 Steps of Happiness is also an experiment, and experimenting is equal to learning.

You can help people to develop a growth mindset. You can work to give your organization a growth mindset.

It is about providing feedback on their work and on the effort people put in a task. If you just focus on the result, tell them they are great, smart, etc. they will feel complimented for the knowledge they currently have. If you compliment people for the hard work, learning, and effort, you compliment them on the actual learning and development. You can also challenge people, not with assignments that are impossible but with assignments just outside their comfort zone. Help them, or provide help, to have them bridge the gap between being in their comfort zone and realizing the assignment. By doing this, these people will develop a growth mindset, step by step.

A growth mindset is not there because you just put a lot of effort into learning. It is also about how you learn: achieve something, talk about it, see where you have a further knowledge gap, and then make the next step.

Sounds almost like being Agile, right?

(This article first appeared on LinkedIn.)

How do your metrics help you?

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.

12 guidelines for good metrics

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!

 

Teams don’t like me as Scrum Master

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?

Why is HR not agile?

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?