2008/6/1, Tobias Mayer <tobias.mayer@...>:
>
>  Does anyone actually know if Nokia are really doing Scrum?  My guess is
>  that if Nokia see so little value in the empirical nature of Scrum as to
>  exclude it from their survey then they are probably not.

Yes, they are doing Scrum.

And a +1 to Peter. According to what info has been published and
talked about in miniseminars here in Finland (the birthplace of
Nokia), the Nokia test is hardly even the tip of the iceberg regarding
Nokias agile adoption. To me at least the Nokia test is very
indicative of whether or not a team is at all agile. They might get
top scores with the test and still not do agile very well, but they
are still agile/IID. That's the other thing; if memory serves me
correct, the test is not to indicate, whether the team is doing Scrum,
but whether the team is doing agile/IID.

Nina
--
I reject your reality and substitute my own.

I think Nina gets the idea.

It is NOT a test of whether a team is doing Scrum well.  It is whether
one team is possibly doing something like Scrum (ie, a fair chance
that they are not doing Waterfall and calling it Scrum, and a fair
chance that they are not doing Cowboy Agile and calling it Scrum).

It is to keep away from the worst smells.

If you don't have a pitcher, if you don't call an out after 3 strikes,
  you are NOT playing baseball.  Those questions don't say whether you
are playing baseball.  And certainly not whether you are playing at a
major league level.

Little Test: I will of course in my head use a Little Test to judge
whether the teams I am working with a doing it "well enough for now".
  But I would never publicly declare a Little Test.  I think it has to
come from user firms.  I welcome additional tests, such as the Exxon
Mobil test or the IBM Test or the Sam's Web Design Test, etc. And one
hopes they will listen to smart folks like you all in constructing
their version.

I think that Tobias and Peter and Nina raised some good issues. No
test would be perfect (in my opinion), and certainly the Nokia Test is
not perfect. Imperfection does not void its usefulness in some
contexts.  If you wait for perfection, you will wait too long.

Regards, Joe


--- In scrumdevelopment@yahoogroups.com, "Nina Niskanen"
<nina.niskanen@...> wrote:
>
> 2008/6/1, Tobias Mayer <tobias.mayer@...>:
> >
> >  Does anyone actually know if Nokia are really doing Scrum?  My
guess is
> >  that if Nokia see so little value in the empirical nature of
Scrum as to
> >  exclude it from their survey then they are probably not.
>
> Yes, they are doing Scrum.
>
> And a +1 to Peter. According to what info has been published and
> talked about in miniseminars here in Finland (the birthplace of
> Nokia), the Nokia test is hardly even the tip of the iceberg regarding
> Nokias agile adoption. To me at least the Nokia test is very
> indicative of whether or not a team is at all agile. They might get
> top scores with the test and still not do agile very well, but they
> are still agile/IID. That's the other thing; if memory serves me
> correct, the test is not to indicate, whether the team is doing Scrum,
> but whether the team is doing agile/IID.
>
> Nina
> --
> I reject your reality and substitute my own.
>

Jeff Sutherland says that Scrum was built to increase productivity 5x
to 10x.  I thought I backed off enough already.

Lean would say: Don't bother with small changes, which include so many
accommodations to the current, bad ways of doing things.  If you see a
big change, go after it.  Aiming for 50% and getting only 25% is way
better than aiming for 8% and getting only 7%.

Remember: This is baselined at the 3rd iteration.  They can barely
spell Scrum at that point. (OK, you told me a million times not to
exaggerate.)

We need to (figuratively) grab management by the collar and say: We
ain't doing business as usual any more!  We're serious. You have to
help us knock down the impediments.

Regards, Joe


--- In scrumdevelopment@yahoogroups.com, Don Gray <don@...> wrote:
>
> Cory,
>
> > I think I'd be hesitant to give concrete figures, since that tends to
> > sharpen managements vision towards that metric (IME).
>
> In Secrets of Consulting Jerry Weinberg advises not to offer
> improvement figures > 10%. I'm at the Agile Coach Camp so I don't have
> my book so read why ...
>
> I've been told to never give management a number, but a range. Since
> managers remember the first number they hear (gross generalization but
> pretty true in my experience) I also give the "worst" number first. In
> this case ... "oh, I think with proper coaching the teams could
> improve their velocity 7.8 - 9.2%". If I was pressured for a date
> range, I'd say something like, "Well, I'm not sure. I think we can
> deliver somewhere in the 6 - 5 month range." If they're paying
> attention it can start a conversation.
>
> --
> Don (336)374-7591
>
> We do not rise to the level of our expectations.
> We fall to the level of our training.
> Author Unknown
> Raise your training level at the AYE Conference Nov 2 - 5, 2008
> www.AYEconference.com
>

