Scrum tools are useful in many situations, not only for their original purpose. For example, you can use the burndown-tool to track meetings and make them more efficient. In addition, the participants of the meeting get a feeling for Scrum and it's focus as well as its transparency.
This is, how it works: You of course have to plan the goal and the agenda of the meeting, including rough time estimates for each agenda point. then take two flip-charts and draw a "task board" and a standard burndown. Write one sticky note for each agenda point (write legibly!) and put them in the first column of your task board. Choose a "iteration length" of five minutes (you can extend or shorten it after you tried it once). This is the timebox after which you draw the burndown and check if one of the agenda-points has to be moved from one column to the next.
When the meeting starts, take three minutes to briefly explain what those sheets of paper mean and how they relate to Scrum. If questions arise, answer them quickly, but don't go into depth - you can still do that after the meeting once you have reached it's goal. Draw the burndown line (and move the "tasks") without any comment during the meeting, but make sure everybody sees the board(s). You will notice that people get nervous and keep themselves shorter if the actual progress deviates from the "ideal line". When the meeting is over, take five minutes for a quick retrospective about this experience for management.
It helps, if you don't have to moderate and track the progress at the same time. Furthermore, you can color-code the sticky notes according to your needs. In any case, make sure you have inserted the "ideal line" - otherwise the focus is lost for your management colleagues.
When I did this (at a big automotive company), the meeting participants were enlightened. They experienced instant focus on the topic, full transparency within five minute slices, and they met the goal because they could adapt to changes (note the sudden drop after minute 35 - this agenda point was shortened due to the delay). On top of that, they felt the pressure they put on themselves. This helped very much in persuading them afterwards, that they do not have to exert control over the Scrum teams, because those are pressured already and the transparency is real (in opposition of the melon status they usually get - green on the outside, but squishy red on the inside).
Here is an example from one meeting where I did this:
Saturday, September 15. 2012
Can you change Scrum?
Quite often people come up to me in training or coaching and ask me if it is possible to "tweak" or "alter" Scrum. Well, the answer to this is quick: Sure you can. Just go to https://www.scrum.org/Scrum-Guides/Change-the-Scrum-Guide and continue from there. Changing Scrum is like changing any other rule book: You can do this, but you need the approval of the authors. Imagine you want to change the rules of chess: If you want to change the walking-path of the king to match that of the dame, you will need to persuade quite a community. It's easier with Scrum though, because Scrum lives continuous inspection and adaptation and there is a process for it (see the link above).
What people really mean is, if they can leave out certain Scrum elements in their specific Scrum implementation. Well, it's their company, so of course they can - but then they are no longer doing Scrum and have to rename their process to something else. Besides, they will most likely miss the benefit of the element they are ditching.
But do you have to follow Scrum forever, even after you have truly mastered Agility in your enterprise? Of course not.
Scrum is a tool, like a hammer. Once it served it's purpose (the nail was driven into the wall), you can put it away (stop using Scrum).
I mean, our goal is after all to improve the profession of software development (or of all knowledge workers in my case), increase the job satisfaction of the people and increase the return on invest for our companies. In my opinion, this means to transform organizations to become agile from the heart. Once they are there (and sustainable!), they are like grown children and can make their own decisions. So, sure: If they really know what they are doing, they can abandon Scrum.
BUT: None of my customers has reached that sustainable state so far. They usually are in a advanced learning stage (or even early beginners) when they decide to abandon some practice and tend to fail once they do so. Therefore, whatever they want to change, I never allow them to drop retrospectives and analyze with them what happened after they altered something. So far, they always went back to Plannings, Daily Scrums and so on.
Usually, if somebody wants to deviate from Scrum, that person is trying to cover some dysfunction instead of solving it's root cause. Let's take an example: A short while ago a development Team came up to me and told me that they had decided to stop doing Retrospectives. I asked them to come together the same day and worked with them on the root causes for their decision (so yes, I did a Retrospective with them even though they had decided to stop doing those - I apologize, guys!). The result was a deep frustration with their organization because everything that had to be changed outside the Team took ages and always got watered down to tastelessness. The Developers felt that the organization was not appreciating agility, or even their employees. "We are just numbers," one colleague said. And he was right.
In the end we continued to do retrospectives and tried to work harder on the corporate culture. This process is still going on and will most likely take another 7-10 years.
Whatever problem set we are talking about, you have to use the right process for it. Scrum is an empirical framework made for complex problems. If you try to apply it on simple problems, there is a mismatch. The same is true when you try to deploy predictive processes on complex problems. It just doesn't work the way it should. The same is true for corporate and personal values: Some value sets (or "cultures") will produce better suited solutions for specific problem sets than others. You can find out if there is a mismatch by looking at the success rate of your projects. If you encounter a bad yield rate (<90%), try to reflect on your problems, solutions and culture. Maybe you are using the wrong process. Maybe you are looking at your problem from the wrong angle. Maybe you should get up, spit into your hands, and solve your root causes without trying to apply the tools that led to the high failure rates in the first place.
What people really mean is, if they can leave out certain Scrum elements in their specific Scrum implementation. Well, it's their company, so of course they can - but then they are no longer doing Scrum and have to rename their process to something else. Besides, they will most likely miss the benefit of the element they are ditching.
But do you have to follow Scrum forever, even after you have truly mastered Agility in your enterprise? Of course not.
Scrum is a tool, like a hammer. Once it served it's purpose (the nail was driven into the wall), you can put it away (stop using Scrum).
I mean, our goal is after all to improve the profession of software development (or of all knowledge workers in my case), increase the job satisfaction of the people and increase the return on invest for our companies. In my opinion, this means to transform organizations to become agile from the heart. Once they are there (and sustainable!), they are like grown children and can make their own decisions. So, sure: If they really know what they are doing, they can abandon Scrum.
BUT: None of my customers has reached that sustainable state so far. They usually are in a advanced learning stage (or even early beginners) when they decide to abandon some practice and tend to fail once they do so. Therefore, whatever they want to change, I never allow them to drop retrospectives and analyze with them what happened after they altered something. So far, they always went back to Plannings, Daily Scrums and so on.
Usually, if somebody wants to deviate from Scrum, that person is trying to cover some dysfunction instead of solving it's root cause. Let's take an example: A short while ago a development Team came up to me and told me that they had decided to stop doing Retrospectives. I asked them to come together the same day and worked with them on the root causes for their decision (so yes, I did a Retrospective with them even though they had decided to stop doing those - I apologize, guys!). The result was a deep frustration with their organization because everything that had to be changed outside the Team took ages and always got watered down to tastelessness. The Developers felt that the organization was not appreciating agility, or even their employees. "We are just numbers," one colleague said. And he was right.
In the end we continued to do retrospectives and tried to work harder on the corporate culture. This process is still going on and will most likely take another 7-10 years.
Whatever problem set we are talking about, you have to use the right process for it. Scrum is an empirical framework made for complex problems. If you try to apply it on simple problems, there is a mismatch. The same is true when you try to deploy predictive processes on complex problems. It just doesn't work the way it should. The same is true for corporate and personal values: Some value sets (or "cultures") will produce better suited solutions for specific problem sets than others. You can find out if there is a mismatch by looking at the success rate of your projects. If you encounter a bad yield rate (<90%), try to reflect on your problems, solutions and culture. Maybe you are using the wrong process. Maybe you are looking at your problem from the wrong angle. Maybe you should get up, spit into your hands, and solve your root causes without trying to apply the tools that led to the high failure rates in the first place.
Friday, August 31. 2012
Agile Tour goes Germany
Finally, the Agile Tour comes to Germany. It's a community event, aiming at creating interest in agility and lowering the barrier to participate. The participation fee will be as low as 50 Euro (incl. VAT). The venue for up to 75 guests takes place at a very pretty building in Stuttgart (I'm sure you'll like it!) on the 22nd of November this year. We will offer a variety of talks, starting at the beginner level ("e.g. What is Scrum?") and ranging up to the experts ("e.g. Enterprise agility"). However, the final agenda will be fixed at the end of September - this means you can still give us some input, if you like.
Any questions? Shoot me (or the other organizers) an email.
All information can be found at http://agiletour.de/
Any questions? Shoot me (or the other organizers) an email.
All information can be found at http://agiletour.de/
Sunday, August 12. 2012
The reasons why distributed teams are less effective
There is an agile myth out there: Collocated teams are at least 40% more productive than dispersed (same team on different locations) or distributed (different teams on several locations) ones. I recently did some study on that topic and found a model that very neatly explains the reasons behind the drop in performance. Maybe this knowledge will aid you in your daily work.
The model I am talking about is the "virtual distance model", invented by Karen Sobel Lojeski and Richard R. Reilly. The model is fully described in their 2008' book Uniting the Virtual Workforce: Transforming Leadership and Innovation in the Globally Integrated Enterprise.
The authors state that virtual distance applies for every human interaction with another human being. It consists of three dimension: Affinity distance, physical distance and operational distance. While many other authors focus on "geographic distance", Karen only sees it as a fraction of physical distance. It is supplemented by temporal distance and organizational distance. Let's look at it more closely and see, if you have met those before.
Geographic distance means that people are physically apart - 15 meters or more. So as soon as there are stairs involved, a wall or too many steps to walk, you are faced with geographic distance (Thomas J. Allen did a study in 1977 and published it in his book Managing the Flow of Technology - you can read more about the exact distance and classification there.)
Temporal distance means that people are working asynchronously. This can either happen if people are working in different time-zones (that's obvious, of course). But this can also happen if people start and end working at different times. For example, if somebody starts work at seven and finishes at three while somebody else comes in at 11 and stays until eight in the evening, you are faced with temporal distance.
Organizational distance basically means that there usually is a distance between different departments and organizations. You can spot this when people start talking about "us" and "them". Did you ever condemn "those stupid marketing people"? Well, there you go...
You can see, that physical distance is far more complex than just "being in different countries". This is similar with "operational distance", which basically means that the tools and frame conditions can pose a problem, contributing to virtual distance. Communications distance is pretty obvious: You can send less information via email than you can in a face-to-face interview. Unfortunately, most people don't mind this knowledge and communicate most of the day via email. I could name many instances on the spot, where just the communication channel contributed to a major conflict in an organization... All media can be considered according to it's "media richness". The media mix must fit the needs of your team and environment. If it doesn't, you increase your operational distance.
In our Professional Scrum Master courses we teach our students that multi-tasking is a bad thing. Of course I know this from my own experience and lean teaches it as well. But here comes the interesting bit: Multitasking contributes to operational distance due to a lack in focus. Or easier put: People don't feel as close to one another if they are working on different things and they are walking on edge due to the stress involved in task switching.
Even if you heed those lessons, "readiness distance" can break your neck. It describes the "readiness" of your IT infrastructure. Imagine that you have a beautiful communication strategy which involves video conferencing. Then you have your first meeting, switch on the equipment - and nothing happens. People grow inpatient while you try to fix it, call in your IT expert only to be told that "there is a license missing". If you are lucky, people won't give up on you just yet...
Distribution Asymmetry is the last part of the puzzle to complete operational distance. It means an unbalanced distribution of your workforce. For example, if two of your people are working in the satellite and five are in the group headquarters, you instantly get "them" and "us" again. By the way: This happens the other way around as well.
The most important distance is the "affinity" distance. You can have it even if your people are sitting right next to each other. It comprises of cultural distance, social distance, relationship distance and interdependence distance. You probably know cultural distance - it happens if people have different cultural backgrounds. This can be true within a country as well: In Germany for example there is a slightly different culture in "East" and "West" as well as between the different states. A Bavarian has a certain cultural distance when interacting with a "northern light" coming from Hamburg (any other state could have been chosen here as well). Social distance means the status within society, that might oppose that of a team mate. Imagine an "Earl of Winchester", honored with an phd and teaching at university, working together on a project, formally equal, with John Doe, who just has finished high school. Can you imagine any conflicts arising from that constellation? While this constructed example is quite obvious, there are many social nuances that have to be considered and addressed in a team if you want to keep the social distance low.
Relationship distance is described as "the extent to which you and others lack relationship connections from past work initiatives". Flatly: People don't know if they can trust each other, because they don't know their new colleagues. It manifests as a "sense of unfamiliarity".
Interdependence distance happens mostly when there is no shared vision. People don't walk into the same direction and therefore don't commit to each other. Maybe you have spotted sentences like "well, my part is working, it's <put a name in> who has to fix his code, not me".
As you can see, there are many dimension you have to consider when forming a virtual team. All of the aforementioned distances will occur, it's up to you to make them transparent and to address them. They are not bad in themselves - they are natural. They are one of many reasons why you desperately need Management - you will fail if you try to solve this immense problem by yourself. It's easier of course, if you stay with collocated teams. It reduces your project complexity. Unfortunately, 65% of the teams in our industry are not collocated but distributed or dispersed. Those teams will be (on average) less productive than the collocated ones. But they can be of strategical importance and there usually are reasons why the companies go for them. Don't condemn them too quickly. And then get back to your work, make the different dimensions of distance transparent, measure them and reduce them.
Good Luck!
The model I am talking about is the "virtual distance model", invented by Karen Sobel Lojeski and Richard R. Reilly. The model is fully described in their 2008' book Uniting the Virtual Workforce: Transforming Leadership and Innovation in the Globally Integrated Enterprise.
The authors state that virtual distance applies for every human interaction with another human being. It consists of three dimension: Affinity distance, physical distance and operational distance. While many other authors focus on "geographic distance", Karen only sees it as a fraction of physical distance. It is supplemented by temporal distance and organizational distance. Let's look at it more closely and see, if you have met those before.
Geographic distance means that people are physically apart - 15 meters or more. So as soon as there are stairs involved, a wall or too many steps to walk, you are faced with geographic distance (Thomas J. Allen did a study in 1977 and published it in his book Managing the Flow of Technology - you can read more about the exact distance and classification there.)
Temporal distance means that people are working asynchronously. This can either happen if people are working in different time-zones (that's obvious, of course). But this can also happen if people start and end working at different times. For example, if somebody starts work at seven and finishes at three while somebody else comes in at 11 and stays until eight in the evening, you are faced with temporal distance.
Organizational distance basically means that there usually is a distance between different departments and organizations. You can spot this when people start talking about "us" and "them". Did you ever condemn "those stupid marketing people"? Well, there you go...
You can see, that physical distance is far more complex than just "being in different countries". This is similar with "operational distance", which basically means that the tools and frame conditions can pose a problem, contributing to virtual distance. Communications distance is pretty obvious: You can send less information via email than you can in a face-to-face interview. Unfortunately, most people don't mind this knowledge and communicate most of the day via email. I could name many instances on the spot, where just the communication channel contributed to a major conflict in an organization... All media can be considered according to it's "media richness". The media mix must fit the needs of your team and environment. If it doesn't, you increase your operational distance.
In our Professional Scrum Master courses we teach our students that multi-tasking is a bad thing. Of course I know this from my own experience and lean teaches it as well. But here comes the interesting bit: Multitasking contributes to operational distance due to a lack in focus. Or easier put: People don't feel as close to one another if they are working on different things and they are walking on edge due to the stress involved in task switching.
Even if you heed those lessons, "readiness distance" can break your neck. It describes the "readiness" of your IT infrastructure. Imagine that you have a beautiful communication strategy which involves video conferencing. Then you have your first meeting, switch on the equipment - and nothing happens. People grow inpatient while you try to fix it, call in your IT expert only to be told that "there is a license missing". If you are lucky, people won't give up on you just yet...
Distribution Asymmetry is the last part of the puzzle to complete operational distance. It means an unbalanced distribution of your workforce. For example, if two of your people are working in the satellite and five are in the group headquarters, you instantly get "them" and "us" again. By the way: This happens the other way around as well.
The most important distance is the "affinity" distance. You can have it even if your people are sitting right next to each other. It comprises of cultural distance, social distance, relationship distance and interdependence distance. You probably know cultural distance - it happens if people have different cultural backgrounds. This can be true within a country as well: In Germany for example there is a slightly different culture in "East" and "West" as well as between the different states. A Bavarian has a certain cultural distance when interacting with a "northern light" coming from Hamburg (any other state could have been chosen here as well). Social distance means the status within society, that might oppose that of a team mate. Imagine an "Earl of Winchester", honored with an phd and teaching at university, working together on a project, formally equal, with John Doe, who just has finished high school. Can you imagine any conflicts arising from that constellation? While this constructed example is quite obvious, there are many social nuances that have to be considered and addressed in a team if you want to keep the social distance low.
Relationship distance is described as "the extent to which you and others lack relationship connections from past work initiatives". Flatly: People don't know if they can trust each other, because they don't know their new colleagues. It manifests as a "sense of unfamiliarity".
Interdependence distance happens mostly when there is no shared vision. People don't walk into the same direction and therefore don't commit to each other. Maybe you have spotted sentences like "well, my part is working, it's <put a name in> who has to fix his code, not me".
As you can see, there are many dimension you have to consider when forming a virtual team. All of the aforementioned distances will occur, it's up to you to make them transparent and to address them. They are not bad in themselves - they are natural. They are one of many reasons why you desperately need Management - you will fail if you try to solve this immense problem by yourself. It's easier of course, if you stay with collocated teams. It reduces your project complexity. Unfortunately, 65% of the teams in our industry are not collocated but distributed or dispersed. Those teams will be (on average) less productive than the collocated ones. But they can be of strategical importance and there usually are reasons why the companies go for them. Don't condemn them too quickly. And then get back to your work, make the different dimensions of distance transparent, measure them and reduce them.
Good Luck!
Thursday, July 12. 2012
Knowledge as impediment
Experience is defined as
I am sure you are aware of Shuhari. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms".
Well, this is pretty abstract. You could maybe summarize it as "First you obey the rules, then you deviate a bit and finally you no longer think about them, it all feels natural." Personally, I prefer the Dreyfus-model.
As you can see in this picture, the Dreyfus model knows five stages of skill acquisition: Novice, Advanced Beginner, Competent, Proficient and Expert. While the Beginner is just able to "follow the rules", the Expert "just does what works". In between, rules first have nuances and become conditional. Once competent, the person learns the rules behind the rules shaping context and conditions. Finally, intuition comes into play.
As far as the skills stretch, the sense of responsibility grows as well. But what does this have to do with Scrum? Well, a lot actually.
You know of course, that your team members will go through all of those stages and that the rest of the team should help each individual to proceed as quickly as sensible. But have you ever thought about yourself? In what stage are you? Don't be too hasty in your decision. Many people have a differing self-perception from other people's views. Especially Scrum Masters, who are usually quite self-confident and need a thick fur to enforce the rules of Scrum tend to consider themselves "Experts" once they start to see the principles behind Scrum. In truth, they are just Advanced Beginners, but they proclaim proudly to have mastered the art of Scrum. It is quite interesting to discuss nuances and the practical application with them (I admit that I like heated discussions). Unfortunately, quite often you quickly reach the point where the Advanced Beginners resort to the "because Scrum says so" argument. That's the minute where the discussions grow stiff and awkward, depending on the individual character.
Nobody can be an expert in all fields. On top of that, Scrum is just a framework with many holes. You need vast additional expertise to fill those professionally. Just think about things like:
Now, if an Advanced Beginner starts discussing Scrum with experienced managers (who tend to be Competent or Proficient in their area of expertise), those quickly spot the lack of context and depth. Credibility and trust are lost. Sometimes Scrum is blamed for the incompetence afterwards (which usually just helps in political plays or fears for change, but nevertheless is harmful for the company's transition). This is a severe impediment. Without trust, Scrum cannot work.
I strongly recommend to create transparency for yourselves and the people you work with. Clearly state where your skills lie - and where you consider yourself a Novice. Don't rely on your own perception but ask others about their opinions. In each area of expertise, there are only few experts out there. Don't consider yourself one too light-headedly. Help others with less experience to develop themselves - for example by coaching them. Strive to improve yourself at every opportunity as well. Whenever you catch yourself not being able to explain something or resorting to "because ... says so"-answers, investigate further and look at the Dreyfus model again. Accept that there is always a "bigger fish" out there (which means a "better expert" of course). That's actually good, because otherwise you couldn't learn anything new anymore - what a boring life. If you believe yourself being a Scrum Expert, start filling in the holes. Trying to become an expert in all the fields will keep you busy a lifetime.
One last piece of advice: You can never become a Scrum Expert just by reading books. You have to apply your knowledge to real projects on a daily basis. Get your hands dirty!
knowledge, skill or wisdom gained through practice in some activity, or the doing of somethingWell, at least that is one definition. In contrast to knowledge, which is defined as
the state or fact of knowingSo somebody with experience has actually applied his wisdom. Recently I have come across several people where the gap between knowledge and experience created impediments.
I am sure you are aware of Shuhari. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms".
Well, this is pretty abstract. You could maybe summarize it as "First you obey the rules, then you deviate a bit and finally you no longer think about them, it all feels natural." Personally, I prefer the Dreyfus-model.
Dreyfus Model - Credits: vitorpamplona.com
As you can see in this picture, the Dreyfus model knows five stages of skill acquisition: Novice, Advanced Beginner, Competent, Proficient and Expert. While the Beginner is just able to "follow the rules", the Expert "just does what works". In between, rules first have nuances and become conditional. Once competent, the person learns the rules behind the rules shaping context and conditions. Finally, intuition comes into play.
As far as the skills stretch, the sense of responsibility grows as well. But what does this have to do with Scrum? Well, a lot actually.
You know of course, that your team members will go through all of those stages and that the rest of the team should help each individual to proceed as quickly as sensible. But have you ever thought about yourself? In what stage are you? Don't be too hasty in your decision. Many people have a differing self-perception from other people's views. Especially Scrum Masters, who are usually quite self-confident and need a thick fur to enforce the rules of Scrum tend to consider themselves "Experts" once they start to see the principles behind Scrum. In truth, they are just Advanced Beginners, but they proclaim proudly to have mastered the art of Scrum. It is quite interesting to discuss nuances and the practical application with them (I admit that I like heated discussions). Unfortunately, quite often you quickly reach the point where the Advanced Beginners resort to the "because Scrum says so" argument. That's the minute where the discussions grow stiff and awkward, depending on the individual character.
Nobody can be an expert in all fields. On top of that, Scrum is just a framework with many holes. You need vast additional expertise to fill those professionally. Just think about things like:
- Coding practices
- Requirement elicitation
- Leadership
- Software deployment
- Organizational development
- Process engineering
- Moderation techniques
- Analysis methods
- And many more...
Now, if an Advanced Beginner starts discussing Scrum with experienced managers (who tend to be Competent or Proficient in their area of expertise), those quickly spot the lack of context and depth. Credibility and trust are lost. Sometimes Scrum is blamed for the incompetence afterwards (which usually just helps in political plays or fears for change, but nevertheless is harmful for the company's transition). This is a severe impediment. Without trust, Scrum cannot work.
I strongly recommend to create transparency for yourselves and the people you work with. Clearly state where your skills lie - and where you consider yourself a Novice. Don't rely on your own perception but ask others about their opinions. In each area of expertise, there are only few experts out there. Don't consider yourself one too light-headedly. Help others with less experience to develop themselves - for example by coaching them. Strive to improve yourself at every opportunity as well. Whenever you catch yourself not being able to explain something or resorting to "because ... says so"-answers, investigate further and look at the Dreyfus model again. Accept that there is always a "bigger fish" out there (which means a "better expert" of course). That's actually good, because otherwise you couldn't learn anything new anymore - what a boring life. If you believe yourself being a Scrum Expert, start filling in the holes. Trying to become an expert in all the fields will keep you busy a lifetime.
One last piece of advice: You can never become a Scrum Expert just by reading books. You have to apply your knowledge to real projects on a daily basis. Get your hands dirty!
Tuesday, May 15. 2012
How to prepare for the Professional Scrum assessments
Since there are quite many people asking me about the scrum.org assessments, it's time to shed some light on how to prepare for them. What you find here is my personal experience from completing PSM I, PSM II, PSPO I and PSPO II all with more than 95%.
Before we talk about preparation, you should understand what those exams are all about. Certificates don't have much meaning when it comes to being a good Scrum Master (see this post and that post for more on the topic). However, some companies think there is some value to that paper. Some people feel proud for passing difficult exams.
The Professional Scrum Master (PSM) line of assessments tries to figure out if you understood the basic concepts (PSM I) of Scrum as described in the Scrum Guide and if you have some intermediate knowledge in being a Scrum Master (PSM II). The same is true for the Professional Scrum Product Owner (PSPO) line of assessments, but those focus on the Product Owner of course. More about pricing and how to obtain a key to give those assessments a shot can be found on the scrum.org website.
To prepare for the entry-level exams (PSM I and PSPO I), you should know the Scrumguide very well. You will be asked around 80 questions in 60 minutes, which is plenty of time. The questions are taken from a pool and vary, so don't believe all questions will be the same if you try it several times. This is pretty unnecessary as well: around 80% of my course participants pass this assessments on the first attempt. Due to language and understanding (of Scrum) issues, 20% fail on the first try. Those usually make it on the second one after studying some more.
So here is how you should prepare:
- Read the Scrumguide
- Understand the Scrumguide
- Gather some experience in a real Scrum Team
- Know something about Scrum Best Practices, which are not part of the Scrumguide. This covers burndowns, planning poker, test driven development and more. This is not strictly necessary to pass the test, it's good to know nevertheless.
- Visit a Scrum course, if you like. That's no prerequisite for the assessment but some people find it helpful.
- Try the Scrum Open assessment as often as you like on the Scrum.org website. If you don't achieve skyrocketing scores here, don't go for the real assessment.
To prepare for the intermediate-level exams (PSM II and PSPO II), you should know everything you did for the entry-level exams (They have to be passed before you try the difficult ones. The reason is mainly to make sure you have a basic understanding and don't get completely lost.). Most people fail the 2nd level assessments, so prepare well! You will need to have truely understood Scrum. Reading the Scrumguide alone will not help you here. You will get some multiple-choice questions again (different ones than in the first assessment), but the main part consists of essay questions. If you really nail it down, one or two sentences suffice to answer. Most people go to some length though. Time is tough on the intermediate assessments. Don't count on having time to look anything up (except some English words if your aren't a native speaker).
Here is what you should do to prepare:
- Do everything you did for the first level assessment
- Read every Scrum and leadership book you can lay your hands on. This won't help you directly but can broaden your horizon.
- Make yourself aware of what the job of a Scrum Master / Product Owner is. A PSM / PSPO course can definitely help you there.
- Acquire experience. I am not talking about visiting a Scrum Team for a week, I am talking about walking through the mud with them. Simply be a Scrum Master for a while. Especially difficult situations can help you acquire expertise. I usually recommend people to gather at least three years of experience before doing the 2nd level assessments. It's up to you of course, if you want to do it.
By the way: Trying to google the answers won't take you very far. A hand full can be found on the net, but the majority is not publicly available. They are changed from time to time as well. You will have to use the primary Scrum tool instead: The grey mass between your ears.
One last piece of advice: If you aren't sure about a question take a note during the test (during does not mean afterwards). Go to a local Scrum user group then and ask the folks there to discuss that question with you. This most often gives you some insight if you are on the right road or not.
Is some information missing? Let me know by commenting this blog post.
Good luck!
Monday, April 9. 2012
External developers in Scrum Teams
Today it is quite common to have external "resources" within your teams. I have hardly come across any company which doesn't have at least some specialists on their teams who are not on their regular payroll. While external developers are not a problem in themselves, the way how those are implemented can cause problems. This blog focuses on external collocated developers on the customer's site (so dispersed and distributed teams are excluded).
Here are two examples:
So what was different between those two companies? Apart from the methodologies (who organizes whom, how is productivity measured and so on), there was only one major difference: The first company looked for resources, the second looked for people. They were treated accordingly.
People tend to like being treated as such. There is nothing like "human resources", even though many departments carry that name (It's not "legal resources" or "manufacturing resources" either. So why don't you try something different? "Human affairs" maybe. Or "People Development". Think about it.). Especially in a knowledge worker environment, you cannot easily replace any given person. People have complex relations. While you can tick of their JAVA-skills, you cannot evaluate in advance, how the team will work together. Treat your team with respect and trust so they can prove you right. You will like the results.
Here are two examples:
- The customer bought resources from all over Germany and asked them to work on one single site from Monday to Friday. They were not introduced to the existing teams but rather appeared suddenly. Their skill profile was not compared to the needs of the teams. Nor were the teams asked, if they needed additional manpower. Since the existing team members were surprised by the appearance of new colleagues, they were reluctant to introduce the new guys to their processes and tools. Planning was inaccurate as well - they never knew, what they had to deal with. For a new member to be fully productive, it took about nine months. Most external people stayed between one and one-and-half year with the company. This meant quite high costs. Those were not transparent though: For controlling, the people worked eight hours a day. Nobody cared to measure the benefit for the company. Thought was lacking anyway: On one instance, the company brought in 50 new people within a month and didn't even care if the project could absorb those.
- Another customer found that they lacked certain expertise in one specific area of their business. So they went looking for the right specialists on that topic. They found them half way across the country, concentrated in a single company. Both firms decided to partner and started to work together. Two teams were formed, each consisting of employees of both companies. During the first months, they all worked on the same site (later, they worked distributed). They all tried hard to get to know each other. Sponsored events (usually involving lots of beer and pizza) added their share. The teams were allowed to self-organize all aspects of their work: Team constellation, core working hours, location of work (including traveling to both sites, if necessary) and so on. When a need for additional expertise surfaced, the teams brought that up themselves. New members were productive after three months. The average member stayed three to five years. Velocity soared up and stayed high.
So what was different between those two companies? Apart from the methodologies (who organizes whom, how is productivity measured and so on), there was only one major difference: The first company looked for resources, the second looked for people. They were treated accordingly.
People tend to like being treated as such. There is nothing like "human resources", even though many departments carry that name (It's not "legal resources" or "manufacturing resources" either. So why don't you try something different? "Human affairs" maybe. Or "People Development". Think about it.). Especially in a knowledge worker environment, you cannot easily replace any given person. People have complex relations. While you can tick of their JAVA-skills, you cannot evaluate in advance, how the team will work together. Treat your team with respect and trust so they can prove you right. You will like the results.
Tuesday, January 24. 2012
Pride and the will to win
In well working Scrum Teams one will experience extremely high motivation, very high collaboration and above-average productivity. Where does that come from? If you have worked with such Scrum Teams in the past, you might have asked yourself the very same question. At least I did - and came up with an interesting answer:
People are productive, when they are motivated. People are motivated when they are proud. Pride only develops if people are treated like human beings, not like resources. They must be allowed to manage themselves, but also shown respect for their work. They must be allowed to deliver high quality work. (You might argue now, that "every Team is allowed to deliver, that's what they are paid for!". Let me assure you, that this is not the case. I have worked with Teams who were so bound by technical barriers and mandatory processes, that they could hardly move an inch. Of course, they weren't able to use full Scrum either and therefore didn't get the benefits out of it. We first had to remove the impediments, which took quite a while).
Have a look around you, especially at open source projects: Why do those people put so much effort into something they aren't even paid for? Every single one of them has his/her own specific reason, but they have one thing in common: They want to make a difference and put their ideas to practice. That is something they often are not able to do during their working time. This potential should not be wasted! As a Scrum Master it is your job to find out what motivates each individual Developer in your Team and find a way that those needs are satisfied. Usually that shouldn't be too hard, because people tend to come in a "motivated" state by default. Just remove everything that impedes this intrinsic motivation.
If you succeed here, meaning the Team takes pride in what they do and are highly motivated as well as productive, you get something very important for free: The will to win. If your Team has a strong will to win, they will overcome difficult times by themselves and they will tackle every problem that arises. If this will to win is missing, you find the Team accepting almost everything without argument. If you have ever heard a Developer say that "this takes awfully long, but that's how it is done around here" you know what I am talking about.
The above described concept is valid and essential for the management of a company as well. Only if they have the will to win, they will be able to solve systemic problems of the organisation. Without it, you (as Scrum Master / Scrum Coach) will have to do everything yourself, go on their nerves, push them further and finally leave the company out of frustration (or because they are fed up with your attitude) - which is the point in time when everything falls back into place as it was before you even started. Does your management keep their promises?
Let your people create high quality work which makes them proud and you will get an unstoppable winning Team.
People are productive, when they are motivated. People are motivated when they are proud. Pride only develops if people are treated like human beings, not like resources. They must be allowed to manage themselves, but also shown respect for their work. They must be allowed to deliver high quality work. (You might argue now, that "every Team is allowed to deliver, that's what they are paid for!". Let me assure you, that this is not the case. I have worked with Teams who were so bound by technical barriers and mandatory processes, that they could hardly move an inch. Of course, they weren't able to use full Scrum either and therefore didn't get the benefits out of it. We first had to remove the impediments, which took quite a while).
Have a look around you, especially at open source projects: Why do those people put so much effort into something they aren't even paid for? Every single one of them has his/her own specific reason, but they have one thing in common: They want to make a difference and put their ideas to practice. That is something they often are not able to do during their working time. This potential should not be wasted! As a Scrum Master it is your job to find out what motivates each individual Developer in your Team and find a way that those needs are satisfied. Usually that shouldn't be too hard, because people tend to come in a "motivated" state by default. Just remove everything that impedes this intrinsic motivation.
If you succeed here, meaning the Team takes pride in what they do and are highly motivated as well as productive, you get something very important for free: The will to win. If your Team has a strong will to win, they will overcome difficult times by themselves and they will tackle every problem that arises. If this will to win is missing, you find the Team accepting almost everything without argument. If you have ever heard a Developer say that "this takes awfully long, but that's how it is done around here" you know what I am talking about.
The above described concept is valid and essential for the management of a company as well. Only if they have the will to win, they will be able to solve systemic problems of the organisation. Without it, you (as Scrum Master / Scrum Coach) will have to do everything yourself, go on their nerves, push them further and finally leave the company out of frustration (or because they are fed up with your attitude) - which is the point in time when everything falls back into place as it was before you even started. Does your management keep their promises?
Let your people create high quality work which makes them proud and you will get an unstoppable winning Team.
Sunday, January 15. 2012
How to become a good Scrum Master
This is a translation of my second-most visited German article. Please note, that this is the last translation of one of my German articles for now. If you want to see another one translated, just let me know.
You have read my opinion about certification in my last Blog entry. But what can you do to become a good Scrum Master, if a certificate doesn't really help you? Well, here is my opinion:
You have read my opinion about certification in my last Blog entry. But what can you do to become a good Scrum Master, if a certificate doesn't really help you? Well, here is my opinion:
- Start. Only who is fully grounded in experience can understand why and how Scrum works.
- Learn from your (own) mistakes (inspect and adapt). Everybody who starts doing something will make mistakes. No worries - but learn from them. Reflect yourself regularly. Especially reflect every single item that comes up in the retrospectives. Check if you could have avoided or anticipated it. Also ask yourself, if you had a share in this impediment coming up. As I said: This is not a problem, as long as you learn from it.
- Participate in a training. On the one hand, you can learn from a professional how Scrum works. On the other hand you can meet interesting people and keep in touch with them.
- Exchange your thoughts with other Scrum-users frequently. No matter if you choose UserGroups, Scrum Tabels, a beer with friends or a Community of Practice in your company - go looking for the exchange. If you can't find anything similar to the aforementioned, create something yourself.
- Read much. Even though reading alone does not make you a professional, it broadens your horizon. This gives you some ideas in real situations, which you might not have had without reading. Books, Blogs and forums should be consumed in exactly this priority.
- Improve your skills far beyond Scrum. Management practices, psychologies, moderation, mediation, creativity techniques, sociology and so on are at least as important as the hard Scrum knowledge.
- Use every opportunity to put to practice whatever you have learned. You are planning a private project? Good - why don't you try a Backlog and Iterations on this one? Your girlfriend cannot decide where to go for the holidays? Well, take the role of the PO and write down the relevant criteria. Your private project has ended? How did it go and what can you learn from it for the future? Of course you are allowed to use your skills on projects from your professional live as well.
- Take aid. If your Team is stuck, it needs an expert - so do you. Nobody can be perfect in all areas - this is valid for you as well. Look for somebody who is a professional in the area you are lacking the most skill (Psychology? Process? Organizational development?) and learn as much as possible from this person. Maybe you can solve related problems alone next time.
- Consider that you can strengthen your strengths and weaken your weaknesses. You won't ever become a hero in your weak spots though. Usually it's better to acknowledge your weaknesses and take some aid there, while you develop your strengths to a point where you are a true expert.
Friday, December 30. 2011
What good are certificates?
This is a translation of my most visited German article. Since it seems to spark quite some interest, here is a English version:
I am often asked which Scrum certificate is "the right one" for Scrum users. To cover this topic in depth, I wrote this blog.
I am often asked which Scrum certificate is "the right one" for Scrum users. To cover this topic in depth, I wrote this blog.
- You do not need any certificate to be skillful at any topic. Certificates only very rarely prove skill, but rather state a level of knowledge tested by the certificate at a certain point of time. Only because somebody carries a certificate with him he is not necessarily the right person for the task ahead. Think back to the time when you did the exams for your diploma, your a-levels exam or your driving license: Would you be able to correctly answer all questions, you passed back then? How much did your university degree help you when you finally hit the real world? In my case, I could use around 10% of everything I had learned - the rest taught me the job itself...
- There are three organisations that are known worldwide whose certificates are worth mentioning: PMI, Scrumalliance and Scrum.org
- The PMI-Agile certificate is nearing the end of its pilot phase. I did not do it myself, so I cannot be sure about its quality. However, it is worth noting that a candidate needs 2.000 hours of "General Project Management Experience". In my experience, a good "classical" project manager still has to go a long way to become a good Scrum Master or Product Owner.
- The Scrumalliance certifies that you sat through a course. There is a multiple-choice test at the end of the Certified Scrum Master course, but it is too simple to be taken serious and your score doesn't count towards your certificate. You could even answer everything wrong and still get the certificate. I did the test just for fun and was impressed to see not only the correct answer for each question (after I hit the "Next" button), but to see that Scrumalliance links for further studies to external sources like Scrum.org, Mountain Goat Software, etc. You can only try this exam after you have taken a CSM course.
- You will sweat quite a bit with Scrum.org. The exams are difficult to very difficult and have to be taken online as well. To become a "Professional Scrum Master I", you do not have to visit a course (so far, only the PSM assessments are openly available. For PSD and PSPO you have to take a course). Instead, you can pay 100 $ for every try. 80 multiple-choice questions and one hour of time then stand between you and your PSM I certificate. You have to to right on 85% of the questions to pass. If you want to become a trainer later, you even have to reach 95%. About 80% of the applicants passes the PSM I, the rest fails. If you acquired the PSM I certificate, you are allowed to try the PSM II. This costs 500$ per try (300$ if you have previously visited a PSM course), takes 2 hours of your time and is a mixture of multiple-choice and essay questions. Again, you have to score 85% to pass and 95% to become a trainer. So far, only 106 people worldwide passed that one. Some of them not with their first try. The most difficult part here is to exactly understand what the scrum.org is asking. Sometimes you have to read between the lines. Not so nice is, that you do not get to know which questions you did wrong. This way it's really hard to prepare for this exam (which is a good thing in my opinion). It is not possible to learn questions by hard or answer them beforehand. Those certificates do not have to be renewed every two years, as opposed by those of the PMI and Scrumalliance. So you only have to pay your fees once.
- Who needs which certificate? First, some hints: Whoever wants to obtain a certificate should think hard what he wants to "prove" with it. If he wants to show that he has been to a course, all providers have good options. If you already hold a PMI certificate, you might want to look into the "PMI Agile". If you want to prove professional knowledge (at the point of time when you take the exam), then the Scrum.org is your only alternative so far. It helps that everyone can do the assessment and 100 $ are quite affordable.
- Developers (Coder, Tester, etc.): Usually professional skills are far more important than process knowledge. You should question yourself if you really need a certificate. If you do, look at the Scrumalliance and the Scrum.org, both offer developer courses with certificates. When you go for the Scrum.org you will be presented with a 3-day or 5-day course, depending on your level of knowledge. This one is streamlined, so you will receive the same quality all over the world. Both the scrumalliance and the scrum.org teach you process and developer skills.
- Product Owner: Usually, a Scrum Master course is not the right place for a Product Owner, because his main duty is Return on Invest (ROI), not the Scrum flow. You should go for a Product Owner course instead - with the attached certificates. PMI does not offer this option.
- Scrum Master: If you already are experienced and think you could pass the assessment, go for the Scrum.org. If you want a certificate but do not want to do an exam for it, go for the Scrumalliance. IMHO the PSM II certificate is the only one out there meaning anything. Only the PSM II creates some sort of "unique selling point" for you, if that is what you are looking for.
« previous page
(Page 3 of 6, totaling 55 entries)
next page »