Many, many, many years ago, I did a two-day workshop ISTQB Foundation. At the end of the two days, there was an exam: 30 multiple-choice questions about software testing. I passed the exam and I got the Foundation Certificate in Software Testing. Did this make me a great software tester? No way. It merely meant that I answered a set of questions correctly, in a specific place, somewhere in time. Was it a waste of money and time? No, definitely not.
We attended the workshop with several software testers and it gave us some great ideas on how to implement testing within an Agile context. Hey, we are talking 2005 here! There were no books yet about testing and Scrum. By doing the workshop, we created a common view on testing and it allowed us to use a common language. One of our testers did not pass the exam. On a side note, within four months that person left the team. Trust me, the exam was not that hard.
This certification was really about verifying basic knowledge. If you were not able to pass this exam, something was wrong. It could be dyslexia, but also a lack of knowledge regarding software testing. It was also about creating a common language: all testers understanding what a Risk Matrix is, and what equivalence partitioning is. It also created a mindset that testers should also develop themselves by doing training, reading books, etc.
I did a follow-up training then: ISTQB Practitioner. The training was eight full days in total and there was again a possibility to get a certification. The certification exam lasted for three hours and consisted of a number of open questions. Just five or seven open questions as I recall. I did the exam and manually wrote 15 pages or so just to answer these questions! No laptop, 15 pages of me and my pencil. It took a month or so before all exams were reviewed and we got the result. I passed the exam and got my Practitioner Certificate in Software Testing. I valued this certificate so much more. Passing this exam really did mean something. I believe only 70% of the attendees passed the exam. By passing the exam, you showed you were able to come up with solutions for complex testing problems, test strategies, test techniques, etc. Still, it did not guarantee for 100% that you were a great tester, but it had much more value for me than the first certificate. For example, when I had to recruit software testers, every software tester who had the ISTQB Practitioner certification was automatically invited for the first interview. I knew those software testers had a passion for software testing, were willing to invest in growing their skills, and definitely had a sound knowledge about testing.
I believe certificates are great as long as you give them the right value. A certificate with multiple choice questions that you can answer without much knowledge does show that you are willing to invest in your skills. If you pass the exam, it shows you have some basic knowledge about a topic. You can talk about the topic with somebody else, you have a common language. Nothing wrong with that. However, it doesn’t prove you can do the job!
A certificate with open questions, where you have to show the experience you possess, has a different value for me. It shows again that you are willing to invest in yourself, and often more than the average professional. It also often shows that you really applied the framework or techniques and that you were able to reflect on the outcome of your actions. Still, of course, no 100% prove you can do the job and of course it also depends on the questions.
What do you think? Certifications BS or not? Should we forget about Certifications? Just use badges linked to experiences?
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.)
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!
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?