If you have an uninvolved manager, yeah, tell him 10% or 5%.  Whatever.

If you have a busy manager whom you want to actively help with the
impediments, you have to give him a reason to play.  He's got bigger
fish to fry than 5% on Team X over there.

Check out Takeuchi and Nonaka's article: The New New Product
Development Game.  See hbr.com ($6).  This is where Scrum started. The
managers came in with a real challenge.  And then the Team responded.
(The managers did not micro-manage at all.)

Regards, Joe


--- In scrumdevelopment@yahoogroups.com, Don Gray <don@...> wrote:
>
> Cory,
>
> > I think I'd be hesitant to give concrete figures, since that tends to
> > sharpen managements vision towards that metric (IME).
>
> In Secrets of Consulting Jerry Weinberg advises not to offer
> improvement figures > 10%. I'm at the Agile Coach Camp so I don't have
> my book so read why ...
>
> I've been told to never give management a number, but a range. Since
> managers remember the first number they hear (gross generalization but
> pretty true in my experience) I also give the "worst" number first. In
> this case ... "oh, I think with proper coaching the teams could
> improve their velocity 7.8 - 9.2%". If I was pressured for a date
> range, I'd say something like, "Well, I'm not sure. I think we can
> deliver somewhere in the 6 - 5 month range." If they're paying
> attention it can start a conversation.
>
> --
> Don (336)374-7591
>
> We do not rise to the level of our expectations.
> We fall to the level of our training.
> Author Unknown
> Raise your training level at the AYE Conference Nov 2 - 5, 2008
> www.AYEconference.com
>

Dear practitioners.

I am in a somewhat awkward position. While the company I am working
for is very successful and recently has one a rather awesome new
customer, capable of literally transforming the future of said
company, I am still left with an environment which seems to be unsure
of itself. Without going into to much detail I will explain the
situation in its utter simplicity.

a) New customer, trusts us, very happy to work with us, but an utterly
tight deadline end of August. Customer has an existing (very simple)
web-site which needs to be "cloned" on our platform.
b) Customer is willing to negotiate on what can be done, they much
rather have "a business" at the end of August than not having any
business at all.
c) The middle ware platform we would ideally like to port this to is
not fully there yet, however many think it is achievable.

There have been many discussions around risk reduction, a plan B is in
effect and there is no reason to believe whatsoever that the people
needing to deliver this were not involved. The teams have been
repeatedly asked about scope, they esitimated, they raised concerned
etc etc.

I strongly believe that everything has been done to consult the people
that need to commit to the work and I believe that the business side
of things has always said "tell us what is doable and we will
negotiate with them".

However to me this is a matter of belief now. This is more about
conviction that we can achieve this and it is something that is not
quantifiable. When General Meng Tian was tasked to build a wall "8
foot high and 3000 miles long" around China he must have somehow
developed that faith and made some of his helpers see, when President
Kennedy asked to put a man on the moon within 7 years, some NASA
engineers must have developed that faith.

While I know a lot about human psychology and the motivational tools
we can utilise to make those around us feel at ease with a task at
hand, I know little about faith. I do not believe in a God, I do not
have ea religion, most of the things I believe in are driven by cold
hard facts. However, in this very case, to rise above and beyond
themselves I believe the people on the floor need to have "faith". My
question is a simple one. How can I help foster an environment which
allows room for believing and taking the risk to believe.

Thank you

-d


--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Interesting thread.

A good discussion of this area can be found in "Ship It!" from the
"The Pragmatic Programmers" series, which considers issue tracking
software in the context of complimentary tools like version control
systems, continuous integration frameworks etc. When used in
conjunction with those tools they can really add value.

To echo what Austin says, having recently worked in an environment
which was generating a lot of new feature requests and bug reports
from different international offices, using an issue/defect tracking
system proved invaluable to capture and manage those requests.

