I am sure not everyone can spend much time reading on scrum development so I thought it might be useful to post this list on here. Will make my life easier also whenever I need to use it ;)
To tolerate a problem is to insist on it. ~ Ron Jeffries
A tool is nothing without a skilled artisan to handle it. ~ Tobias
The practices are not the knowing: they are a path to the knowing. ~Ron Jeffries~
No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today. ~Kent Beck~
Anyone who uses the term "resource" when referencing people has to put $1 in the "inappropriate comment" jar! ~ Ken Schwaber
Reality is what we make, not just what we live with. ~Ron Jeffries~
Make it real or else forget about it -- Carlos Santana
Without prioritization, nothing is a priority. ~??
Agility might be said to be about encountering all the problems so early and so often that the effort to fix them is less than the pain of enduring them. ~Ron Jeffries~
"Everything is simple, until you have to do it yourself". ~??
"Once you add people to even the simplest problem, it can get pretty messy in a hurry". ~??
The practices are not the knowing: they are a path to the knowing. ~Ron Jeffries~
Ability to estimate correctly is not an 'ability' ... it is a fluke and lucky guess ~Roy Morien~
A dead scrum master is no good to anyone. ~??
If we're not shipping our software when it's ready, it's poor business practice. If we're not sure whether our software is ready, it's poor software practice. ~Ron Jeffries
Once you start measuring something, you can easily end up in a situation where the measurement itself starts influencing the things you want to measure. – Wolfgang
"A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed." --Ken Schwaber
Don’t worry about the enterprise rollout today when you have not started even one project. ~??
Wednesday, 16 July 2008
Friday, 11 July 2008
Team Dysfunctions and Scrum
I firmly believe and support the idea that Scrum is a management framework and it is not supposed to sort all problems on Earth. I also think I understand well that Scrum was created to solve “a problem” and it duly delivers the goal. This article however is not about how great Scrum is. This article is about a common problem which I believe most if not all Scrum implementations experience. What I am talking about is the problem of overcoming team dysfunctions.
It is known that a Scrum implementation, especially in its early days is expected to and almost always reveals hidden problems and issues that usually cause one or more major team dysfunctions. Finding ways to overcome these dysfunctions is the main goal of this article.
A beautiful beginning
So, you have introduced Scrum and you are working with the first ever Scrum team in your organisation. Luckily all team members seem to be interested and attend all the meetings. You have managed to get a room with whiteboards where the Daily stand-up takes place and you are also able to book an appropriately equipped room for reviews and plannings. Everyone in the organisation seems to be quite excited by the use of index cards and blu-tac which creates an energetic culture and you really feel good about the way things are going.
Retrospectives though feel a bit weird although you can’t quite figure out why. And then suddenly it all kicks-off with an against the rules reaction of a team member during a retrospective meeting after a disastrous review. The team achieved mere 5 points out of 12 planned. Tom, a senior developer says that Chris, a test engineer wouldn’t let the rest of the team do any testing. As a result the team ended up with half of the stories in the final stages of testing just because test engineers would not trust the rest of the team members to provide adequate testing. Surprised by the fact that he is being blamed Chris replies that no one else is qualified to do “proper testing” and anyway testing is not being paid enough attention in Scrum so he believes quality is going down. You finally realise that you need to stop this and you speak about how blaming is not allowed and accent on the positives of identifying a problem which the team now needs to focus on resolving.
The event throws you a little bit out of focus. You see this as a technical issue where testing needs to be automated to reduce the workload of testers. You start reading about test automation and distribute various useful web casts and studies about it. You even change your Scrum training and do it specifically for your test engineers. They seem to understand more and more about cross functional teams and the need of automation. You forget about that retrospective for now.
Although the problem may disappear unfortunately the issue is a lot bigger. Your test engineers do not trust the rest of the team and perhaps vice versa. Lack of trust is usually caused by the unwillingness to be vulnerable. Team members are not open with one another and are afraid to talk about their mistakes and weaknesses. At the same time the fact that your previous retrospectives seemed to be running well suggests that the team might be avoiding conflict. Because of the lack of trust the Team cannot engage in open debates, instead they resort to indirect discussions and shielded comments. Fear of conflict usually only postpones the conflict and once the disappointment reaches certain level the reaction will cause far bigger problem than if the conflict had arisen earlier, or even better resolved in a team debate.
Definitely getting better
Your testers now seemed to have finally got it. At least they no longer question automated testing and seem to be spending time on finding an appropriate tool to use. You still have slight concerns about the way the team reaches quick agreement during planning although you can easily explain this with the team getting more and more used to Scrum. Finally you’re edging close to completing the list of stories in the backlog so you start talking about release. On what seem to certainly be the last planning meeting you start discussing final steps to produce deliverable product which appears to cause a little more discomfort compared to previous meetings. Most unexpectedly Jane, your other test engineer, states out of the blue that she doesn’t care if the team decides that the product is ready for release as she anyway isn’t convinced that enough testing has been done. This sparks Chris’s comment that he wouldn’t accept responsibility for this product as he has never done less testing nor seen a most weird way to develop something. Peter who is a web developer in the team responds that test engineers still do not trust the rest of the team so how can more testing be done when only two team members are testing.
You are disappointed and very concerned that what seemed to be a maturing Scrum team suddenly doesn’t even act as a team. You spend the rest of the day reading about teamwork and various ways to improve it. You are beginning to realise that without sorting out underlying problems it would be difficult to improve practices and productivity.
When a team lacks conflict or what is usually called healthy conflict this could lead to lack of commitment. Because team members cannot air their opinions in an open discussion they rarely if at all commit to decision although they may demonstrate agreement in meetings. Teams members feel as if their opinions do not matter therefore find it difficult to support team decisions. Unfortunately when this is the case it triggers an even bigger problem – avoidance of accountability. Without committing to a well understood plan of action, it doesn’t matter how focused your people are they often fail to call their peers on actions and behaviors that seem counterproductive to the good of the team.
Did you see it coming?
The next morning things seem to become even worse. On the daily scrum Pete, senior developer shows impatience while Chris is talking, interrupts him to make a point about team members not following practices which he believes are a must. Tom also joins in by ignoring the usual order and stating that he feels it became more difficult for him to do “proper” development and increase his expertise. Jane follows to confirm what is obvious to the rest – she doesn’t enjoy working “that way” because she doesn’t see any career progression opportunities with Scrum.
You feel betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have disappeared. The team hasn’t been maturing, it hasn’t even formed. Team members were creating artificial harmony by avoiding conflict and now they feel disengaged and demonstrate no commitment.
If the team fails to hold one another accountable this leads to an environment where the most damaging dysfunction is demonstrated. When team members put their individual needs e.g. career development, recognition, etc. or even the needs of a group of people inside the team above the collective goals of the team this leads to Inattention to results.
You are in an awkward situation because you firmly believe Scrum is not the reason for these problems and yet Scrum exposed the dysfunctions. Everyone will be convinced that pre-Scrum no dysfunctions existed and now your team looks like falling apart. How can you change this? How can you resurrect the team and prove to senior management that Scrum is worth the effort?
Can somebody please explain!
I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like the one we just looked at. While a lot of sources suggest that Scrum Masters should not deal with cases like this I tend to disagree. What if middle management doesn’t want to assist? What if they blame Scrum/You for the problem? What if you don’t want to lose the battle?
Before we get onto it I need to warn you that this is not something that can change overnight. You will need a lot of patience, good coaching and facilitation skills and then even more patience. It will probably be many days if not weeks until you see some change and might take up to 6-9 months until you start feeling optimistic about your team.
Are you vulnerable?
It all starts with trust so it is a good idea to look at establishing trust first. Ask yourself these questions: Are you vulnerable? Do you act like you are? Are you communicating enough to make the team aware that you are ready to make yourself vulnerable? Talk to the team or individually. Do a group exercise where you ask everyone to make themselves vulnerable by sharing details they otherwise would not want to. You will find examples easily but something in the lines of: strong and weak side, biggest challenge in school, etc. will do the trick. You also need to find a way to get the team together outside of normal work environment. This may range from organising a night out for the whole team to off-site event. Do as appropriate depending on your budget. Try to do the same activity at least once a month.
How would you now if you succeeded?
- When you start hearing team members answering honestly “I don’t know”
- Team members happily share information and offer help
Plain talking
Politics is when people choose their words and actions based on how they want others to react rather than on what they really think. Politics is when attention is paid to the speaker’s rank rather than dialogue content. Politics kill progress; therefore you need to stop political behaviour immediately.
Is there a lot of whispering in the team? Can your team members freely express what they think without fearing negative reaction? Start by telling your team to think as if they are two levels higher in the hierarchy. Encourage honest comments regardless of how ruthless they may sound. Print out posters explaining why politics is bad and put them on the walls around your team or if allowed in the whole building. Protect and support your people to speak openly with anyone in the company. Encourage healthy debate by asking open questions like: What other options do we have? What would happen if we go with this solution?
How would you know if you succeeded?
- When whispering is gone
- When you can join a team discussion and the topic doesn’t get changed
Something smells bad?
Agreement is good but be careful how you reach it. If you often feel that the team agrees too easily, if decisions are taken too quickly and meetings go too quietly then perhaps not everything is as good as it looks. Such “easy” decisions are bad for the team because team members will not feel fully involved because they could not voice their opinions due to dysfunctions already discussed above.
The only thing you can do in this case is to be there as facilitator and ask the questions required to spark a healthy debate. Ask about any weakness you see or suggest solutions but be careful – try to be only an advisor. When a debate is going in the wrong direction you should try to bring back the business goal and accent on the responsibility and effort required to achieve a great solution. Avoid digging into too much detail – this is where you will usually lose most of your time.
How would you know if you succeeded?
- When team members can say "I may not agree with your ideas but I understand them and can support them."
A group or a team
According to a popular definition a team is a small group of people with complementary skills and abilities who are committed to a common goal and approach for which they hold each other accountable. Presumably if a group of people doesn’t meet these criteria it remains just a group of people.
Do you often notice team members not particularly interested in team decisions? Have you seen team members only interested in their propositions and not willing to discuss or support others’ solutions? Do you often here “This is not my area. You need to speak to X”? Then perhaps you see what I mean. You need to set team goals and make sure everyone in the team is motivated to meet these goals. Sprint targets are good goals to meet but not always enough. Think about some more. These could be one off events like team games or reoccurring like review process. If you do have or want to start a performance review process make sure you go with the review process for agile teams because other process will make things worse. The review process for agile teams however used with well specified team goals might be just what you need to make sure the team is committed to a common goal and meeting these targets is really important for everyone and for the team.
How would you know if you succeeded?
- When sprint targets met rate increases significantly and anyway you will KNOW it on “that” review meeting
I scored two goals!
A friend was telling me a story about his son. The boy used to play football and once when his father (who actually hates football) picked him up after a game he asked: who won the game? The boy answered: I scored two goals. His father took a deep breath and asked again: Who won the game? Then the boy said: we lost 2:7 but I scored two goals isn’t that the important bit?
Clearly team members interested mainly in their individual goals and not paying attention to team’s results are causing the biggest of all damages. Perhaps this is caused by your organisation’s implementation of traditional performance review process, or just because team members fail to see benefits in achieving the team goal, something that is obvious with achieving their personal goal.
Make sure to explicitly set performance objectives and individual goals which are aligned with the team goals. This may seem a difficult task but there is plenty of information how to do it – you may begin by reading about the review process for agile teams. Note that you may need a lot of support from the senior management and it may seem as a difficult battle however only by winning it you can avoid ambiguous goals and the inattention to results behaviour. Team members will still have goals to work towards but now these goals will not get in the way of team’s targets.
How would you now if you succeeded?
- When team members start using more “we” rather than “I”
The show must go on...
The goal I set at the start of this article was to look at a few common scenarios, identify team dysfunctions and suggest ways to resolve them in Scrum environment. I’d like to believe the goal is mostly achieved. Of course this is only a five page article and you will need to read a lot more than this in order to succeed but my feeling is that since the thoughts I share are from experience you may find them useful. And if you do find this article helpful feel free to get in touch but do also remember that the battle to keep your team functional is one that you will have to keep winning over and over again.
Good thing you’re not alone on the way!
References:
The Five Dysfunctions of a Team -http://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=sr_1_1?ie=UTF8&s=books&qid=1215814459&sr=8-1
Various ideas generated by reading posts on http://groups.yahoo.com/group/scrumdevelopment
It is known that a Scrum implementation, especially in its early days is expected to and almost always reveals hidden problems and issues that usually cause one or more major team dysfunctions. Finding ways to overcome these dysfunctions is the main goal of this article.
A beautiful beginning
So, you have introduced Scrum and you are working with the first ever Scrum team in your organisation. Luckily all team members seem to be interested and attend all the meetings. You have managed to get a room with whiteboards where the Daily stand-up takes place and you are also able to book an appropriately equipped room for reviews and plannings. Everyone in the organisation seems to be quite excited by the use of index cards and blu-tac which creates an energetic culture and you really feel good about the way things are going.
Retrospectives though feel a bit weird although you can’t quite figure out why. And then suddenly it all kicks-off with an against the rules reaction of a team member during a retrospective meeting after a disastrous review. The team achieved mere 5 points out of 12 planned. Tom, a senior developer says that Chris, a test engineer wouldn’t let the rest of the team do any testing. As a result the team ended up with half of the stories in the final stages of testing just because test engineers would not trust the rest of the team members to provide adequate testing. Surprised by the fact that he is being blamed Chris replies that no one else is qualified to do “proper testing” and anyway testing is not being paid enough attention in Scrum so he believes quality is going down. You finally realise that you need to stop this and you speak about how blaming is not allowed and accent on the positives of identifying a problem which the team now needs to focus on resolving.
The event throws you a little bit out of focus. You see this as a technical issue where testing needs to be automated to reduce the workload of testers. You start reading about test automation and distribute various useful web casts and studies about it. You even change your Scrum training and do it specifically for your test engineers. They seem to understand more and more about cross functional teams and the need of automation. You forget about that retrospective for now.
Although the problem may disappear unfortunately the issue is a lot bigger. Your test engineers do not trust the rest of the team and perhaps vice versa. Lack of trust is usually caused by the unwillingness to be vulnerable. Team members are not open with one another and are afraid to talk about their mistakes and weaknesses. At the same time the fact that your previous retrospectives seemed to be running well suggests that the team might be avoiding conflict. Because of the lack of trust the Team cannot engage in open debates, instead they resort to indirect discussions and shielded comments. Fear of conflict usually only postpones the conflict and once the disappointment reaches certain level the reaction will cause far bigger problem than if the conflict had arisen earlier, or even better resolved in a team debate.
Definitely getting better
Your testers now seemed to have finally got it. At least they no longer question automated testing and seem to be spending time on finding an appropriate tool to use. You still have slight concerns about the way the team reaches quick agreement during planning although you can easily explain this with the team getting more and more used to Scrum. Finally you’re edging close to completing the list of stories in the backlog so you start talking about release. On what seem to certainly be the last planning meeting you start discussing final steps to produce deliverable product which appears to cause a little more discomfort compared to previous meetings. Most unexpectedly Jane, your other test engineer, states out of the blue that she doesn’t care if the team decides that the product is ready for release as she anyway isn’t convinced that enough testing has been done. This sparks Chris’s comment that he wouldn’t accept responsibility for this product as he has never done less testing nor seen a most weird way to develop something. Peter who is a web developer in the team responds that test engineers still do not trust the rest of the team so how can more testing be done when only two team members are testing.
You are disappointed and very concerned that what seemed to be a maturing Scrum team suddenly doesn’t even act as a team. You spend the rest of the day reading about teamwork and various ways to improve it. You are beginning to realise that without sorting out underlying problems it would be difficult to improve practices and productivity.
When a team lacks conflict or what is usually called healthy conflict this could lead to lack of commitment. Because team members cannot air their opinions in an open discussion they rarely if at all commit to decision although they may demonstrate agreement in meetings. Teams members feel as if their opinions do not matter therefore find it difficult to support team decisions. Unfortunately when this is the case it triggers an even bigger problem – avoidance of accountability. Without committing to a well understood plan of action, it doesn’t matter how focused your people are they often fail to call their peers on actions and behaviors that seem counterproductive to the good of the team.
Did you see it coming?
The next morning things seem to become even worse. On the daily scrum Pete, senior developer shows impatience while Chris is talking, interrupts him to make a point about team members not following practices which he believes are a must. Tom also joins in by ignoring the usual order and stating that he feels it became more difficult for him to do “proper” development and increase his expertise. Jane follows to confirm what is obvious to the rest – she doesn’t enjoy working “that way” because she doesn’t see any career progression opportunities with Scrum.
You feel betrayed. It seems like the hundreds of hours spent on convincing people and setting up the basics have disappeared. The team hasn’t been maturing, it hasn’t even formed. Team members were creating artificial harmony by avoiding conflict and now they feel disengaged and demonstrate no commitment.
If the team fails to hold one another accountable this leads to an environment where the most damaging dysfunction is demonstrated. When team members put their individual needs e.g. career development, recognition, etc. or even the needs of a group of people inside the team above the collective goals of the team this leads to Inattention to results.
You are in an awkward situation because you firmly believe Scrum is not the reason for these problems and yet Scrum exposed the dysfunctions. Everyone will be convinced that pre-Scrum no dysfunctions existed and now your team looks like falling apart. How can you change this? How can you resurrect the team and prove to senior management that Scrum is worth the effort?
Can somebody please explain!
I am convinced there is no easy answer to these questions; however I also believe that by following a few simple rules a lot can be done to save a dysfunctional team like the one we just looked at. While a lot of sources suggest that Scrum Masters should not deal with cases like this I tend to disagree. What if middle management doesn’t want to assist? What if they blame Scrum/You for the problem? What if you don’t want to lose the battle?
Before we get onto it I need to warn you that this is not something that can change overnight. You will need a lot of patience, good coaching and facilitation skills and then even more patience. It will probably be many days if not weeks until you see some change and might take up to 6-9 months until you start feeling optimistic about your team.
Are you vulnerable?
It all starts with trust so it is a good idea to look at establishing trust first. Ask yourself these questions: Are you vulnerable? Do you act like you are? Are you communicating enough to make the team aware that you are ready to make yourself vulnerable? Talk to the team or individually. Do a group exercise where you ask everyone to make themselves vulnerable by sharing details they otherwise would not want to. You will find examples easily but something in the lines of: strong and weak side, biggest challenge in school, etc. will do the trick. You also need to find a way to get the team together outside of normal work environment. This may range from organising a night out for the whole team to off-site event. Do as appropriate depending on your budget. Try to do the same activity at least once a month.
How would you now if you succeeded?
- When you start hearing team members answering honestly “I don’t know”
- Team members happily share information and offer help
Plain talking
Politics is when people choose their words and actions based on how they want others to react rather than on what they really think. Politics is when attention is paid to the speaker’s rank rather than dialogue content. Politics kill progress; therefore you need to stop political behaviour immediately.
Is there a lot of whispering in the team? Can your team members freely express what they think without fearing negative reaction? Start by telling your team to think as if they are two levels higher in the hierarchy. Encourage honest comments regardless of how ruthless they may sound. Print out posters explaining why politics is bad and put them on the walls around your team or if allowed in the whole building. Protect and support your people to speak openly with anyone in the company. Encourage healthy debate by asking open questions like: What other options do we have? What would happen if we go with this solution?
How would you know if you succeeded?
- When whispering is gone
- When you can join a team discussion and the topic doesn’t get changed
Something smells bad?
Agreement is good but be careful how you reach it. If you often feel that the team agrees too easily, if decisions are taken too quickly and meetings go too quietly then perhaps not everything is as good as it looks. Such “easy” decisions are bad for the team because team members will not feel fully involved because they could not voice their opinions due to dysfunctions already discussed above.
The only thing you can do in this case is to be there as facilitator and ask the questions required to spark a healthy debate. Ask about any weakness you see or suggest solutions but be careful – try to be only an advisor. When a debate is going in the wrong direction you should try to bring back the business goal and accent on the responsibility and effort required to achieve a great solution. Avoid digging into too much detail – this is where you will usually lose most of your time.
How would you know if you succeeded?
- When team members can say "I may not agree with your ideas but I understand them and can support them."
A group or a team
According to a popular definition a team is a small group of people with complementary skills and abilities who are committed to a common goal and approach for which they hold each other accountable. Presumably if a group of people doesn’t meet these criteria it remains just a group of people.
Do you often notice team members not particularly interested in team decisions? Have you seen team members only interested in their propositions and not willing to discuss or support others’ solutions? Do you often here “This is not my area. You need to speak to X”? Then perhaps you see what I mean. You need to set team goals and make sure everyone in the team is motivated to meet these goals. Sprint targets are good goals to meet but not always enough. Think about some more. These could be one off events like team games or reoccurring like review process. If you do have or want to start a performance review process make sure you go with the review process for agile teams because other process will make things worse. The review process for agile teams however used with well specified team goals might be just what you need to make sure the team is committed to a common goal and meeting these targets is really important for everyone and for the team.
How would you know if you succeeded?
- When sprint targets met rate increases significantly and anyway you will KNOW it on “that” review meeting
I scored two goals!
A friend was telling me a story about his son. The boy used to play football and once when his father (who actually hates football) picked him up after a game he asked: who won the game? The boy answered: I scored two goals. His father took a deep breath and asked again: Who won the game? Then the boy said: we lost 2:7 but I scored two goals isn’t that the important bit?
Clearly team members interested mainly in their individual goals and not paying attention to team’s results are causing the biggest of all damages. Perhaps this is caused by your organisation’s implementation of traditional performance review process, or just because team members fail to see benefits in achieving the team goal, something that is obvious with achieving their personal goal.
Make sure to explicitly set performance objectives and individual goals which are aligned with the team goals. This may seem a difficult task but there is plenty of information how to do it – you may begin by reading about the review process for agile teams. Note that you may need a lot of support from the senior management and it may seem as a difficult battle however only by winning it you can avoid ambiguous goals and the inattention to results behaviour. Team members will still have goals to work towards but now these goals will not get in the way of team’s targets.
How would you now if you succeeded?
- When team members start using more “we” rather than “I”
The show must go on...
The goal I set at the start of this article was to look at a few common scenarios, identify team dysfunctions and suggest ways to resolve them in Scrum environment. I’d like to believe the goal is mostly achieved. Of course this is only a five page article and you will need to read a lot more than this in order to succeed but my feeling is that since the thoughts I share are from experience you may find them useful. And if you do find this article helpful feel free to get in touch but do also remember that the battle to keep your team functional is one that you will have to keep winning over and over again.
Good thing you’re not alone on the way!
References:
The Five Dysfunctions of a Team -http://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=sr_1_1?ie=UTF8&s=books&qid=1215814459&sr=8-1
Various ideas generated by reading posts on http://groups.yahoo.com/group/scrumdevelopment
Subscribe to:
Posts (Atom)