[Scrum] Why are we individually competent but collectively incompetent?
25 views
Skip to first unread message
Michael de la Maza
Apr 26, 2010, 8:22:41 PM4/26/10
to Scrum Alliance - transforming the world of work.
In companies I work with I usually find significant disagreements
among people. But when I speak to each person involved, each one
seems remarkably competent and reasonable. How can a collection of
people, all of whom are individually capable and caring, form a team
which is incompetent and uncaring?
Here are some of the issues that I believe cause team-level problems:
- People are afraid to open about uncomfortable truths. During
meetings they nod in agreement but, in private, they fume.
- Companies do not make time to resolve meta-level issues. They
expect and demand that everyone will be working on the next release
all of the time.
- People lack certain key skills, especially the ability disagree in a
non-confrontational and non-harmful manner.
More generally, the root of the matter is that empathizing with others
is extraordinarily difficult. A very wise friend of mine once told
me, "For a marriage to be successful each person needs to think that
they are doing 80% of the work." Assuming that both of the people in
the marriage are good people, why would this be the case?
Perhaps it’s this: We all know exactly what we are doing at all times,
but we only have the vaguest understanding of what someone else, even
a marriage partner, is doing. Hence, we give ourselves credit for all
of the good things we do, but give others only partial credit for all
of their good deeds. We do this not because we are unkind or evil,
but because we simply do not know.
One of the marvels of Scrum is that it radically increases empathy by
greatly increasing how much team members know and understand about
each other. It does so in ways that are often not widely understood.
Take the notion of generalizing specialists. This concept is often
justified by arguing that having more people who can work on the
highest priority item allows the team to create more business value.
While this is certainly true, another great advantage of generalizing
specialists is that they know how difficult are the problems in
domains outside of their own. So, when a team member is stuck, they
empathize. When another team member solves a particularly difficult
problem, they can be appreciative.
The best way I know to increase empathy quickly is to engage in
certain structured activities with other team members. The Empowering
Teams with Agile Games conference, which will be held on May 15th and
16th, is a great way to learn about agile games from people like Lyssa
Adkins, Tobias Mayer, Michael McCullough, and Don McGreal. The web
site for the conference is: http://bit.ly/9KneVl
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
among people. But when I speak to each person involved, each one
seems remarkably competent and reasonable. How can a collection of
people, all of whom are individually capable and caring, form a team
which is incompetent and uncaring?
Here are some of the issues that I believe cause team-level problems:
- People are afraid to open about uncomfortable truths. During
meetings they nod in agreement but, in private, they fume.
- Companies do not make time to resolve meta-level issues. They
expect and demand that everyone will be working on the next release
all of the time.
- People lack certain key skills, especially the ability disagree in a
non-confrontational and non-harmful manner.
More generally, the root of the matter is that empathizing with others
is extraordinarily difficult. A very wise friend of mine once told
me, "For a marriage to be successful each person needs to think that
they are doing 80% of the work." Assuming that both of the people in
the marriage are good people, why would this be the case?
Perhaps it’s this: We all know exactly what we are doing at all times,
but we only have the vaguest understanding of what someone else, even
a marriage partner, is doing. Hence, we give ourselves credit for all
of the good things we do, but give others only partial credit for all
of their good deeds. We do this not because we are unkind or evil,
but because we simply do not know.
One of the marvels of Scrum is that it radically increases empathy by
greatly increasing how much team members know and understand about
each other. It does so in ways that are often not widely understood.
Take the notion of generalizing specialists. This concept is often
justified by arguing that having more people who can work on the
highest priority item allows the team to create more business value.
While this is certainly true, another great advantage of generalizing
specialists is that they know how difficult are the problems in
domains outside of their own. So, when a team member is stuck, they
empathize. When another team member solves a particularly difficult
problem, they can be appreciative.
The best way I know to increase empathy quickly is to engage in
certain structured activities with other team members. The Empowering
Teams with Agile Games conference, which will be held on May 15th and
16th, is a great way to learn about agile games from people like Lyssa
Adkins, Tobias Mayer, Michael McCullough, and Don McGreal. The web
site for the conference is: http://bit.ly/9KneVl
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
nela
Apr 27, 2010, 4:06:33 PM4/27/10
to Scrum Alliance - transforming the world of work.
I am coming to the same conclusion - a group of very competent people
comes out as an incompetent group. Why...
member said to another "you must let the others know what you are
doing, as I am certainly not aware at all what you are doing and what
you have done". The answer came "just look in the CVS and you will
see". But the answer was not satisfactory to the other party. So, I
broke up the argument, and asked them all to remember what they
promised to each other on our previous Retrospective: Inform the whole
team of one section of work finished, by sending a mail to the whole
group.
> - People lack certain key skills, especially the ability disagree in a
> non-confrontational and non-harmful manner.
I agree !! Definitely !
> The best way I know to increase empathy quickly is to engage in
> certain structured activities with other team members.
Our boss is sending the team (excluding me the SM, and the PO, just
the team) for a team building trip. I hope that the team building
coach will have an idea about these structured activities... ...
The team is still not working as a team properly. We are on our 4th
sprint (2 weeks each) and we have shown very little. And had a lot of
arguments. Why are people behaving like that? No idea. They are all
very good at their job, and yet they spend most of their time trying
to show they are better then the person next to them. That takes the
concentration away, certainly, from a Sprint Goal that was planned. I
have to keep reminding them every day - asking them the fourth
question - you explained in detail your individual tasks, but how far
are you from achieving the team plan ?? And I get no particular
answer, just shrugging of shoulders.
By the way, Sprint No.1 was a failure, Sprint No. 2 was a success,
Sprint No. 3 was a failure. Now... it is Sprint No. 4 with a Review
next tuesday... We shall see.
Kind regards,
Nela.
On Apr 27, 2:22 am, Michael de la Maza <michael.delam...@gmail.com>
wrote:
comes out as an incompetent group. Why...
> We all know exactly what we are doing at all times,
> but we only have the vaguest understanding of what someone else, even
> a marriage partner, is doing.
That is one big issue, and came up today on my daily scrum. One team
> but we only have the vaguest understanding of what someone else, even
> a marriage partner, is doing.
member said to another "you must let the others know what you are
doing, as I am certainly not aware at all what you are doing and what
you have done". The answer came "just look in the CVS and you will
see". But the answer was not satisfactory to the other party. So, I
broke up the argument, and asked them all to remember what they
promised to each other on our previous Retrospective: Inform the whole
team of one section of work finished, by sending a mail to the whole
group.
> - People lack certain key skills, especially the ability disagree in a
> non-confrontational and non-harmful manner.
> The best way I know to increase empathy quickly is to engage in
> certain structured activities with other team members.
the team) for a team building trip. I hope that the team building
coach will have an idea about these structured activities... ...
The team is still not working as a team properly. We are on our 4th
sprint (2 weeks each) and we have shown very little. And had a lot of
arguments. Why are people behaving like that? No idea. They are all
very good at their job, and yet they spend most of their time trying
to show they are better then the person next to them. That takes the
concentration away, certainly, from a Sprint Goal that was planned. I
have to keep reminding them every day - asking them the fourth
question - you explained in detail your individual tasks, but how far
are you from achieving the team plan ?? And I get no particular
answer, just shrugging of shoulders.
By the way, Sprint No.1 was a failure, Sprint No. 2 was a success,
Sprint No. 3 was a failure. Now... it is Sprint No. 4 with a Review
next tuesday... We shall see.
Kind regards,
Nela.
On Apr 27, 2:22 am, Michael de la Maza <michael.delam...@gmail.com>
wrote:
John Clifford
Apr 27, 2010, 4:28:28 PM4/27/10
to Scrum Alliance - transforming the world of work.
On Apr 27, 1:06 pm, nela <nela.soldatovjo...@gmail.com> wrote:
> The team is still not working as a team properly. We are on our 4th
> sprint (2 weeks each) and we have shown very little. And had a lot of
> arguments. Why are people behaving like that? No idea.
discover what the real issues are, especially if you use something
like the 5 Whys.
> By the way, Sprint No.1 was a failure, Sprint No. 2 was a success,
> Sprint No. 3 was a failure. Now... it is Sprint No. 4 with a Review
> next tuesday... We shall see.
What did you change after each sprint, to incorporate the lessons you
learned from that sprint so that you wouldn't make the same mistakes
again?
Jan Beaver
Apr 27, 2010, 5:00:54 PM4/27/10
to scruma...@googlegroups.com
Hi Nela,
The description of your team seems to place them on the boundary between Forming and Storming in the model of team development described by Bruce Tuckman (http://en.wikipedia.org/wiki/Forming,_storming,_norming_and_performing). Patience and steady guidance are usually the key elements a ScrumMaster needs to apply at this point. Stay engaged with your team and learn all you can about team dynamics and mediating interpersonal relations.
I hope the team retreat helps!
Cheers,
Jan Beaver, CSP
The description of your team seems to place them on the boundary between Forming and Storming in the model of team development described by Bruce Tuckman (http://en.wikipedia.org/wiki/Forming,_storming,_norming_and_performing). Patience and steady guidance are usually the key elements a ScrumMaster needs to apply at this point. Stay engaged with your team and learn all you can about team dynamics and mediating interpersonal relations.
I hope the team retreat helps!
Cheers,
Jan Beaver, CSP
John Clifford
Apr 27, 2010, 11:53:04 PM4/27/10
to Scrum Alliance - transforming the world of work.
Michael, I believe it's because the practices that work for
individuals don't scale... and this is something that is not obvious
to most people. As a result, everyone is trying to do what worked for
them individually, causing conflict with others, and no one is willing
to abandon the familiar.
Empathy is part of the solution, but it's a mean to an end. The end
being 'what people are actually in disagreement about.' Empathy makes
the team drop much of their defensiveness so that the real problems
can be discussed.
individuals don't scale... and this is something that is not obvious
to most people. As a result, everyone is trying to do what worked for
them individually, causing conflict with others, and no one is willing
to abandon the familiar.
Empathy is part of the solution, but it's a mean to an end. The end
being 'what people are actually in disagreement about.' Empathy makes
the team drop much of their defensiveness so that the real problems
can be discussed.
Scott Dunn
Apr 28, 2010, 12:40:58 PM4/28/10
to Scrum Alliance - transforming the world of work.
One thing I've seen help team members find their place is to have them
take the StrengthsFinder assessment and review the results as a team.
It is a nice, objective way to show that the each have their own
unique strengths, making their identity and contribution to the team
more clear and stronger. Other assessments work towards the same end,
just not as powerful, IMO. There is a free version of a pseudo Myers-
Briggs online. Also, depending on your strengths, you might be able to
note where people are contributing in unique ways (their own) and
affirm that (praise in public, correct in private), especially the
ones who seem insecure.
Another tool I've heard helps is the team-building approach described
in Artful Making, but I haven't gone through that book.
When I've seen the problems you described as "yet they spend most of
their time trying to show they are better then the person next to
them," it's a value and identity issue, if not security (going back to
Maslov's hierarchy of needs). Address those and it will help for them
to put down their guard, connect with and even affirm/support each
other. Everyone is looking for belonging, affirmation and purpose, and
it's harder for people to give to others until those needs are
addressed.
You are insightful for seeing the issues for what they are. Nice job.
Most of the time, for me, the real (hard) issues are people issues.
Regards,
Scott
Scott Dunn, Agile Coach
Certified Scrum Practitioner, Certified ScrumMaster, PMP, Pragmatic
Marketing Certified
Software Development and Human Capital - Agile, Leadership and
Strengths
> > You received this message because you are subscribed to theGoogleGroups "Scrum Alliance - transforming the world of work." group.
nela
Apr 28, 2010, 3:10:59 PM4/28/10
to Scrum Alliance - transforming the world of work.
Hi guys, thanks for your input !!
To John: "What are they arguing about? Perhaps looking at this may
retrospective or any other impromptu meeting, to discuss the problems
they have. They are all aware they are going nowhere fast, but they do
not seem to be ready to talk about it. Like pushing a stone uphill,
when you ask them to talk about it. What are they arguing about - I
can only give you a direct example:
5 members total, one of them is not working on this Sprint No.4
because of other priorities. So, we have 4. One of them is a girl
developer, one of them an architect who would like to develop also,
one of them is a self-learner developer, and the other one is new kid
on the block, in the company only one year, straight from school as
software architect.
Today at the daily scrum the argument was about Java versions. The
girl is the only one doing the actual developing currently, the others
are just "watching what she does" as they do not know the newest JSF
or whatever. She currently states she has a problem with a company
template, as the template is made with a previous version of JSF, and
we decided in this project to use the newest version. So nobody yet
uses it. The others keep asking her what exactly it is the problem,
but when she explains they do not really understand, and they say they
don't understand. I stopped the discussion by suggesting they should
all meet after lunch (daily scrum is just before lunch) and discuss
the problem.
During lunch, she told me that the guys can't really help because they
did not even try to develop anything with this new technology, so they
should try first, then they would know what she is talking about. In
the meantime she is searching the internet and books, for answer. The
department that did the template is not really interested - they told
her that "you all decided in the project to use technology that is too
new, not tried and tested within the company". I would not necessarily
agree with that, if it was up to me - I would tell them to spend a few
days or a week to create a new template which departments can use to
create web applications, in the new version. But - as usual, they have
other priorities.
The self-learner developer stated he will try to develop a web page
with this new jsf, and he will have a better idea then.
The others picked some tasks which I am not sure what they are, but it
seems to be something with Junit testing, automated testing, etc.
I tried to get them to concentrate on the user stories not finished,
the sprint plan they committed, work towards the goal. But it did not
seem to create a lot of response. Even the PO was there to remind them
that the 4 user stories they committed to, go exactly in that order,
as they are on the board. They cannot do the last one first.
In my opinion, the problem with every Sprint Plan is that they cannot
envisage the coming problems, as they do not know the technology. And
the girl is always the one finding out the problems, as she seems to
have the willpower to tackle the new technology and get on with it.
But when she states what problems she is coming against, what seems to
happen is - the guys just want to help her, protect her, or whatever.
And yet, they cannot, because they did not even try to see what is it
all about. But they are quick to say - I can help you. She does not
need help, she needs them to start getting involved. She spent an hour
in the afternoon explaining to two of them what is wrong, but I am not
sure it will help.
To Scott:
seem to be a group of people put together by force, all of them
constantly trying to prove how good they are as individuals, and how
much they know. They are not willing to tackle the problem and grab it
by its neck.
And the retrospectives have shown that they are not really willing to
discuss and decide on how to get better. Because they think they are
perfect, and it is not their fault if the technology or some other
issue is stopping their progress. They seem to want everything to get
magically solved over night, and then they can get on with the work.
Regards to you all, and keep sending me your ideas,
thanks again,
Nela.
To John: "What are they arguing about? Perhaps looking at this may
help to discover what the real issues are"
The main problem with my team is that they are not open to use the
retrospective or any other impromptu meeting, to discuss the problems
they have. They are all aware they are going nowhere fast, but they do
not seem to be ready to talk about it. Like pushing a stone uphill,
when you ask them to talk about it. What are they arguing about - I
can only give you a direct example:
5 members total, one of them is not working on this Sprint No.4
because of other priorities. So, we have 4. One of them is a girl
developer, one of them an architect who would like to develop also,
one of them is a self-learner developer, and the other one is new kid
on the block, in the company only one year, straight from school as
software architect.
Today at the daily scrum the argument was about Java versions. The
girl is the only one doing the actual developing currently, the others
are just "watching what she does" as they do not know the newest JSF
or whatever. She currently states she has a problem with a company
template, as the template is made with a previous version of JSF, and
we decided in this project to use the newest version. So nobody yet
uses it. The others keep asking her what exactly it is the problem,
but when she explains they do not really understand, and they say they
don't understand. I stopped the discussion by suggesting they should
all meet after lunch (daily scrum is just before lunch) and discuss
the problem.
During lunch, she told me that the guys can't really help because they
did not even try to develop anything with this new technology, so they
should try first, then they would know what she is talking about. In
the meantime she is searching the internet and books, for answer. The
department that did the template is not really interested - they told
her that "you all decided in the project to use technology that is too
new, not tried and tested within the company". I would not necessarily
agree with that, if it was up to me - I would tell them to spend a few
days or a week to create a new template which departments can use to
create web applications, in the new version. But - as usual, they have
other priorities.
The self-learner developer stated he will try to develop a web page
with this new jsf, and he will have a better idea then.
The others picked some tasks which I am not sure what they are, but it
seems to be something with Junit testing, automated testing, etc.
I tried to get them to concentrate on the user stories not finished,
the sprint plan they committed, work towards the goal. But it did not
seem to create a lot of response. Even the PO was there to remind them
that the 4 user stories they committed to, go exactly in that order,
as they are on the board. They cannot do the last one first.
In my opinion, the problem with every Sprint Plan is that they cannot
envisage the coming problems, as they do not know the technology. And
the girl is always the one finding out the problems, as she seems to
have the willpower to tackle the new technology and get on with it.
But when she states what problems she is coming against, what seems to
happen is - the guys just want to help her, protect her, or whatever.
And yet, they cannot, because they did not even try to see what is it
all about. But they are quick to say - I can help you. She does not
need help, she needs them to start getting involved. She spent an hour
in the afternoon explaining to two of them what is wrong, but I am not
sure it will help.
To Scott:
"One thing I've seen help team members find their place is to have
them take the StrengthsFinder assessment and review the results as a
team. "
It would be nice, but my team does not seem to be interested. They
them take the StrengthsFinder assessment and review the results as a
team. "
seem to be a group of people put together by force, all of them
constantly trying to prove how good they are as individuals, and how
much they know. They are not willing to tackle the problem and grab it
by its neck.
And the retrospectives have shown that they are not really willing to
discuss and decide on how to get better. Because they think they are
perfect, and it is not their fault if the technology or some other
issue is stopping their progress. They seem to want everything to get
magically solved over night, and then they can get on with the work.
Regards to you all, and keep sending me your ideas,
thanks again,
Nela.
nela
Apr 28, 2010, 3:36:58 PM4/28/10
to Scrum Alliance - transforming the world of work.
To come back to the original message from Michael de la Maza:
"How can a collection of people, all of whom are individually capable
and caring, form a team
which is incompetent and uncaring? "
They can form such a team, because the real person comes out of them.
They seemed a caring person, but put them in a position to care about
somebody they did not choose - and they show that they are not caring
at all.
So, the seemingly caring person is only caring to the people he or she
chooses.
"How can a collection of people, all of whom are individually capable
and caring, form a team
which is incompetent and uncaring? "
They seemed a caring person, but put them in a position to care about
somebody they did not choose - and they show that they are not caring
at all.
So, the seemingly caring person is only caring to the people he or she
chooses.
Ron Jeffries
Apr 28, 2010, 4:12:28 PM4/28/10
to scruma...@googlegroups.com
Hello, nela. On Wednesday, April 28, 2010, at 3:36:58 PM, you
wrote:
> They can form such a team, because the real person comes out of them.
> They seemed a caring person, but put them in a position to care about
> somebody they did not choose - and they show that they are not caring
> at all.
So your best guess is that we're facing a team ALL OF WHOM do not
really care?
Seems very unlikely to me ...
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Some things are impossible. And some things people say are
impossible -- because they don't know how to do them. -- Ron Loyd
wrote:
> They can form such a team, because the real person comes out of them.
> They seemed a caring person, but put them in a position to care about
> somebody they did not choose - and they show that they are not caring
> at all.
really care?
Seems very unlikely to me ...
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Some things are impossible. And some things people say are
impossible -- because they don't know how to do them. -- Ron Loyd
Ilja Preuß
Apr 29, 2010, 3:07:13 AM4/29/10
to scruma...@googlegroups.com
How is the retrospective facilitated? Are you trying to immediately
identify and resolve problems, or are you taking your time to first
get a common picture of what happened, "getting the stories out"?
Doing the latter has a significant effect on team building.
Curious, Ilja
2010/4/28 nela <nela.sold...@gmail.com>:
identify and resolve problems, or are you taking your time to first
get a common picture of what happened, "getting the stories out"?
Doing the latter has a significant effect on team building.
Curious, Ilja
2010/4/28 nela <nela.sold...@gmail.com>:
Onkar Timalapur
Apr 29, 2010, 3:16:13 AM4/29/10
to scruma...@googlegroups.com
Hi Nela,
I think if they are not willing to care/help other people, I have an solution I am not sure it suites your organization.
Make this as one of their yearly Objective/Goal, which will be considered at the time of appraisal, you can give some weigt to this but you can't force the team, but give some fair points whovever does that.
Thanks and Regards
Onkar Bangalore
> Date: Wed, 28 Apr 2010 12:36:58 -0700
> Subject: [Scrum] Re: Why are we individually competent but collectively incompetent?
> From: nela.sold...@gmail.com
> To: scruma...@googlegroups.com
I think if they are not willing to care/help other people, I have an solution I am not sure it suites your organization.
Make this as one of their yearly Objective/Goal, which will be considered at the time of appraisal, you can give some weigt to this but you can't force the team, but give some fair points whovever does that.
Thanks and Regards
Onkar Bangalore
> Date: Wed, 28 Apr 2010 12:36:58 -0700
> Subject: [Scrum] Re: Why are we individually competent but collectively incompetent?
> From: nela.sold...@gmail.com
> To: scruma...@googlegroups.com
Invest your money wisely post Budget Sign up now.
Jens Meydam
Apr 29, 2010, 3:29:28 PM4/29/10
to Scrum Alliance - transforming the world of work.
Hi Nela,
I am blissfully unaware of all the political issues you must deal with
at your company.
Let's pretend for a moment there really weren't any, and you as the
ScrumMaster of the team were free to do the sensible thing. (As they
say, Scrum is all about common sense.)
> They are all aware they are going nowhere fast, but they do
> not seem to be ready to talk about it.
How about aborting the Sprint? Let's face it, they don't have a
chance to succeed.
There are serious issues, and you may use a drastic measure such as
aborting the Sprint as a means to communicate to the team and to the
people above you (at least those who care) that some serious
intervention is necessary to save the project.
> 5 members total, one of them is not working on this Sprint No.4
> because of other priorities. So, we have 4. One of them is a girl
> developer, one of them an architect who would like to develop also,
> one of them is a self-learner developer, and the other one is new kid
> on the block, in the company only one year, straight from school as
> software architect.
You as the ScrumMaster have a say (or should have a say) on who is on
your team. Alistair Cockburn recommends to have at least one
experienced developer on the team who can handle the technology and
has a good understanding of the requirements (and this recommendation
is based on empirical research, by the way.)
> Today at the daily scrum the argument was about Java versions. The
> girl is the only one doing the actual developing currently, the others
> are just "watching what she does" as they do not know the newest JSF
> or whatever. She currently states she has a problem with a company
> template, as the template is made with a previous version of JSF, and
> we decided in this project to use the newest version. So nobody yet
> uses it.
> [...] The department that did the template is not really interested - they told
that actually works?
> The self-learner developer stated he will try to develop a web page
> with this new jsf, and he will have a better idea then.
How about finding somebody who can coach them? If they can't do
anything because they don't know the technology, that's an impediment,
and it's your job to remove it.
> But when she states what problems she is coming against, what seems to
> happen is - the guys just want to help her, protect her, or whatever.
> And yet, they cannot, because they did not even try to see what is it
> all about.
How about having more of those girls and fewer of those guys on the
team? :-)
Jens
I am blissfully unaware of all the political issues you must deal with
at your company.
Let's pretend for a moment there really weren't any, and you as the
ScrumMaster of the team were free to do the sensible thing. (As they
say, Scrum is all about common sense.)
> They are all aware they are going nowhere fast, but they do
> not seem to be ready to talk about it.
chance to succeed.
There are serious issues, and you may use a drastic measure such as
aborting the Sprint as a means to communicate to the team and to the
people above you (at least those who care) that some serious
intervention is necessary to save the project.
> 5 members total, one of them is not working on this Sprint No.4
> because of other priorities. So, we have 4. One of them is a girl
> developer, one of them an architect who would like to develop also,
> one of them is a self-learner developer, and the other one is new kid
> on the block, in the company only one year, straight from school as
> software architect.
your team. Alistair Cockburn recommends to have at least one
experienced developer on the team who can handle the technology and
has a good understanding of the requirements (and this recommendation
is based on empirical research, by the way.)
> Today at the daily scrum the argument was about Java versions. The
> girl is the only one doing the actual developing currently, the others
> are just "watching what she does" as they do not know the newest JSF
> or whatever. She currently states she has a problem with a company
> template, as the template is made with a previous version of JSF, and
> we decided in this project to use the newest version. So nobody yet
> uses it.
> her that "you all decided in the project to use technology that is too
> new, not tried and tested within the company".
Why don't you just change your mind and use a technology (version)
> new, not tried and tested within the company".
that actually works?
> The self-learner developer stated he will try to develop a web page
> with this new jsf, and he will have a better idea then.
anything because they don't know the technology, that's an impediment,
and it's your job to remove it.
> But when she states what problems she is coming against, what seems to
> happen is - the guys just want to help her, protect her, or whatever.
> And yet, they cannot, because they did not even try to see what is it
> all about.
team? :-)
Jens
nela
Apr 29, 2010, 4:14:20 PM4/29/10
to Scrum Alliance - transforming the world of work.
Hi again guys ! Just reading your fascinating comments... you are
giving me a lot of good input.
To Ron:
only one that seems remotely interested to deliver something at the
end of the sprint is the girl.
To Ilja:
and I decided to run the third one myself. He told me he would have
run it differently and I told him - every person runs things
differently, it doesn't mean it is wrong. He agreed. However, the
result is the same.
What I did is, I put on the board the results of the previous
agreements on a previous retrospective, asked the team how the
decisions went through the sprint, did they do what they decided?
Then, I started an open discussion what do they think they did bad in
this failed sprint. And few things came out, I stuck them on the
board, and at the end I got them to make a conclusion - what are they
going to do better. However, the decisions were on the board only. All
was forgotten the very next day... Even when I reminded them - this
was your decision in your retrospective - they struggled to get out of
it.
To Onkar:
goals set are appraised a year later and people get a bonus based on
it. Hmm, it just may work.
To Jens:
at least let them survive the planned team-building trip... (Also, for
selfish reasons, I would like my first SM job to show a success to all
these waterfall people around me.)
applications in JSF, and they are using an older version. We have a
very good understanding of the requirements, but no experience. I must
add here, that the whole team attended a full 2 day course on Java JSF
newest technology. Maybe they need a brush-up, after a little bit of
experience?? (at least the girl has...)
I promise you I will not give up. I will keep them going and help them
the best I can. My next step will be to suggest to my boss, that we
need another JSF training for the whole team. This company loves to
pay for training. So all I need to do is organise it. Now the team
should have real questions to ask.
Thanks a lot, really !
Kind regards,
Nela.
giving me a lot of good input.
To Ron:
"So your best guess is that we're facing a team ALL OF WHOM do not
really care? "
I am saying they seem to not care. Maybe deep inside they do. But the
really care? "
only one that seems remotely interested to deliver something at the
end of the sprint is the girl.
To Ilja:
"How is the retrospective facilitated?"
As my coach is present on each retrospective, he ran the first two,
and I decided to run the third one myself. He told me he would have
run it differently and I told him - every person runs things
differently, it doesn't mean it is wrong. He agreed. However, the
result is the same.
What I did is, I put on the board the results of the previous
agreements on a previous retrospective, asked the team how the
decisions went through the sprint, did they do what they decided?
Then, I started an open discussion what do they think they did bad in
this failed sprint. And few things came out, I stuck them on the
board, and at the end I got them to make a conclusion - what are they
going to do better. However, the decisions were on the board only. All
was forgotten the very next day... Even when I reminded them - this
was your decision in your retrospective - they struggled to get out of
it.
To Onkar:
"Make this as one of their yearly Objective/Goal, which will be
considered at the time of appraisal"
That is a very good idea indeed! We have those, once a year, and the
considered at the time of appraisal"
goals set are appraised a year later and people get a bonus based on
it. Hmm, it just may work.
To Jens:
"How about aborting the Sprint? Let's face it, they don't have a
chance to succeed. "
That is very drastic!! I would like to still give them some more time,
chance to succeed. "
at least let them survive the planned team-building trip... (Also, for
selfish reasons, I would like my first SM job to show a success to all
these waterfall people around me.)
"to have at least one
experienced developer on the team who can handle the technology and
has a good understanding of the requirements"
There is none. Only one department in the company develops web-
experienced developer on the team who can handle the technology and
has a good understanding of the requirements"
applications in JSF, and they are using an older version. We have a
very good understanding of the requirements, but no experience. I must
add here, that the whole team attended a full 2 day course on Java JSF
newest technology. Maybe they need a brush-up, after a little bit of
experience?? (at least the girl has...)
"How about having more of those girls and fewer of those guys on the
team? :-)"
I like this one the best !! GIRL POWER !
team? :-)"
I promise you I will not give up. I will keep them going and help them
the best I can. My next step will be to suggest to my boss, that we
need another JSF training for the whole team. This company loves to
pay for training. So all I need to do is organise it. Now the team
should have real questions to ask.
Thanks a lot, really !
Kind regards,
Nela.
nela
Apr 29, 2010, 4:21:59 PM4/29/10
to Scrum Alliance - transforming the world of work.
Hi again,
I need some "male" insight:
as you are all guys here, can you put yourself in these guys position
in my team - where the girl is the only team member showing something
developed - how does it make a guy feel? Can't be good. What does a
guy normally do in those situations? How does he act and why?
From the guys point of view.
(if you think it is hard to understand women, think again. It is often
just as hard to understand guys. :-)
Nela.
I need some "male" insight:
as you are all guys here, can you put yourself in these guys position
in my team - where the girl is the only team member showing something
developed - how does it make a guy feel? Can't be good. What does a
guy normally do in those situations? How does he act and why?
From the guys point of view.
(if you think it is hard to understand women, think again. It is often
just as hard to understand guys. :-)
Nela.
Skip La Fetra
Apr 29, 2010, 6:37:37 PM4/29/10
to scruma...@googlegroups.com
> From the guys point of view.
It depends on the guy.
Lots of stereotypes kicking around, but everyone is an individual.
In my case, some of the best engineers I've ever managed have been women.
But some have been guys.
A few of the worst engineers I've managed have been women -- but the worst
of all time was a guy.
Similarly, I've worked for both good and not-so-good managers of both sexes.
So far, I've been unhelpful as far as "typical stereotypes" go. I honestly
think that there is more than a purely gender basis.
But, there may be social/ cultural/ clique/ factors -- and some cultures
have significant gender differences.
I'd try to understand each individual as much as possible as an individual,
but through a lens of cultural understanding particularly if the team is not
from the same cultural or geographic background. Or possibly if they are
not from the same academic background.
- Skip
-----Original Message-----
From: scruma...@googlegroups.com [mailto:scruma...@googlegroups.com]
On Behalf Of nela
Sent: Thursday, April 29, 2010 1:22 PM
To: Scrum Alliance - transforming the world of work.
Subject: [Scrum] Re: Why are we individually competent but collectively
incompetent?
Ilja Preuß
Apr 30, 2010, 3:52:25 AM4/30/10
to scruma...@googlegroups.com
Hi Nela,
> To Ilja:
> "How is the retrospective facilitated?"
> As my coach is present on each retrospective, he ran the first two,
> and I decided to run the third one myself. He told me he would have
> run it differently and I told him - every person runs things
> differently, it doesn't mean it is wrong. He agreed. However, the
> result is the same.
> What I did is, I put on the board the results of the previous
> agreements on a previous retrospective, asked the team how the
> decisions went through the sprint, did they do what they decided?
> Then, I started an open discussion what do they think they did bad in
> this failed sprint. And few things came out, I stuck them on the
> board, and at the end I got them to make a conclusion - what are they
> going to do better. However, the decisions were on the board only. All
> was forgotten the very next day... Even when I reminded them - this
> was your decision in your retrospective - they struggled to get out of
> it.
it sounds to me like your team could possibly benefit from a more
structured approach to retrospectives.
First, it's typically a good idea to gather facts before you start
interpreting them. Before you can have a reasonable discussion about
what happened, you need everyone on the same page. Not all team
members will have noticed the same things, or will have the same
perspectives on what happened, and it's important for everyone to get
a clear picture of this fact. A timeline exercise is a good way to do
this.
Second, I wouldn't concentrate on just the bad stuff they did. The
goal ist to improve the system they work in. For that, they also need
to look at stuff that wasn't under their direct control, and at stuff
that worked well. "What do we not want to loose, or even want to do
more off" is an important question to ask, especially for a team that
isn't very gelled or motivated.
Last but not least, I wonder what the team's decisions looked like.
How many were there? (They should probably concentrate on the one to
three most important ones.) Where they SMART? Perhaps a good question
for the next retrospective could be "why do we struggle living up to
our decisions, and what can we do about it?"
If you are interested in learning more about facilitating
retrospectives, I highly recommend the book "Agile Retrospectives".
Hope this helps,
Ilja
> To Ilja:
> "How is the retrospective facilitated?"
> As my coach is present on each retrospective, he ran the first two,
> and I decided to run the third one myself. He told me he would have
> run it differently and I told him - every person runs things
> differently, it doesn't mean it is wrong. He agreed. However, the
> result is the same.
> What I did is, I put on the board the results of the previous
> agreements on a previous retrospective, asked the team how the
> decisions went through the sprint, did they do what they decided?
> Then, I started an open discussion what do they think they did bad in
> this failed sprint. And few things came out, I stuck them on the
> board, and at the end I got them to make a conclusion - what are they
> going to do better. However, the decisions were on the board only. All
> was forgotten the very next day... Even when I reminded them - this
> was your decision in your retrospective - they struggled to get out of
> it.
structured approach to retrospectives.
First, it's typically a good idea to gather facts before you start
interpreting them. Before you can have a reasonable discussion about
what happened, you need everyone on the same page. Not all team
members will have noticed the same things, or will have the same
perspectives on what happened, and it's important for everyone to get
a clear picture of this fact. A timeline exercise is a good way to do
this.
Second, I wouldn't concentrate on just the bad stuff they did. The
goal ist to improve the system they work in. For that, they also need
to look at stuff that wasn't under their direct control, and at stuff
that worked well. "What do we not want to loose, or even want to do
more off" is an important question to ask, especially for a team that
isn't very gelled or motivated.
Last but not least, I wonder what the team's decisions looked like.
How many were there? (They should probably concentrate on the one to
three most important ones.) Where they SMART? Perhaps a good question
for the next retrospective could be "why do we struggle living up to
our decisions, and what can we do about it?"
If you are interested in learning more about facilitating
retrospectives, I highly recommend the book "Agile Retrospectives".
Hope this helps,
Ilja
nela
Apr 30, 2010, 2:51:33 PM4/30/10
to Scrum Alliance - transforming the world of work.
As far as a structured retrospective is concerned I have one question
that is bugging me:
How do I motivate the team to use the retrospective?
That is my main concern. They seem to be going through the motions, as
they were told that a retrospective is a part of scrum process, and it
will help them be a better and more productive team.
But it is like stopping smoking - you can help the person really with
good advice and analysis and explain how harmful it is, and get the
person to come to the conclusion that it would really be good to stop
smoking because of this and that reason, and the person will totally
agree. Then 24 hours later he will start again.
That is because he did not want to stop in the first place, and he
thought you had some magic wand.
There is no magic wand in Scrum, the team must WANT to be a good team.
(As you can see from my mood, I had another bad day at the office...)
Nela.
that is bugging me:
How do I motivate the team to use the retrospective?
That is my main concern. They seem to be going through the motions, as
they were told that a retrospective is a part of scrum process, and it
will help them be a better and more productive team.
But it is like stopping smoking - you can help the person really with
good advice and analysis and explain how harmful it is, and get the
person to come to the conclusion that it would really be good to stop
smoking because of this and that reason, and the person will totally
agree. Then 24 hours later he will start again.
That is because he did not want to stop in the first place, and he
thought you had some magic wand.
There is no magic wand in Scrum, the team must WANT to be a good team.
(As you can see from my mood, I had another bad day at the office...)
Nela.
nela
Apr 30, 2010, 3:03:02 PM4/30/10
to Scrum Alliance - transforming the world of work.
I have come to one conclusion - I dont know if you think it is
correct:
A good scrum team has to be formed from experienced developers, not
newcomers and wannabies.
That does not mean they need to know exactly the technology they would
work with, I mean experienced in a sense that they have taken part in
more projects than you can count on one hand.
This lot I have are all newbies. Max 2 years of work in an office, let
alone develop something from scratch, design from scratch, and be
capable to self-organise. They are still growing up, and they do not
know where they are going - let alone why.
Maybe that is where the problem lies.
The little quarrels and arguments about very superficial issues,
trying to prove to others that you are clever, that would not happen
in a group of proffessional experienced developers. Or am I wrong.
What do you think?
Regards,
Nela.
correct:
A good scrum team has to be formed from experienced developers, not
newcomers and wannabies.
That does not mean they need to know exactly the technology they would
work with, I mean experienced in a sense that they have taken part in
more projects than you can count on one hand.
This lot I have are all newbies. Max 2 years of work in an office, let
alone develop something from scratch, design from scratch, and be
capable to self-organise. They are still growing up, and they do not
know where they are going - let alone why.
Maybe that is where the problem lies.
The little quarrels and arguments about very superficial issues,
trying to prove to others that you are clever, that would not happen
in a group of proffessional experienced developers. Or am I wrong.
What do you think?
Regards,
Nela.
George Dinwiddie
Apr 30, 2010, 6:25:17 PM4/30/10
to scruma...@googlegroups.com
Hi, Nela,
nela wrote:
> As far as a structured retrospective is concerned I have one question
> that is bugging me:
> How do I motivate the team to use the retrospective?
Have a retrospective that the team finds valuable /for themselves./ I
see many orgs try to have retrospectives only for the organization's
benefit. The team needs to first tend to their own benefit. Over time,
the team's benefit and the organization's benefit will become better
aligned, because that's to both their benefit.
> That is my main concern. They seem to be going through the motions, as
> they were told that a retrospective is a part of scrum process, and it
> will help them be a better and more productive team.
Do they want to be "better and more productive?" Maybe there's
something else they want more immediately?
> But it is like stopping smoking - you can help the person really with
> good advice and analysis and explain how harmful it is, and get the
> person to come to the conclusion that it would really be good to stop
> smoking because of this and that reason, and the person will totally
> agree. Then 24 hours later he will start again.
Yes, a person will stop smoking when they want to do so. When that's
true, they'll do so rather easily (though still with physical
withdrawal). Stopping because some other person wants them to do so is
very hard, and rarely seems to work.
> That is because he did not want to stop in the first place, and he
> thought you had some magic wand.
> There is no magic wand in Scrum, the team must WANT to be a good team.
The magic wand is finding the key that makes the team want to be a good
team. See also the story of the "buffalo bridle" in Weinberg's Secrets
of Consulting.
> (As you can see from my mood, I had another bad day at the office...)
Sorry to hear that.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
nela wrote:
> As far as a structured retrospective is concerned I have one question
> that is bugging me:
> How do I motivate the team to use the retrospective?
see many orgs try to have retrospectives only for the organization's
benefit. The team needs to first tend to their own benefit. Over time,
the team's benefit and the organization's benefit will become better
aligned, because that's to both their benefit.
> That is my main concern. They seem to be going through the motions, as
> they were told that a retrospective is a part of scrum process, and it
> will help them be a better and more productive team.
something else they want more immediately?
> But it is like stopping smoking - you can help the person really with
> good advice and analysis and explain how harmful it is, and get the
> person to come to the conclusion that it would really be good to stop
> smoking because of this and that reason, and the person will totally
> agree. Then 24 hours later he will start again.
true, they'll do so rather easily (though still with physical
withdrawal). Stopping because some other person wants them to do so is
very hard, and rarely seems to work.
> That is because he did not want to stop in the first place, and he
> thought you had some magic wand.
> There is no magic wand in Scrum, the team must WANT to be a good team.
team. See also the story of the "buffalo bridle" in Weinberg's Secrets
of Consulting.
> (As you can see from my mood, I had another bad day at the office...)
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Vernon Stinebaker
May 1, 2010, 11:40:11 AM5/1/10
to scruma...@googlegroups.com
Not my experience. I put fresh graduates through a multi-week Boot Camp where they're taught the Scrum framework, agile principles and practices, and are challenged to put them to practical use in a project delivered across two weekly Sprints. The participants are new to Scrum, agile, self-organizating, and I'm usually throwing in technology that's new to them as well; but consistently they're able to deliver something valuable (though usually not everything they commit to) in the first Sprint, and come close to or meet their commitment in the second Sprint. We've done this many times, and it's always worked, so I know that Scrum works with completely inexperienced teams.
I've actually experienced more challenge in getting people with more experience who think they know the right way to do things to open their minds to a new way of thinking, but even in these cases with proper coaching they also come around.
I think you mentioned you have a coach? What's the coach's advice? It's much easier for someone who's working directly with the team to provide insight and suggestions. Inaccurate actions based on preconceived behaviors (like thinking that they are unable to develop from scratch, design, or incapable of self organization) sometimes reinforces existing organizational impediments.
Are you familiar with Bruce Tuckman's Group Development Model (Forming, Storming, Norming, and Performing). "Little quarrels and arguments" sounds like Storming; a very normal behavior for teams and necessary for teams to pass through before being able to progress. You might want to read a bit more about this model and see what you can do to help the team proceed through this stage.
Thanks,
Vernon
I've actually experienced more challenge in getting people with more experience who think they know the right way to do things to open their minds to a new way of thinking, but even in these cases with proper coaching they also come around.
I think you mentioned you have a coach? What's the coach's advice? It's much easier for someone who's working directly with the team to provide insight and suggestions. Inaccurate actions based on preconceived behaviors (like thinking that they are unable to develop from scratch, design, or incapable of self organization) sometimes reinforces existing organizational impediments.
Are you familiar with Bruce Tuckman's Group Development Model (Forming, Storming, Norming, and Performing). "Little quarrels and arguments" sounds like Storming; a very normal behavior for teams and necessary for teams to pass through before being able to progress. You might want to read a bit more about this model and see what you can do to help the team proceed through this stage.
Thanks,
Vernon
Ilja Preuß
May 3, 2010, 10:17:06 AM5/3/10
to scruma...@googlegroups.com
Hi Nela,
2010/4/30 nela <nela.sold...@gmail.com>:
> Maybe that is where the problem lies.
> The little quarrels and arguments about very superficial issues,
> trying to prove to others that you are clever, that would not happen
> in a group of proffessional experienced developers. Or am I wrong.
> What do you think?
I think you don't have a team. I wonder where that's coming from. How
are they evaluated? Is anyone holding them accountable *as a team*?
Curious, Ilja
2010/4/30 nela <nela.sold...@gmail.com>:
> I have come to one conclusion - I dont know if you think it is
> correct:
> A good scrum team has to be formed from experienced developers, not
> newcomers and wannabies.
> That does not mean they need to know exactly the technology they would
> work with, I mean experienced in a sense that they have taken part in
> more projects than you can count on one hand.
Absolutely not. Scrum is great for and with newbies!
> correct:
> A good scrum team has to be formed from experienced developers, not
> newcomers and wannabies.
> That does not mean they need to know exactly the technology they would
> work with, I mean experienced in a sense that they have taken part in
> more projects than you can count on one hand.
> Maybe that is where the problem lies.
> The little quarrels and arguments about very superficial issues,
> trying to prove to others that you are clever, that would not happen
> in a group of proffessional experienced developers. Or am I wrong.
> What do you think?
are they evaluated? Is anyone holding them accountable *as a team*?
Curious, Ilja
nela
May 3, 2010, 3:44:28 PM5/3/10
to Scrum Alliance - transforming the world of work.
Hello,
""Little quarrels and arguments" sounds like Storming; a very normal
behavior for teams and necessary for teams to pass through before
being able to progress. "
I am thinking that in 2-3 more sprints they will be able to progress.
---------
This is an internal project, the product will be administered in the
end by the same team, the department head is our PO, we all sit in the
same room... Seems all is ok. However, it does not work. Yet. And I do
not think that anyone is holding them accountable as a team. But - it
is balancing act now: to scrum or not to scrum... ...
> 2010/4/30 nela <nela.soldatovjo...@gmail.com>:
""Little quarrels and arguments" sounds like Storming; a very normal
behavior for teams and necessary for teams to pass through before
being able to progress. "
---------
"> I think you don't have a team. I wonder where that's coming from.
How
> are they evaluated? Is anyone holding them accountable *as a team*?"
I really hope that I still do have a team. Where it is coming from?
How
> are they evaluated? Is anyone holding them accountable *as a team*?"
This is an internal project, the product will be administered in the
end by the same team, the department head is our PO, we all sit in the
same room... Seems all is ok. However, it does not work. Yet. And I do
not think that anyone is holding them accountable as a team. But - it
is balancing act now: to scrum or not to scrum... ...
> 2010/4/30 nela <nela.soldatovjo...@gmail.com>:
Ilja Preuß
May 4, 2010, 7:45:02 AM5/4/10
to scruma...@googlegroups.com
Hi Nela,
there are two conditions that make a work group be a team:
- a common goal that the group is collectively held accountable for, and
- mutual dependencies between the team members for reaching that goal.
Sounds to me like your for your group, those conditions aren't met. No
wonder that they don't behave like a team.
What do you think?
Cheers, Ilja
2010/5/3 nela <nela.sold...@gmail.com>:
there are two conditions that make a work group be a team:
- a common goal that the group is collectively held accountable for, and
- mutual dependencies between the team members for reaching that goal.
Sounds to me like your for your group, those conditions aren't met. No
wonder that they don't behave like a team.
What do you think?
Cheers, Ilja
2010/5/3 nela <nela.sold...@gmail.com>:
nela
May 4, 2010, 4:24:46 PM5/4/10
to Scrum Alliance - transforming the world of work.
Hi Ilja,
common goal is only to create this new product - web application.
Yes, they are dependent on each other to accomplish that goal, as far
as I can see, the knowledge is dispersed. But, somehow they are still
not focused to deliver user stories.
In the sprintplan they break up the user story in tasks, and during
the sprint they concentrate so much on each task, elaborate, argue,
find new things to do... that the user story is forgotten. Every
single day I ask them again and again - what about user stories, where
are you with user stories on the sprint plan? They shrug their
shoulders, and go on with their little tasks.
Today we had a review - nothing to deliver. Not a single user story
ready. PO was really not happy. Neither was I.
Retrospective after the review was very short and to the point. I told
them you must give yourselves clear decisions to improve, we cannot go
on like this. And they seem to understand. Quickly 6-7 points were put
on the board. And that list will be on the Sprint board for the whole
length of the 5th Spring. I still have (a little) energy left... ...
Lets see how they do in the next sprint...
Keep fingers crossed.
Nela.
common goal is only to create this new product - web application.
Yes, they are dependent on each other to accomplish that goal, as far
as I can see, the knowledge is dispersed. But, somehow they are still
not focused to deliver user stories.
In the sprintplan they break up the user story in tasks, and during
the sprint they concentrate so much on each task, elaborate, argue,
find new things to do... that the user story is forgotten. Every
single day I ask them again and again - what about user stories, where
are you with user stories on the sprint plan? They shrug their
shoulders, and go on with their little tasks.
Today we had a review - nothing to deliver. Not a single user story
ready. PO was really not happy. Neither was I.
Retrospective after the review was very short and to the point. I told
them you must give yourselves clear decisions to improve, we cannot go
on like this. And they seem to understand. Quickly 6-7 points were put
on the board. And that list will be on the Sprint board for the whole
length of the 5th Spring. I still have (a little) energy left... ...
Lets see how they do in the next sprint...
Keep fingers crossed.
Nela.
> there are two conditions that make a work group be a team:
>
> - a common goal that the group is collectively held accountable for, and
>
> - mutual dependencies between the team members for reaching that goal.
>
> Sounds to me like your for your group, those conditions aren't met. No
> wonder that they don't behave like a team.
>
> What do you think?
>
> Cheers, Ilja
>
> 2010/5/3 nela <nela.soldatovjo...@gmail.com>:
>
> - a common goal that the group is collectively held accountable for, and
>
> - mutual dependencies between the team members for reaching that goal.
>
> Sounds to me like your for your group, those conditions aren't met. No
> wonder that they don't behave like a team.
>
> What do you think?
>
> Cheers, Ilja
>
Jens Meydam
May 5, 2010, 3:36:50 PM5/5/10
to Scrum Alliance - transforming the world of work.
Hi Nela,
I really like Ilja's two conditions for something like a team spirit
to develop. This is also at the heart of Scrum (as far as I
understand it): A team faces a challenging goal that it can only
reach by working together. A good analogy are elite units in the
military.
> common goal is only to create this new product - web application.
> Yes, they are dependent on each other to accomplish that goal, as far
> as I can see, the knowledge is dispersed. But, somehow they are still
> not focused to deliver user stories.
1) The attitude of most of the team members (the "girl" being the
shining exception)
2) The incompetence of the team members with regard to the chosen
technology
3) The choice of a technology version that doesn't work well
As for the first point, you got wonderfully sounding advice, but ...
just imagine an elite unit in the military behaving in that way! If I
could, I would get rid of the worst team members and try to get at
least one more team member like the girl. I would even take a
trainee, but someone bright with the right attitude.
The second and third point are easier to deal with. If you could only
reverse your decision to use an immature version of the technology and
could use a properly working, well documented version (at least for
the time being) ... There must be some decent textbooks and guides on
standard JSF; a motivated team should be able to get something simple
working fairly quickly, even without much training / coaching.
> I still have (a little) energy left... ...
> Lets see how they do in the next sprint...
> Keep fingers crossed.
Ken Schwaber likes to point out that one of the great things about
Scrum is that it gives you the bad news early. Had you taken a
waterfall approach to this project, how long would it have taken you
until it would have been blindingly clear that as it is the project is
kind of doomed?
With Scrum, the problems become obvious very fast and you have the
choice to abort the project, to try to overcome the difficulties or
(but who in his right mind would do that?) to stand by watching as the
team fails sprint after sprint and the company keeps burning money
with very little to show for it.
Jens
I really like Ilja's two conditions for something like a team spirit
to develop. This is also at the heart of Scrum (as far as I
understand it): A team faces a challenging goal that it can only
reach by working together. A good analogy are elite units in the
military.
> common goal is only to create this new product - web application.
> Yes, they are dependent on each other to accomplish that goal, as far
> as I can see, the knowledge is dispersed. But, somehow they are still
> not focused to deliver user stories.
> Today we had a review - nothing to deliver. Not a single user story
> ready. PO was really not happy. Neither was I.
From what you write I guess there are three basic problems:
> ready. PO was really not happy. Neither was I.
1) The attitude of most of the team members (the "girl" being the
shining exception)
2) The incompetence of the team members with regard to the chosen
technology
3) The choice of a technology version that doesn't work well
As for the first point, you got wonderfully sounding advice, but ...
just imagine an elite unit in the military behaving in that way! If I
could, I would get rid of the worst team members and try to get at
least one more team member like the girl. I would even take a
trainee, but someone bright with the right attitude.
The second and third point are easier to deal with. If you could only
reverse your decision to use an immature version of the technology and
could use a properly working, well documented version (at least for
the time being) ... There must be some decent textbooks and guides on
standard JSF; a motivated team should be able to get something simple
working fairly quickly, even without much training / coaching.
> I still have (a little) energy left... ...
> Lets see how they do in the next sprint...
> Keep fingers crossed.
Scrum is that it gives you the bad news early. Had you taken a
waterfall approach to this project, how long would it have taken you
until it would have been blindingly clear that as it is the project is
kind of doomed?
With Scrum, the problems become obvious very fast and you have the
choice to abort the project, to try to overcome the difficulties or
(but who in his right mind would do that?) to stand by watching as the
team fails sprint after sprint and the company keeps burning money
with very little to show for it.
Jens
nela
May 9, 2010, 11:19:49 AM5/9/10
to Scrum Alliance - transforming the world of work.
Hi Jens,
thanks a lot for that post !! I will think about the points you
made... ...
bye
Nela.
thanks a lot for that post !! I will think about the points you
made... ...
bye
Nela.
Reply all
Reply to author
Forward
0 new messages