Most of them allow communication with the requester / business owner
using email and/or a wiki-type interface, and can be used to share
information across the business. An added advantage is that several of
them can be extended via plugins to interface directly with
Subversion, generate virtual whiteboards, burn-down charts etc.

I fully accept the point that maintaining the tool shouldn't become
the focus rather than the process, but when used appropriately there
is a place for good issue tracking software.

---

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of David H.
Sent: 01 June 2008 16:39
To: scrumdev
Subject: [scrumdevelopment] A leap of faith and how to convince people to jump...

Dear practitioners.

I am in a somewhat awkward position. While the company I am working
for is very successful and recently has one a rather awesome new
customer, capable of literally transforming the future of said
company, I am still left with an environment which seems to be unsure
of itself. Without going into to much detail I will explain the
situation in its utter simplicity.

a) New customer, trusts us, very happy to work with us, but an utterly
tight deadline end of August. Customer has an existing (very simple)
web-site which needs to be "cloned" on our platform.
b) Customer is willing to negotiate on what can be done, they much
rather have "a business" at the end of August than not having any
business at all.
c) The middle ware platform we would ideally like to port this to is
not fully there yet, however many think it is achievable.

There have been many discussions around risk reduction, a plan B is in
effect and there is no reason to believe whatsoever that the people
needing to deliver this were not involved. The teams have been
repeatedly asked about scope, they esitimated, they raised concerned
etc etc.

I strongly believe that everything has been done to consult the people
that need to commit to the work and I believe that the business side
of things has always said "tell us what is doable and we will
negotiate with them".

However to me this is a matter of belief now. This is more about
conviction that we can achieve this and it is something that is not
quantifiable. When General Meng Tian was tasked to build a wall "8
foot high and 3000 miles long" around China he must have somehow
developed that faith and made some of his helpers see, when President
Kennedy asked to put a man on the moon within 7 years, some NASA
engineers must have developed that faith.

While I know a lot about human psychology and the motivational tools
we can utilise to make those around us feel at ease with a task at
hand, I know little about faith. I do not believe in a God, I do not
have ea religion, most of the things I believe in are driven by cold
hard facts. However, in this very case, to rise above and beyond
themselves I believe the people on the floor need to have "faith". My
question is a simple one. How can I help foster an environment which
allows room for believing and taking the risk to believe.

Thank you

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Hello
> Unless there is an extremely compelling reason to adopt the new middle ware
> platform, such as you haven't got a viable alternative, I would go for the
> tried and tested approach every time, especially as the new customer is
> "rather awesome".
>
There are numerous compelling reasons which are extremely important.
The people delivering the solution _want_ to adopt the new solution
but it seems they are not quite 100% sure and there is no willingness
at all to take a leap of faith and take a little buit of risk.

> Sounds like the customer is betting his business on you delivering, would
> you be willing to, say, bet your house on the new technology delivering by
> August?
Yes, of course I would. I have long past taken that leap of faith and
I am more than comfortable betting my job and my life, staking it on
this delivery. Simply _because_ it has been carefully locked at, no
one asks the impossible and it seems to be reflected by the teams
delivering the work and yet still they are scared.

> Perhaps there is a very good reason why the "people on the floor"
> haven't got faith.

Very good, what would you suggest to do to find out. Because every
conversation I am having seems to revolve around the fact that people
say "yepp I think we could do it" but no one stand sup and says "let's
do it".
>
> You should foster an environment where the team is empowered to make the
> most appropriate decision in their eyes. If this is adopting older, more
> stable technology - then so be it.
>
I am sorry but that does not work all the time. There are business
decisions on a strategic level which need to be taken into account as
well. I feel it is my job to faciltate this understanding so that the
people commiting can make the right decision. Once I have facilitated
that knoweldge and they still choose to use the old, slightly broken
but proven technology, then so be it.

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

---

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of David H.
Sent: 01 June 2008 19:02
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] A leap of faith and how to convince people to jump...

Hello
> Unless there is an extremely compelling reason to adopt the new middle ware
> platform, such as you haven't got a viable alternative, I would go for the
> tried and tested approach every time, especially as the new customer is
> "rather awesome".
>
There are numerous compelling reasons which are extremely important.
The people delivering the solution _want_ to adopt the new solution
but it seems they are not quite 100% sure and there is no willingness
at all to take a leap of faith and take a little buit of risk.

> Sounds like the customer is betting his business on you delivering, would
> you be willing to, say, bet your house on the new technology delivering by
> August?
Yes, of course I would. I have long past taken that leap of faith and
I am more than comfortable betting my job and my life, staking it on
this delivery. Simply _because_ it has been carefully locked at, no
one asks the impossible and it seems to be reflected by the teams
delivering the work and yet still they are scared.

> Perhaps there is a very good reason why the "people on the floor"
> haven't got faith.

Very good, what would you suggest to do to find out. Because every
conversation I am having seems to revolve around the fact that people
say "yepp I think we could do it" but no one stand sup and says "let's
do it".
>
> You should foster an environment where the team is empowered to make the
> most appropriate decision in their eyes. If this is adopting older, more
> stable technology - then so be it.
>
I am sorry but that does not work all the time. There are business
decisions on a strategic level which need to be taken into account as
well. I feel it is my job to faciltate this understanding so that the
people commiting can make the right decision. Once I have facilitated
that knoweldge and they still choose to use the old, slightly broken
but proven technology, then so be it.

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

David H. wrote:
>> Perhaps there is a very good reason why the "people on the floor"
>> haven't got faith.
>
> Very good, what would you suggest to do to find out. Because every
> conversation I am having seems to revolve around the fact that people
> say "yepp I think we could do it" but no one stand sup and says "let's
> do it".

Can you give an example of such a conversation?

Have you asked them what they'd need to be excited about doing this?

Have you asked them what they'd really like to do?

What (do they believe) happens if they fail?

> I am sorry but that does not work all the time. There are business
> decisions on a strategic level which need to be taken into account as
> well. I feel it is my job to faciltate this understanding so that the
> people commiting can make the right decision. Once I have facilitated
> that knoweldge and they still choose to use the old, slightly broken
> but proven technology, then so be it.

Could it be that they feel pressed to use the new technology - however
subtly?

Have you ever told them that you will support any decision they come up
with on this?

Curious, Ilja

PS: You might want to look into "Powerful Questions"...

Hi Paul,


Sounds to me the problem isn't in the PO or in the technical stories.
I mean, sure, those areas may need improvement, but they are not the
core problem. I think you addressed the core problem yourself: not
releasing things.

If you don't release, you don't do workable iterative and incremental
software development. You don't get feedback, you don't get customer
ownership, you don't get tested working milestones. I don't know if
the team releases "potentially shippable increments of functionality",
but if they don't you don't have incremental development, either. It's
just waterfall with a different management framework, with pretty much
all the problems of waterfall development.

So the first thing I would do is check how the team's operation fits
in with the goals of iterative and incremental development & the
values and principles of Agile development. Then coach the team to
change they work to match them. Only _then_ I think it makes sense to
go to coach the PO (as you stated yourself).

The typical problem with technical stories is that they tend to be
horizontal. That is, they don't address end user functionality
directly. It is difficult to do effective iterative and incremental
development when you can only deliver partial functionality at a time.
So if you see that kind of problems in the product backlog, it would
make sense to rework those issues with the team.

Now, if the lead architect is used to running the show, you might have
problems turning the ship about. He is the person you need to
convince. He is either your best friend or your strongest opponent.
The PO seems detached and sounds unlikely to impose requirements on
the project. He already doesn't demand milestones, so why would he
oppose improvements to his position? [I don't mean that the milestones
would be good to require, but it just shows he doesn't require
specific issues even if he thinks they would be good in his opinion.]


Wishing you good luck,


Petri Heiramo
Senior Process Improvement Manager, CSP
Digia Plc., Finland

> Hi All,
>
> I have recently started working as a coach with a team that has
> primarily been using Scrum. They have an established backlog which
> includes a number of technical features. I believe that this is
> ligitimate in Scrum. The problem we are having is getting firm
> ownership of the backlog. From the customers point of view, the
> backlog is a "to do list" for the development team. If I say that the
> team have been going for 18 months and is planning on delivering it's
> first release in the next two months then you'll get the picture :)
>
> So the customer doesn't feel that he owns the backlog. He is just
> waiting for his realse, waterfall style. This feeling is reinforced by
> technical features in the backlog that are created by the lead
> architect, and assigned priority based on his advice, and which
> clearly do not belong to the customer.
>
> How does this work in a Scrum team.? My experience is XP.
>
> Regards,
>
> Paul.

(responding to Don)

> In Secrets of Consulting Jerry Weinberg advises not to offer
> improvement figures > 10%. I'm at the Agile Coach Camp so
> I don't have my book so read why ...

I don't have the book handy either, but the usual quoted reason
is that if you offer more than 10% you are implying that the
management have been doing things wrong in the past, which
gives them a motivation for finding fault with you and your
ideas.

Personally, I try telling it like it is.  If I think there's
potential for 5x, 10x or occasionally 20x improvement, but
what I'll do is say "This is what's been achieved elsewhere.
I believe we can use some of those ideas here and make some
of those improvements in productivty".  That allows them a
way out; they can think that not all of the techniques
would work here; think that "some" means a few percent when I
have in mind more like 90%.  A direct quote from one of my
clients - "When I look back to what we were doing a year ago
- I didn't realise how bad we were!"

Paul.

--- In scrumdevelopment@yahoogroups.com, "barvybe" <pgoldey@...> wrote:
>
> I think the real issue here is around the release timeframes you
> mentioned.
>
> The "team" should be demonstrating code every few weeks that the
> customer reviews and provides feedback on.  The customer can then
> "release" the product as soon / late as they wish, do multiple
> releases, etc.
>
> Otherwise, you are correct - from the customer's perspective this is
> waterfall and hence the tensions you are dealing with.
>
> Pete
>
Yep - Which is why I have been treading gently :)

Despite this the organisation has chosen Scrum as the way forward and
the PO needs to be aware of his responsibilities.

I'll be speaking to the PO today. Wish me luck :)

Paul.

--- In scrumdevelopment@yahoogroups.com, "m.sumrell" <m.sumrell@...>
wrote:
>
> Paul -
> My advice is to have the team write ALL stories in a way that shows
> benefit to the customer.  The customer should be able to understand
> all the stories in the backlog.  Mike Cohn's book on User Stories
> gives some great examples on how to do this.
>
>
> --- In scrumdevelopment@yahoogroups.com, "beckfordp" <beckfordp@>
> wrote:
> >
> > Hi All,
> >
> > I have recently started working as a coach with a team that has
> > primarily been using Scrum. They have an established backlog which
> > includes a number of technical features. I believe that this is
> > ligitimate in Scrum. The problem we are having is getting firm
> > ownership of the backlog. From the customers point of view, the
> > backlog is a "to do list" for the development team. If I say that
> the
> > team have been going for 18 months and is planning on delivering
> it's
> > first release in the next two months then you'll get the picture :)
> >
> > So the customer doesn't feel that he owns the backlog. He is just
> > waiting for his realse, waterfall style. This feeling is reinforced
> by
> > technical features in the backlog that are created by the lead
> > architect, and assigned priority based on his advice, and which
> > clearly do not belong to the customer.
> >
> > How does this work in a Scrum team.? My experience is XP.
> >
> > Regards,
> >
> > Paul.
> >
>
Yep - I intend to run through a story re-write with the PO first so
that he can see the value in it.

Thanx,

P.

Hi Petri,

Your reading of the situation is spot on. There are a number of
complex people issues at play.

I've been here before, so I'll be applying my usual charms in an
attempt to influence the team in a positive direction.

Thanks for the advice.

Paul.

--- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
<petri.heiramo@...> wrote:
>
> Hi Paul,
>
>
> Sounds to me the problem isn't in the PO or in the technical stories.
> I mean, sure, those areas may need improvement, but they are not the
> core problem. I think you addressed the core problem yourself: not
> releasing things.
>
> If you don't release, you don't do workable iterative and incremental
> software development. You don't get feedback, you don't get customer
> ownership, you don't get tested working milestones. I don't know if
> the team releases "potentially shippable increments of functionality",
> but if they don't you don't have incremental development, either. It's
> just waterfall with a different management framework, with pretty much
> all the problems of waterfall development.
>
> So the first thing I would do is check how the team's operation fits
> in with the goals of iterative and incremental development & the
> values and principles of Agile development. Then coach the team to
> change they work to match them. Only _then_ I think it makes sense to
> go to coach the PO (as you stated yourself).
>
> The typical problem with technical stories is that they tend to be
> horizontal. That is, they don't address end user functionality
> directly. It is difficult to do effective iterative and incremental
> development when you can only deliver partial functionality at a time.
> So if you see that kind of problems in the product backlog, it would
> make sense to rework those issues with the team.
>
> Now, if the lead architect is used to running the show, you might have
> problems turning the ship about. He is the person you need to
> convince. He is either your best friend or your strongest opponent.
> The PO seems detached and sounds unlikely to impose requirements on
> the project. He already doesn't demand milestones, so why would he
> oppose improvements to his position? [I don't mean that the milestones
> would be good to require, but it just shows he doesn't require
> specific issues even if he thinks they would be good in his opinion.]
>
>
> Wishing you good luck,
>
>
> Petri Heiramo
> Senior Process Improvement Manager, CSP
> Digia Plc., Finland
>
> > Hi All,
> >
> > I have recently started working as a coach with a team that has
> > primarily been using Scrum. They have an established backlog which
> > includes a number of technical features. I believe that this is
> > ligitimate in Scrum. The problem we are having is getting firm
> > ownership of the backlog. From the customers point of view, the
> > backlog is a "to do list" for the development team. If I say that the
> > team have been going for 18 months and is planning on delivering it's
> > first release in the next two months then you'll get the picture :)
> >
> > So the customer doesn't feel that he owns the backlog. He is just
> > waiting for his realse, waterfall style. This feeling is reinforced by
> > technical features in the backlog that are created by the lead
> > architect, and assigned priority based on his advice, and which
> > clearly do not belong to the customer.
> >
> > How does this work in a Scrum team.? My experience is XP.
> >
> > Regards,
> >
> > Paul.
>

Hi David,


I believe that in order to have this "leap of faith", you need to
change the perspective from "how you can instill the belief" to "what
do the developers need for the commitment". I believe "faith" is
merely "belief in the ability to meet the goal." Commitment and faith
are interchangeable in this case. You can help in that realization,
though.

I believe that the only way to create commitment is to create an
environment where people can self-motivate themselves. One training I
was involved in trained it something like this:

Motivation is an internal state for a desire to achieve something. The
key elements of potentially becoming committed are -
- Perception of the goal and its importance to something the person
values (in this case, the company).
- Perception of the meaning of this goal to oneself (what's in it for
the developers, internal motives).
- A feasible, observed path to the goal
- Belief in one's ability to achieve the goal

Based on your comments, I believe the first point should be about
clear for all involved people. It may be that the rest are still up in
the air.

So what can you do to address the last three?

It could be that the project would mean loads of overtime (or at least
people could be afraid of that) or it would mean changes to summer
plans. Does it? If it does, what are the personal gains to balance the
"cost"? Can the project run late and the people will then be working
two extra months really hard "because it should've been ready already"?

Does the project advance the interests of the developers in some other
way?

Do the developers perceive that the goal is achievable? Is it? Really,
I mean. Or is it "I think we can do it". If it is impossible to feel
confident about that now, what can we do in short term to increase our
perception of the solution and its feasibility? You said that the
competence should be there, but you have to help the team see it in
relation to the way to the target.

Your description of the project sounds like a risky business. There
are big unknowns. Can you eliminate them? What can you do to reduce
the uncertainty or impact? I don't think it's a wonder your developers
(who, in the end, will have to build it or face the consequences) feel
hesitant.

One thing I see possible to try is to discuss and set a mid-term goal
to which the team _can_ commit to. For example, "can we have this and
that figured out in two weeks?" If "this and that" is one of the core
risks, solving it in two weeks will help them see how they can achieve
the ultimate goal. This will allow the people to postpone the final
commitment and give them something to reach that does meet the
criteria I suggested above. I think this is one of the things that
make Scrum so powerful in general - perceptible, achievable goals.

As to monetary incentives, they tend to make people work harder, not
smarter. Try to find ones that instill desire to do smart things. I
believe they will yield much better end result. This is not McDonalds
where only the quantity really counts.

Hope this helps, and good luck for the whole team!


Yours, Petri


Petri Heiramo
Senior Process Improvement Manager, CSP
Digia Plc., Finland

--- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...> wrote:
>
> Dear practitioners.
>
> I am in a somewhat awkward position. While the company I am working
> for is very successful and recently has one a rather awesome new
> customer, capable of literally transforming the future of said
> company, I am still left with an environment which seems to be unsure
> of itself. Without going into to much detail I will explain the
> situation in its utter simplicity.
>
> a) New customer, trusts us, very happy to work with us, but an utterly
> tight deadline end of August. Customer has an existing (very simple)
> web-site which needs to be "cloned" on our platform.
> b) Customer is willing to negotiate on what can be done, they much
> rather have "a business" at the end of August than not having any
> business at all.
> c) The middle ware platform we would ideally like to port this to is
> not fully there yet, however many think it is achievable.
>
> There have been many discussions around risk reduction, a plan B is in
> effect and there is no reason to believe whatsoever that the people
> needing to deliver this were not involved. The teams have been
> repeatedly asked about scope, they esitimated, they raised concerned
> etc etc.
>
> I strongly believe that everything has been done to consult the people
> that need to commit to the work and I believe that the business side
> of things has always said "tell us what is doable and we will
> negotiate with them".
>
> However to me this is a matter of belief now. This is more about
> conviction that we can achieve this and it is something that is not
> quantifiable. When General Meng Tian was tasked to build a wall "8
> foot high and 3000 miles long" around China he must have somehow
> developed that faith and made some of his helpers see, when President
> Kennedy asked to put a man on the moon within 7 years, some NASA
> engineers must have developed that faith.
>
> While I know a lot about human psychology and the motivational tools
> we can utilise to make those around us feel at ease with a task at
> hand, I know little about faith. I do not believe in a God, I do not
> have ea religion, most of the things I believe in are driven by cold
> hard facts. However, in this very case, to rise above and beyond
> themselves I believe the people on the floor need to have "faith". My
> question is a simple one. How can I help foster an environment which
> allows room for believing and taking the risk to believe.
>
> Thank you
>
> -d
>
>
> --
> Sent from gmail so do not trust this communication.
> Do not send me sensitive information here, ask for my none-gmail
accounts.
>
> "Therefore the considerations of the intelligent always include both
> benefit and harm." - Sun Tzu
>

Well Andreas

I am in a similar situation, if you want to give me a shout off the
list then we can probably have a more in depth chat and share our
findings with everyone else./

-d


--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Hi Andreas,

Electronic Arts did a presentation at the UK Scrum Gathering. I missed
most of it as I was on the phone to a headhunter at the time. (whoops)

There maybe some information on it, at the SA main site. The
presentations normally get placed there. (Having said that, if you are
from EA that probably won't help!)

Regards,

Nigel Baker
Agile Coach
CST


--- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...> wrote:
>
> Well Andreas
>
> I am in a similar situation, if you want to give me a shout off the
> list then we can probably have a more in depth chat and share our
> findings with everyone else./
>
> -d
>
>
> --
> Sent from gmail so do not trust this communication.
> Do not send me sensitive information here, ask for my none-gmail
accounts.
>
> "Therefore the considerations of the intelligent always include both
> benefit and harm." - Sun Tzu
>

On Mon, Jun 2, 2008 at 5:15 PM, Megan Brown <mbrown@...> wrote:
>
--------------------------------------------------------------------------------\
----
> BETTER SOFTWARE  MAGAZINE JUNE 2008 FEATURE ARTICLE
>
--------------------------------------------------------------------------------\
----
> Agile Model-Driven Development
> Scaling Agile to Meet the Needs of Real-World Projects
> By Scott Ambler and Celso Gonzalez
>
sigh....

Could we please put a [ANN] Tag in such postions so my filter catches
them? That would be very nice. Thank you very much

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Joe,

> Jeff Sutherland says that Scrum was built to increase productivity
> 5x to 10x.

I believe it can. I'd like to suggest this is necessary but not
sufficient. To be sufficient I'd like to hear more about the
environment and team composition. I once worked with a team built by
the "you 5 people are now a team and we'll be using Scrum" method. To
make team dynamics more interesting one person was remotely located in
upstate New York with the rest of the team in California. Oh, and the
three most senior people had prior responsibilities that didn't go
away when the team ?formed?. I worked with this team from the sprint 2
retrospective (demo crashed and burned) through sprint 7 (or so). They
went from abysmal results to getting close to finishing the sprint
backlog. The ScrumMaster who followed me told me somewhere around
sprint 10 he saw some team like behavior.

> We need to (figuratively) grab management by the collar and say: We
> ain't doing business as usual any more!  We're serious. You have to
> help us knock down the impediments.

Could we say "Scrum is capable of increasing a team's productivity
between 5x and 10x. How much improvement your teams achieve is based
on how much you support the change including appropriate training,
changes in the team environment and engineering practices. You decide
how much additional value you'd like to generate."

--
Don (336)374-7591

The greatest discovery of my generation is that a human being can alter his life
by altering his attitudes of mind.
William James

Change your attitude by attending the AYE Conference Nov 2 - 5, 2008
www.AYEconference.com

--- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
<ken.schwaber@...> wrote:
   Cutting to chase of my comments
>
> 4. Monitor the team's progress, to make sure they stay on
schedule, and isn't having problems
>
> Ken
>

Ken I can see the other 8 items in your list as being the "right" way
to do things.  I am not sure about number 4 above.  At least not the
way we are doing Scrum.

As SM I am weekly required to report to a team of other managers and
a VP of IT, where the team is, are they on target to reach the
deliverable at the end of the time box, and if I am having any
problems removing obstacles/diverting outside distractions/or having
enough resources for the team to do the job.

To do this I monitor the number of Tasks in the Sprint, the number of
uncompleted tasks, the actual burn-down verses project burn-down, and
the Obstacles the team has brought up that I, the SM, need to clear
out of their path.

Why wouldn't this be the SM job?  Is it wrong for
Management, "Chickens" that they are, should as the SM for this sort
of report for their planning purposes.  I do not see the team really
do this for themselves.

>
> As SM I am weekly required to report to a team of other managers and
> a VP of IT, where the team is, are they on target to reach the
> deliverable at the end of the time box, and if I am having any
> problems removing obstacles/diverting outside distractions/or having
> enough resources for the team to do the job.
>
Why? Is there any reason whatsoever why they cannot get to that
information themselves?

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Hi all,

I sent a call for participation to the group last week with respect to a short (5-10mins)online survey I am conducting for doctoral and practitioner research. This is a second call (plea, beg, desperate call – please help!) for participate in this research, to provide some enlightenment as to the types organisations that adopt agile methods such as SCRUM. The survey should only take 5-10mins of your time and can be found here:

http://ou1211237011.agile-adoption.sgizmo.com

This is NOT a marketing survey and is used for doctoral and practitioner research purposes. I myself have worked in the software industry for over 15 years, and I believe this research could provide some significant findings with respect the types of organisation more conducive to adopting agile methods. And of course, these findings will be shared with the group, if enough responses are returned.

If you seek further evidence of my purposes please find my name at the Maths and Computing department at the Open University, UK.

Your participation is greatly appreciated, so please join in.

Thanks,
Ant Grinyer

-----
Senior Business Analyst (Cegedim UK Pharmaceutical Solutions)
Part-time doctoral candidate (The Open University)

Hi Joe,

Joseph Little wrote:
> We need to (figuratively) grab management by the collar and say: We
> ain't doing business as usual any more!  We're serious. You have to
> help us knock down the impediments.

It seems like you know or have an idea of what the improvements can lead
to. At least, you seem rather confident that you can have a significant
improvement in the organization by helping the teams have the courage to
remove impediments.

To steal a little from Paul's reply - I'm picturing the following
scenario. Let's say I have dinner with the CTO, and he is sold on Scrum.
I mean, he really gets it. Now you are talking with the managers, and
telling them you are going to increase velocity, or improve the team,
etc, etc. They know there is executive buy-in, but other than keeping
their jobs, what is the incentive for them to jump in?

It would seem like answering that question would give you the figurative
collar grabbing mechanism. But as you know, it's a mechanism that
requires respect and a light hand.

(I've done this twice on teams where the manager was the cause of or was
the impediment. By removing emotion (but not passion!) and showing
improvements, and timelines for improvements, I was able to make it
work. In one case, we started under the radar, so had some concrete
numbers to show, but in both cases the managers took it personally - as
I would expect many of us would.)

--
Cory Foy
http://www.cornetdesign.com