Hello, Kurt.  On Thursday, July 30, 2009, at 11:13:32 PM, you
wrote:

>> Have you tried pairing developers?

> Not so much, but we will be starting a pairing experiment soon.

Could make a big difference helping the "new guy".

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you don't have the courage to say what you think,
there isn't much use in thinking it, is there?
   --Thomas Jay Peckish II

Well, I think that people are always doing their best, so for me
commitment means "this looks reasonable to us. Let's go" and then
everybody tries to do what scrum requires of them... this includes
sustainable pace, the values, etc

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Ilja Preuß wrote:
>
>
> 2009/7/31 Michael James <michael@...
> <mailto:michael%40danube.com>>:
> > On Jul 31, 2009, at 11:44 AM, Ilja Preuß wrote:
> >> Personally, I like "I will do my best to meet it, and as soon as it
> >> becomes clear that I can't, I will communicate it."
> >
> > I like that.  I might add "while working a healthy, sustainable pace,"
> > as "my/our best" could be seen as a blank check.
>
> Well, yeah - for me, that's implied by "my best", but I can see how it
> wouldn't be for everyone.
>
> Cheers, Ilja
>
>

Read my latest post - coping with change on infoq

http://www.infoq.com/articles/coping-with-change

Hope this helps
Jack
www.agilebuddy.com
blog.agilebuddy.com
twitter.com/agilebuddy

--- In scrumdevelopment@yahoogroups.com, Mattias Skarin <mattias.skarin@...>
wrote:
>
>  > Mattias, what things are you doing to help the PM->PO transition?
>
> 1- make teams self organize (remove this as a focus for the old PM's).
> Don't know why, but they didn't let go until we had working scrum
> masters in all teams.
> 2. Teach PM's some basic lean things, like faster deliver with fewer
> concurrent projects
> 3. Ask what they liked to do. Customer visionary? Testing? Solve problems?
> -> Both PM's wanted to deal with customer..
> 4. Coach them in thinking ahead of the customer (
> Make them state what users will like about the products & help them find
> that out. For example by design a product wrapper. Have them identify
> one thing the customer have not thought of yet (but would like).
>
> Step 1 is almost complete after 8 weeks. Beginning step 4. Time will
> tell if it works :-)
>
> /Mattias
>

I love what you wrote, especially about the principles and values of
scrum, but I disagree with all of your constraints :)

     * work committed at the beginning of a sprint must have value to the
       customer or user - I disagree. There are many sorts of value.
       Scrum is silent on which ones to use. All you know is that the PO
       prioritized it

     * work committed at the beginning of a sprint must be finished at
       the end of the sprint. - I disagree. There is a commitment. It is
       unclear what that commitment means. If there is pressure to finish
       nomatter what, technical debt and unsustainable pace naturally
       follow. So, again, what do you value?

     * the team must complete the work according to a formal definition
       of done - I nearly agree.I only disagree with the word "formal"
       here. I say "agreed to" definition of done

The main think I know about scrum is once you get past the basics of
"inspect and adapt" for both your product and process, virtually
everything is malleable. That's on purpose, I think, because the purpose
is to maximize what your organization values, whatever that is.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Peter Stevens (cal) wrote:
>
>
> Hi Adam,
>
> That's the problem with any self-reporting and lack of branding. What
> the asker of a question means with the question and how the respondent
> interprets the question can be two entirely different things.
>
> At last year's Agile Business Conference in London, keynote speaker
> Rob Thomsett defined Agile as a set of values, not as a set of
> practices: Openness, Trust, Honesty, Courage and Fiscal
> Responsibility. So projects using everything from Scrum to XP to DSDM
> to RUP could claim to be Agile.
>
> I conducted a poll last summer asking the 8 questions of the Nokia
> test. "Is anybody really doing Scrum
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>?"
> 3/4th of the respondents scored 7 or less. Because of the tool used to
> collect the data, I couldn't tell how many satisfied Nokia's
> definition of Agile (First 3 questions). The number of respondents was
> also rather small -- 47 -- so one might question how representative
> this poll was. Since then, Robin Dymond has been started a project to
> get 1000 respondents to answer an extended version of the test. Last I
> heard, he had 360 respondents, so he hasn't published any results yet.
>
> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
> of tilllate.com, described his company's getting started with Scrum.
> When he started, he didn't believe that Scrum would work in his
> company, so he changed it. Pretty dramatically. For instance, time
> boxes yes, fixed length iterations no. At the beginning of his talk, I
> wondered if we could even call his process Scrum. He definitely broke
> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
> process brought him closer to Scrum by the book (adding
> retrospectives, daily scrums, ready to try again with fixed length
> iterations, etc).
>
> The talk was a real eye opener. If your top management gets the
> principles of Scrum, the practices are less of an issue. If they
> don't, well, it can be tough.
>
> Scrum doesn't actually specify any engineering practices. It specifies
> three constraints:
>
>     * work committed at the beginning of a sprint must have value to
>       the customer or user
>     * work committed at the beginning of a sprint must be finished at
>       the end of the sprint.
>     * the team must complete the work according to a formal definition
>       of done
>
> These constraints drive most teams to move towards XP engineering
> practices (even though there is no requirement to do so).  I am not
> aware of any evidence which shows that doing agile engineering leads
> companies to adopt agile management practices, so Scrum is the place
> to start.
>
> So, coming back to your original post, I think you've got the numbers
> and messages you need:
>
>    1. > 50% of all IT projects are doing (or trying to do) agile.
>    2. 84% of them do (or are trying to do) Scrum -- and this is the
>       place to start.
>    3. Scrum is hard, so management buy in and commitment are essential.
>
> Now it's time for management to self organize: "How do you convince
> yourselves the Scrum and Agile are worthy of serious commitment? How
> do you learn to walk the walk?"
>
> Cheers,
>
> Peter
>
>
>
> Adam Sroka wrote:
>> Ken's numbers match my experience, but I wonder how many of those 84%
>> are doing some kind of Scrum-but with absolutely none of the Agile
>> "engineering practices." And, of those who claim to be doing some form
>> of Agile that isn't Scrum, I wonder how many are actually doing
>> anything that would remotely resemble Agile to you or I.
>>
>> Also, as an aside, I've noticed that nearly every job description now
>> says "Experience with agile methodologies - especially Scrum or XP -
>> is desirable," or something quite similar. It makes using the job
>> boards more difficult, because nine out of ten of the results for
>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
>>
>
>

Mattias Skarin wrote:
>  > Mattias, what things are you doing to help the PM->PO transition?
>
> 1- make teams self organize (remove this as a focus for the old PM's).
> Don't know why, but they didn't let go until we had working scrum
> masters in all teams.

How do (did) you do this?

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

On Fri, Jul 31, 2009 at 9:47 AM, Dan
Rawsthorne<dan.rawsthorne@...> wrote:
> I love what you wrote, especially about the principles and values of
> scrum, but I disagree with all of your constraints :)
>
>    * work committed at the beginning of a sprint must have value to the
>      customer or user - I disagree. There are many sorts of value.
>      Scrum is silent on which ones to use. All you know is that the PO
>      prioritized it
>

The focus on *Customer* value is part of what makes it Agile (See
Manifesto). It is true that Scrum doesn't say we have to focus on
customer value per se. Thus, it might be possible to be doing Scrum
and not doing Agile Software Development. That's fine, but I think you
need to be explicit about it. There are too many teams who think that
what they are doing is Agile but it is not, and they don't really have
any idea why.

>    * work committed at the beginning of a sprint must be finished at
>      the end of the sprint. - I disagree. There is a commitment. It is
>      unclear what that commitment means. If there is pressure to finish
>      nomatter what, technical debt and unsustainable pace naturally
>      follow. So, again, what do you value?
>

I suppose the "no matter what" part is problematic. Certainly we may
feel the need to inspect-and-adapt during the Sprint, and that should
be okay. However, shouldn't we at least be making an honest attempt to
commit to what we thing we can do and then do it? (Absent unforeseen
external pressures.)

>    * the team must complete the work according to a formal definition
>      of done - I nearly agree.I only disagree with the word "formal"
>      here. I say "agreed to" definition of done
>

+1

> The main think I know about scrum is once you get past the basics of
> "inspect and adapt" for both your product and process, virtually
> everything is malleable. That's on purpose, I think, because the purpose
> is to maximize what your organization values, whatever that is.
>
> Dan Rawsthorne, PhD, CST
> Senior Coach, Danube Technologies
> dan@..., 425-269-8628
>
>
>
> Peter Stevens (cal) wrote:
>>
>>
>> Hi Adam,
>>
>> That's the problem with any self-reporting and lack of branding. What
>> the asker of a question means with the question and how the respondent
>> interprets the question can be two entirely different things.
>>
>> At last year's Agile Business Conference in London, keynote speaker
>> Rob Thomsett defined Agile as a set of values, not as a set of
>> practices: Openness, Trust, Honesty, Courage and Fiscal
>> Responsibility. So projects using everything from Scrum to XP to DSDM
>> to RUP could claim to be Agile.
>>
>> I conducted a poll last summer asking the 8 questions of the Nokia
>> test. "Is anybody really doing Scrum
>>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>?"
>> 3/4th of the respondents scored 7 or less. Because of the tool used to
>> collect the data, I couldn't tell how many satisfied Nokia's
>> definition of Agile (First 3 questions). The number of respondents was
>> also rather small -- 47 -- so one might question how representative
>> this poll was. Since then, Robin Dymond has been started a project to
>> get 1000 respondents to answer an extended version of the test. Last I
>> heard, he had 360 respondents, so he hasn't published any results yet.
>>
>> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
>> of tilllate.com, described his company's getting started with Scrum.
>> When he started, he didn't believe that Scrum would work in his
>> company, so he changed it. Pretty dramatically. For instance, time
>> boxes yes, fixed length iterations no. At the beginning of his talk, I
>> wondered if we could even call his process Scrum. He definitely broke
>> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
>> process brought him closer to Scrum by the book (adding
>> retrospectives, daily scrums, ready to try again with fixed length
>> iterations, etc).
>>
>> The talk was a real eye opener. If your top management gets the
>> principles of Scrum, the practices are less of an issue. If they
>> don't, well, it can be tough.
>>
>> Scrum doesn't actually specify any engineering practices. It specifies
>> three constraints:
>>
>>     * work committed at the beginning of a sprint must have value to
>>       the customer or user
>>     * work committed at the beginning of a sprint must be finished at
>>       the end of the sprint.
>>     * the team must complete the work according to a formal definition
>>       of done
>>
>> These constraints drive most teams to move towards XP engineering
>> practices (even though there is no requirement to do so).  I am not
>> aware of any evidence which shows that doing agile engineering leads
>> companies to adopt agile management practices, so Scrum is the place
>> to start.
>>
>> So, coming back to your original post, I think you've got the numbers
>> and messages you need:
>>
>>    1. > 50% of all IT projects are doing (or trying to do) agile.
>>    2. 84% of them do (or are trying to do) Scrum -- and this is the
>>       place to start.
>>    3. Scrum is hard, so management buy in and commitment are essential.
>>
>> Now it's time for management to self organize: "How do you convince
>> yourselves the Scrum and Agile are worthy of serious commitment? How
>> do you learn to walk the walk?"
>>
>> Cheers,
>>
>> Peter
>>
>>
>>
>> Adam Sroka wrote:
>>> Ken's numbers match my experience, but I wonder how many of those 84%
>>> are doing some kind of Scrum-but with absolutely none of the Agile
>>> "engineering practices." And, of those who claim to be doing some form
>>> of Agile that isn't Scrum, I wonder how many are actually doing
>>> anything that would remotely resemble Agile to you or I.
>>>
>>> Also, as an aside, I've noticed that nearly every job description now
>>> says "Experience with agile methodologies - especially Scrum or XP -
>>> is desirable," or something quite similar. It makes using the job
>>> boards more difficult, because nine out of ten of the results for
>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
>>>
>>
>>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...! Groups Links
>
>
>
>

I like the analogy, selling Scrum is similar to visiting a doctor. You need to
communicate the advantages and the risks associated as well.

Senior Managers will always ask for risks and things that could go wrong. Most
of the time they're just checking with you if you're fully aware of the possible
short comings of what you're proposing.

Maybe even hard data about Scrum adoption can help you, I've seen a separate
thread on this forum related to that.

Regards,

Juan

I am not sure I buy the comment that you can be doing Scrum and not be doing
Agile Software Development.

Jack
blog.agilebuddy.com
www.agilebuddy.com
twitter.com/agilebuddy


--- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
>
> On Fri, Jul 31, 2009 at 9:47 AM, Dan
> Rawsthorne<dan.rawsthorne@...> wrote:
> > I love what you wrote, especially about the principles and values of
> > scrum, but I disagree with all of your constraints :)
> >
> > � �* work committed at the beginning of a sprint must have value to the
> > � � �customer or user - I disagree. There are many sorts of value.
> > � � �Scrum is silent on which ones to use. All you know is that the PO
> > � � �prioritized it
> >
>
> The focus on *Customer* value is part of what makes it Agile (See
> Manifesto). It is true that Scrum doesn't say we have to focus on
> customer value per se. Thus, it might be possible to be doing Scrum
> and not doing Agile Software Development. That's fine, but I think you
> need to be explicit about it. There are too many teams who think that
> what they are doing is Agile but it is not, and they don't really have
> any idea why.
>
> > � �* work committed at the beginning of a sprint must be finished at
> > � � �the end of the sprint. - I disagree. There is a commitment. It is
> > � � �unclear what that commitment means. If there is pressure to
finish
> > � � �nomatter what, technical debt and unsustainable pace naturally
> > � � �follow. So, again, what do you value?
> >
>
> I suppose the "no matter what" part is problematic. Certainly we may
> feel the need to inspect-and-adapt during the Sprint, and that should
> be okay. However, shouldn't we at least be making an honest attempt to
> commit to what we thing we can do and then do it? (Absent unforeseen
> external pressures.)
>
> > � �* the team must complete the work according to a formal definition
> > � � �of done - I nearly agree.I only disagree with the word "formal"
> > � � �here. I say "agreed to" definition of done
> >
>
> +1
>
> > The main think I know about scrum is once you get past the basics of
> > "inspect and adapt" for both your product and process, virtually
> > everything is malleable. That's on purpose, I think, because the purpose
> > is to maximize what your organization values, whatever that is.
> >
> > Dan Rawsthorne, PhD, CST
> > Senior Coach, Danube Technologies
> > dan@..., 425-269-8628
> >
> >
> >
> > Peter Stevens (cal) wrote:
> >>
> >>
> >> Hi Adam,
> >>
> >> That's the problem with any self-reporting and lack of branding. What
> >> the asker of a question means with the question and how the respondent
> >> interprets the question can be two entirely different things.
> >>
> >> At last year's Agile Business Conference in London, keynote speaker
> >> Rob Thomsett defined Agile as a set of values, not as a set of
> >> practices: Openness, Trust, Honesty, Courage and Fiscal
> >> Responsibility. So projects using everything from Scrum to XP to DSDM
> >> to RUP could claim to be Agile.
> >>
> >> I conducted a poll last summer asking the 8 questions of the Nokia
> >> test. "Is anybody really doing Scrum
> >>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>?"
> >> 3/4th of the respondents scored 7 or less. Because of the tool used to
> >> collect the data, I couldn't tell how many satisfied Nokia's
> >> definition of Agile (First 3 questions). The number of respondents was
> >> also rather small -- 47 -- so one might question how representative
> >> this poll was. Since then, Robin Dymond has been started a project to
> >> get 1000 respondents to answer an extended version of the test. Last I
> >> heard, he had 360 respondents, so he hasn't published any results yet.
> >>
> >> The speaker at last month's the Scrum Breakfast, Silvan M�hlemann, CTO
> >> of tilllate.com, described his company's getting started with Scrum.
> >> When he started, he didn't believe that Scrum would work in his
> >> company, so he changed it. Pretty dramatically. For instance, time
> >> boxes yes, fixed length iterations no. At the beginning of his talk, I
> >> wondered if we could even call his process Scrum. He definitely broke
> >> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
> >> process brought him closer to Scrum by the book (adding
> >> retrospectives, daily scrums, ready to try again with fixed length
> >> iterations, etc).
> >>
> >> The talk was a real eye opener. If your top management gets the
> >> principles of Scrum, the practices are less of an issue. If they
> >> don't, well, it can be tough.
> >>
> >> Scrum doesn't actually specify any engineering practices. It specifies
> >> three constraints:
> >>
> >> � � * work committed at the beginning of a sprint must have value to
> >> � � � the customer or user
> >> � � * work committed at the beginning of a sprint must be finished at
> >> � � � the end of the sprint.
> >> � � * the team must complete the work according to a formal definition
> >> � � � of done
> >>
> >> These constraints drive most teams to move towards XP engineering
> >> practices (even though there is no requirement to do so). �I am not
> >> aware of any evidence which shows that doing agile engineering leads
> >> companies to adopt agile management practices, so Scrum is the place
> >> to start.
> >>
> >> So, coming back to your original post, I think you've got the numbers
> >> and messages you need:
> >>
> >> � �1. > 50% of all IT projects are doing (or trying to do) agile.
> >> � �2. 84% of them do (or are trying to do) Scrum -- and this is the
> >> � � � place to start.
> >> � �3. Scrum is hard, so management buy in and commitment are essential.
> >>
> >> Now it's time for management to self organize: "How do you convince
> >> yourselves the Scrum and Agile are worthy of serious commitment? How
> >> do you learn to walk the walk?"
> >>
> >> Cheers,
> >>
> >> Peter
> >>
> >>
> >>
> >> Adam Sroka wrote:
> >>> Ken's numbers match my experience, but I wonder how many of those 84%
> >>> are doing some kind of Scrum-but with absolutely none of the Agile
> >>> "engineering practices." And, of those who claim to be doing some form
> >>> of Agile that isn't Scrum, I wonder how many are actually doing
> >>> anything that would remotely resemble Agile to you or I.
> >>>
> >>> Also, as an aside, I've noticed that nearly every job description now
> >>> says "Experience with agile methodologies - especially Scrum or XP -
> >>> is desirable," or something quite similar. It makes using the job
> >>> boards more difficult, because nine out of ten of the results for
> >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
> >>>
> >>
> >>
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to: � scrumdevelopment@...
> > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...!
Groups Links
> >
> >
> >
> >
>

Response 1: But scrum isn't about Agilily, it's about agility. I think
that most teams should value the Agile Manifesto (and other stuff, as
I've posted before), but it's not part of scrum. Scrum isn't restricted
to software, after all :)

Response 2: This is an interesting question, and is the reason kanban's
WIP is gaining traction. The force (in a patterns sense) of commitment
often leads to bad stuff. Scrum requires commitment, but is largely
silent on what that means. I'd like to have a 2-3 hour discussion on
this sometime, just to see if there some "there" there.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Adam Sroka wrote:
>
>
> On Fri, Jul 31, 2009 at 9:47 AM, Dan
> Rawsthorne<dan.rawsthorne@...
> <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
> > I love what you wrote, especially about the principles and values of
> > scrum, but I disagree with all of your constraints :)
> >
> >    * work committed at the beginning of a sprint must have value to the
> >      customer or user - I disagree. There are many sorts of value.
> >      Scrum is silent on which ones to use. All you know is that the PO
> >      prioritized it
> >
>
> The focus on *Customer* value is part of what makes it Agile (See
> Manifesto). It is true that Scrum doesn't say we have to focus on
> customer value per se. Thus, it might be possible to be doing Scrum
> and not doing Agile Software Development. That's fine, but I think you
> need to be explicit about it. There are too many teams who think that
> what they are doing is Agile but it is not, and they don't really have
> any idea why.
>
> >    * work committed at the beginning of a sprint must be finished at
> >      the end of the sprint. - I disagree. There is a commitment. It is
> >      unclear what that commitment means. If there is pressure to finish
> >      nomatter what, technical debt and unsustainable pace naturally
> >      follow. So, again, what do you value?
> >
>
> I suppose the "no matter what" part is problematic. Certainly we may
> feel the need to inspect-and-adapt during the Sprint, and that should
> be okay. However, shouldn't we at least be making an honest attempt to
> commit to what we thing we can do and then do it? (Absent unforeseen
> external pressures.)
>
> >    * the team must complete the work according to a formal definition
> >      of done - I nearly agree.I only disagree with the word "formal"
> >      here. I say "agreed to" definition of done
> >
>
> +1
>
> > The main think I know about scrum is once you get past the basics of
> > "inspect and adapt" for both your product and process, virtually
> > everything is malleable. That's on purpose, I think, because the purpose
> > is to maximize what your organization values, whatever that is.
> >
> > Dan Rawsthorne, PhD, CST
> > Senior Coach, Danube Technologies
> > dan@... <mailto:dan%40danube.com>, 425-269-8628
> >
> >
> >
> > Peter Stevens (cal) wrote:
> >>
> >>
> >> Hi Adam,
> >>
> >> That's the problem with any self-reporting and lack of branding. What
> >> the asker of a question means with the question and how the respondent
> >> interprets the question can be two entirely different things.
> >>
> >> At last year's Agile Business Conference in London, keynote speaker
> >> Rob Thomsett defined Agile as a set of values, not as a set of
> >> practices: Openness, Trust, Honesty, Courage and Fiscal
> >> Responsibility. So projects using everything from Scrum to XP to DSDM
> >> to RUP could claim to be Agile.
> >>
> >> I conducted a poll last summer asking the 8 questions of the Nokia
> >> test. "Is anybody really doing Scrum
> >>
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>>?"
> >> 3/4th of the respondents scored 7 or less. Because of the tool used to
> >> collect the data, I couldn't tell how many satisfied Nokia's
> >> definition of Agile (First 3 questions). The number of respondents was
> >> also rather small -- 47 -- so one might question how representative
> >> this poll was. Since then, Robin Dymond has been started a project to
> >> get 1000 respondents to answer an extended version of the test. Last I
> >> heard, he had 360 respondents, so he hasn't published any results yet.
> >>
> >> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
> >> of tilllate.com, described his company's getting started with Scrum.
> >> When he started, he didn't believe that Scrum would work in his
> >> company, so he changed it. Pretty dramatically. For instance, time
> >> boxes yes, fixed length iterations no. At the beginning of his talk, I
> >> wondered if we could even call his process Scrum. He definitely broke
> >> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
> >> process brought him closer to Scrum by the book (adding
> >> retrospectives, daily scrums, ready to try again with fixed length
> >> iterations, etc).
> >>
> >> The talk was a real eye opener. If your top management gets the
> >> principles of Scrum, the practices are less of an issue. If they
> >> don't, well, it can be tough.
> >>
> >> Scrum doesn't actually specify any engineering practices. It specifies
> >> three constraints:
> >>
> >>     * work committed at the beginning of a sprint must have value to
> >>       the customer or user
> >>     * work committed at the beginning of a sprint must be finished at
> >>       the end of the sprint.
> >>     * the team must complete the work according to a formal definition
> >>       of done
> >>
> >> These constraints drive most teams to move towards XP engineering
> >> practices (even though there is no requirement to do so).  I am not
> >> aware of any evidence which shows that doing agile engineering leads
> >> companies to adopt agile management practices, so Scrum is the place
> >> to start.
> >>
> >> So, coming back to your original post, I think you've got the numbers
> >> and messages you need:
> >>
> >>    1. > 50% of all IT projects are doing (or trying to do) agile.
> >>    2. 84% of them do (or are trying to do) Scrum -- and this is the
> >>       place to start.
> >>    3. Scrum is hard, so management buy in and commitment are essential.
> >>
> >> Now it's time for management to self organize: "How do you convince
> >> yourselves the Scrum and Agile are worthy of serious commitment? How
> >> do you learn to walk the walk?"
> >>
> >> Cheers,
> >>
> >> Peter
> >>
> >>
> >>
> >> Adam Sroka wrote:
> >>> Ken's numbers match my experience, but I wonder how many of those 84%
> >>> are doing some kind of Scrum-but with absolutely none of the Agile
> >>> "engineering practices." And, of those who claim to be doing some form
> >>> of Agile that isn't Scrum, I wonder how many are actually doing
> >>> anything that would remotely resemble Agile to you or I.
> >>>
> >>> Also, as an aside, I've noticed that nearly every job description now
> >>> says "Experience with agile methodologies - especially Scrum or XP -
> >>> is desirable," or something quite similar. It makes using the job
> >>> boards more difficult, because nine out of ten of the results for
> >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
> >>>
> >>
> >>
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to:   scrumdevelopment@eGroups.com
> <mailto:scrumdevelopment%40eGroups.com>
> > To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...
> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
> >
> >
> >
> >
>
>

Well. since scrum isn't for software, how could you object to the
statement? By definition, scrum is "A team-based framework to develop
complex systems and products." It would be reasonable for you to say "I
think that when using scrum to develop software, it should be an Agile
Development," but I'd still disagree with you.

Scrum is for developing complex systems and products to meet
organizational goals and values. I agree that software organizations
*should* value the Agile Manifesto, as they *should* value delivering
value to customers, but it's certainly not required. The Agile Manifesto
is a moral statement, a statement of preferred values, and scrum is
merely a tool. Any team can use scrum to provide what its organization
values.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



jmilunsky wrote:
>
>
> I am not sure I buy the comment that you can be doing Scrum and not be
> doing Agile Software Development.
>
> Jack
> blog.agilebuddy.com
> www.agilebuddy.com
> twitter.com/agilebuddy
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, Adam Sroka
> <adam.sroka@...> wrote:
> >
> > On Fri, Jul 31, 2009 at 9:47 AM, Dan
> > Rawsthorne<dan.rawsthorne@...> wrote:
> > > I love what you wrote, especially about the principles and values of
> > > scrum, but I disagree with all of your constraints :)
> > >
> > > � �* work committed at the beginning of a sprint must have
> value to the
> > > � � �customer or user - I disagree. There are many sorts of
> value.
> > > � � �Scrum is silent on which ones to use. All you know is
> that the PO
> > > � � �prioritized it
> > >
> >
> > The focus on *Customer* value is part of what makes it Agile (See
> > Manifesto). It is true that Scrum doesn't say we have to focus on
> > customer value per se. Thus, it might be possible to be doing Scrum
> > and not doing Agile Software Development. That's fine, but I think you
> > need to be explicit about it. There are too many teams who think that
> > what they are doing is Agile but it is not, and they don't really have
> > any idea why.
> >
> > > � �* work committed at the beginning of a sprint must be
> finished at
> > > � � �the end of the sprint. - I disagree. There is a
> commitment. It is
> > > � � �unclear what that commitment means. If there is
> pressure to finish
> > > � � �nomatter what, technical debt and unsustainable pace
> naturally
> > > � � �follow. So, again, what do you value?
> > >
> >
> > I suppose the "no matter what" part is problematic. Certainly we may
> > feel the need to inspect-and-adapt during the Sprint, and that should
> > be okay. However, shouldn't we at least be making an honest attempt to
> > commit to what we thing we can do and then do it? (Absent unforeseen
> > external pressures.)
> >
> > > � �* the team must complete the work according to a formal
> definition
> > > � � �of done - I nearly agree.I only disagree with the word
> "formal"
> > > � � �here. I say "agreed to" definition of done
> > >
> >
> > +1
> >
> > > The main think I know about scrum is once you get past the basics of
> > > "inspect and adapt" for both your product and process, virtually
> > > everything is malleable. That's on purpose, I think, because the
> purpose
> > > is to maximize what your organization values, whatever that is.
> > >
> > > Dan Rawsthorne, PhD, CST
> > > Senior Coach, Danube Technologies
> > > dan@..., 425-269-8628
> > >
> > >
> > >
> > > Peter Stevens (cal) wrote:
> > >>
> > >>
> > >> Hi Adam,
> > >>
> > >> That's the problem with any self-reporting and lack of branding. What
> > >> the asker of a question means with the question and how the
> respondent
> > >> interprets the question can be two entirely different things.
> > >>
> > >> At last year's Agile Business Conference in London, keynote speaker
> > >> Rob Thomsett defined Agile as a set of values, not as a set of
> > >> practices: Openness, Trust, Honesty, Courage and Fiscal
> > >> Responsibility. So projects using everything from Scrum to XP to DSDM
> > >> to RUP could claim to be Agile.
> > >>
> > >> I conducted a poll last summer asking the 8 questions of the Nokia
> > >> test. "Is anybody really doing Scrum
> > >>
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>>?"
> > >> 3/4th of the respondents scored 7 or less. Because of the tool
> used to
> > >> collect the data, I couldn't tell how many satisfied Nokia's
> > >> definition of Agile (First 3 questions). The number of
> respondents was
> > >> also rather small -- 47 -- so one might question how representative
> > >> this poll was. Since then, Robin Dymond has been started a project to
> > >> get 1000 respondents to answer an extended version of the test.
> Last I
> > >> heard, he had 360 respondents, so he hasn't published any results
> yet.
> > >>
> > >> The speaker at last month's the Scrum Breakfast, Silvan
> M�hlemann, CTO
> > >> of tilllate.com, described his company's getting started with Scrum.
> > >> When he started, he didn't believe that Scrum would work in his
> > >> company, so he changed it. Pretty dramatically. For instance, time
> > >> boxes yes, fixed length iterations no. At the beginning of his
> talk, I
> > >> wondered if we could even call his process Scrum. He definitely broke
> > >> a lot of rules of Scrum. But he stayed true to inspect and adapt.
> That
> > >> process brought him closer to Scrum by the book (adding
> > >> retrospectives, daily scrums, ready to try again with fixed length
> > >> iterations, etc).
> > >>
> > >> The talk was a real eye opener. If your top management gets the
> > >> principles of Scrum, the practices are less of an issue. If they
> > >> don't, well, it can be tough.
> > >>
> > >> Scrum doesn't actually specify any engineering practices. It
> specifies
> > >> three constraints:
> > >>
> > >> � � * work committed at the beginning of a sprint must have
> value to
> > >> � � � the customer or user
> > >> � � * work committed at the beginning of a sprint must be
> finished at
> > >> � � � the end of the sprint.
> > >> � � * the team must complete the work according to a formal
> definition
> > >> � � � of done
> > >>
> > >> These constraints drive most teams to move towards XP engineering
> > >> practices (even though there is no requirement to do so). �I am not
> > >> aware of any evidence which shows that doing agile engineering leads
> > >> companies to adopt agile management practices, so Scrum is the place
> > >> to start.
> > >>
> > >> So, coming back to your original post, I think you've got the numbers
> > >> and messages you need:
> > >>
> > >> � �1. > 50% of all IT projects are doing (or trying to do) agile.
> > >> � �2. 84% of them do (or are trying to do) Scrum -- and this
> is the
> > >> � � � place to start.
> > >> � �3. Scrum is hard, so management buy in and commitment are
> essential.
> > >>
> > >> Now it's time for management to self organize: "How do you convince
> > >> yourselves the Scrum and Agile are worthy of serious commitment? How
> > >> do you learn to walk the walk?"
> > >>
> > >> Cheers,
> > >>
> > >> Peter
> > >>
> > >>
> > >>
> > >> Adam Sroka wrote:
> > >>> Ken's numbers match my experience, but I wonder how many of
> those 84%
> > >>> are doing some kind of Scrum-but with absolutely none of the Agile
> > >>> "engineering practices." And, of those who claim to be doing
> some form
> > >>> of Agile that isn't Scrum, I wonder how many are actually doing
> > >>> anything that would remotely resemble Agile to you or I.
> > >>>
> > >>> Also, as an aside, I've noticed that nearly every job
> description now
> > >>> says "Experience with agile methodologies - especially Scrum or XP -
> > >>> is desirable," or something quite similar. It makes using the job
> > >>> boards more difficult, because nine out of ten of the results for
> > >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
> > >>>
> > >>
> > >>
> > >
> > >
> > > ------------------------------------
> > >
> > > To Post a message, send it to: � scrumdevelopment@...
> > > To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...! Groups Links
> > >
> > >
> > >
> > >
> >
>
>

I love what you wrote, especially about the principles and values of scrum, but I disagree with all of your constraints :)
* work committed at the beginning of a sprint must have value to the
customer or user - I disagree. There are many sorts of value.
Scrum is silent on which ones to use. All you know is that the PO
prioritized it
* work committed at the beginning of a sprint must be finished at
the end of the sprint. - I disagree. There is a commitment. It is
unclear what that commitment means. If there is pressure to finish
nomatter what, technical debt and unsustainable pace naturally
follow. So, again, what do you value?
* the team must complete the work according to a formal definition
of done - I nearly agree.I only disagree with the word "formal"
here. I say "agreed to" definition of done
The main think I know about scrum is once you get past the basics of "inspect and adapt" for both your product and process, virtually everything is malleable. That's on purpose, I think, because the purpose is to maximize what your organization values, whatever that is.
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628
Peter Stevens (cal) wrote:

 Hi Adam,
That's the problem with any self-reporting and lack of branding. What the asker of a question means with the question and how the respondent interprets the question can be two entirely different things.
At last year's Agile Business Conference in London, keynote speaker Rob Thomsett defined Agile as a set of values, not as a set of practices: Openness, Trust, Honesty, Courage and Fiscal Responsibility. So projects using everything from Scrum to XP to DSDM to RUP could claim to be Agile.
I conducted a poll last summer asking the 8 questions of the Nokia test. "Is anybody really doing Scrum <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?" 3/4th of the respondents scored 7 or less. Because of the tool used to collect the data, I couldn't tell how many satisfied Nokia's definition of Agile (First 3 questions). The number of respondents was also rather small -- 47 -- so one might question how representative this poll was. Since then, Robin Dymond has been started a project to get 1000 respondents to answer an extended version of the test. Last I heard, he had 360 respondents, so he hasn't published any results yet.
The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO of tilllate.com, described his company's getting started with Scrum. When he started, he didn't believe that Scrum would work in his company, so he changed it. Pretty dramatically. For instance, time boxes yes, fixed length iterations no. At the beginning of his talk, I wondered if we could even call his process Scrum. He definitely broke a lot of rules of Scrum. But he stayed true to inspect and adapt. That process brought him closer to Scrum by the book (adding retrospectives, daily scrums, ready to try again with fixed length iterations, etc).
The talk was a real eye opener. If your top management gets the principles of Scrum, the practices are less of an issue. If they don't, well, it can be tough.
Scrum doesn't actually specify any engineering practices. It specifies three constraints:
* work committed at the beginning of a sprint must have value to
the customer or user
* work committed at the beginning of a sprint must be finished at
the end of the sprint.
* the team must complete the work according to a formal definition
of done
These constraints drive most teams to move towards XP engineering practices (even though there is no requirement to do so). I am not aware of any evidence which shows that doing agile engineering leads companies to adopt agile management practices, so Scrum is the place to start.
So, coming back to your original post, I think you've got the numbers and messages you need:
1. > 50% of all IT projects are doing (or trying to do) agile.
2. 84% of them do (or are trying to do) Scrum -- and this is the
place to start.
3. Scrum is hard, so management buy in and commitment are essential.
Now it's time for management to self organize: "How do you convince yourselves the Scrum and Agile are worthy of serious commitment? How do you learn to walk the walk?"
Cheers,
Peter
Adam Sroka wrote:

Ken's numbers match my experience, but I wonder how many of those 84%
are doing some kind of Scrum-but with absolutely none of the Agile
"engineering practices." And, of those who claim to be doing some form
of Agile that isn't Scrum, I wonder how many are actually doing
anything that would remotely resemble Agile to you or I.
Also, as an aside, I've noticed that nearly every job description now
says "Experience with agile methodologies - especially Scrum or XP -
is desirable," or something quite similar. It makes using the job
boards more difficult, because nine out of ten of the results for
"agile," "XP," and "Scrum," are false positives (For my purposes.)

------------------------------------
To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:scrumdevelopment-digest@yahoogroups.com mailto:scrumdevelopment-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

I want to be pedantic for a second. We're actually asking the question
"what do we do with *people* that have been trained to be PMs, the
*people* that have been trained to be BAs?" Right? We need to be precise
here. What does the PM do? Well, it's a role, so the PM manages
projects. Period. Or he/she is not a PM.

So, the opening statement below should be "we shouldn't assume Jill goes
to a customer-centric role just because she's been a PM, or has been
trained to be a PM, or whatever." Scrum focus on people, on the
self-organizing cross-functional team, right? So, stop talking about
roles and start talking about abilities... please.

Now, an aside. If you have a scrum project, and it has a PM (somebody
designated by the organizational to manage the project), that that
person is your PO. We can start a discussion about that, if you wish,
but that's a different discussion than the one we're having here, I think.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Kathy Adams wrote:
>
>
> We shouldn't assume the PM goes to a customer-centric role.  Some
> teams have Business Analysts who move in that direction.  Our projects
> tend to use out-sourced resources, so the PM is often doing the
> administrative work of contract negotiation, invoice management,
> vendor management, etc.  We also have recently trained our key user to
> be the product owner, leaving the BA to really own moving from user
> stories to deeper requirements and defining test criteria with the PO
> and managing or doing testing.
>
> PM's also tend to become the scrum master working on removing
> roadblocks.  Our team uses a usability expert, documentation writer,
> occasionally when available a QA person, so the PM is often
> busy negotiating for  those resources who aren't full time on our
> team.  It may not sounds like " classic " agile, but we are very
> successfull with remote and less than full-time resources, given a
> little extra effort on the part of the scrum master (PMP, ex-PM ) to
> make it all come together.
>
> Also,  learning to be a servant leader (scrum master) and learning
> team facilitation techniques are engaging activities to PM's who are
> ready to move to a deeper level of support for team.
>

Dan, I am glad you raised this, and I was right with you until the last
paragraph.  Can you say more about what you have in mind there?

-- Jean

Dan Rawsthorne wrote:

> I want to be pedantic for a second. We're actually asking the question
> "what do we do with *people* that have been trained to be PMs, the
> *people* that have been trained to be BAs?" Right? We need to be precise
> here. What does the PM do? Well, it's a role, so the PM manages
> projects. Period. Or he/she is not a PM.
>
> So, the opening statement below should be "we shouldn't assume Jill goes
> to a customer-centric role just because she's been a PM, or has been
> trained to be a PM, or whatever." Scrum focus on people, on the
> self-organizing cross-functional team, right? So, stop talking about
> roles and start talking about abilities... please.
>
> Now, an aside. If you have a scrum project, and it has a PM (somebody
> designated by the organizational to manage the project), that that
> person is your PO. We can start a discussion about that, if you wish,
> but that's a different discussion than the one we're having here, I think.
>
> Dan Rawsthorne, PhD, CST
> Senior Coach, Danube Technologies
> dan@..., 425-269-8628
>
>
>
> Kathy Adams wrote:
> >
> >
> > We shouldn't assume the PM goes to a customer-centric role.  Some
> > teams have Business Analysts who move in that direction.  Our projects
> > tend to use out-sourced resources, so the PM is often doing the
> > administrative work of contract negotiation, invoice management,
> > vendor management, etc.  We also have recently trained our key user to
> > be the product owner, leaving the BA to really own moving from user
> > stories to deeper requirements and defining test criteria with the PO
> > and managing or doing testing.
> >
> > PM's also tend to become the scrum master working on removing
> > roadblocks.  Our team uses a usability expert, documentation writer,
> > occasionally when available a QA person, so the PM is often
> > busy negotiating for  those resources who aren't full time on our
> > team.  It may not sounds like " classic " agile, but we are very
> > successfull with remote and less than full-time resources, given a
> > little extra effort on the part of the scrum master (PMP, ex-PM ) to
> > make it all come together.
> >
> > Also,  learning to be a servant leader (scrum master) and learning
> > team facilitation techniques are engaging activities to PM's who are
> > ready to move to a deeper level of support for team.
> >





Jean Richardson, PMP, CSM
c: 503-788-8998

Yeah, point taken. I wasn't reading it like that :-)

Jack
www.agilebuddy.com
blog.agilebuddy.com
twitter.com/agilebuddy

Hello, Dan.  On Friday, July 31, 2009, at 2:55:28 PM, you wrote:

> Now, an aside. If you have a scrum project, and it has a PM (somebody
> designated by the organizational to manage the project), that that
> person is your PO. We can start a discussion about that, if you wish,
> but that's a different discussion than the one we're having here, I think.

I know of teams where that's not the case.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Education is the ability to listen to almost anything without losing
your temper or your self-confidence. --Robert Frost

Congratulations!!!

I'm so excited because my presentation has also been selected.

Your work is so interesting, I won't miss it! ;-)

See you there.

Cheers,

    Gemma Hornos

 

Rafael,

 

make sure you get to Munich two weeks early and have a beer at the Oktoberfest for the good times.

 

Congratulations and Ein Prosit,

Pablo Emanuel

2009/7/31 Rafael Sabbagh Armony <sabbagh@gmail.com>

Hi,

me, Rafael Sabbagh, and Marcos Garrido are very proud to announce that our work, Scrum and the World Crisis (aka Scrum and the Recession) was selected to be presented at the Germany Scrum Gathering, to take place in Munich next october (http://www.scrumalliance.org/events/77-germany-scrum-gathering).

The text was published at the ScrumAlliance website (http://www.scrumalliance.org/articles/127) and the presentation is available at SlideShare (http://www.slideshare.net/scrumability/scrum-and-the-world-crisis-1452731).

We presented this work at the Brazil Scrum Gathering last may.


Regards,
   Rafael Sabbagh

* value to the user or customer -> what exactly should the product owner
prioritize which doesn't have value to the customer or user? Lots of
things, including things that have value to the business, the
organization, the team, the product...

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Peter Stevens (cal) wrote:
>
>
> Hi Dan,
>
> I agree with your summary, but am puzzled by your disagreement on the
> constraints.
>
> * value to the user or customer -> what exactly should the product
> owner prioritize which doesn't have value to the customer or user?
>
> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
> stong. The team commits to do its best to meet the sprint goal and
> backlog commitments. Timebox and Quality (Definition of Done) are more
> important than Scope.
>
> * definition of done. I agree that the definition is agreed betweeen
> P-O and Team (or perhaps even part of a departmental or company-wide
> standard, but that is advanced magic ;-) ), but what is the problem of
> the word 'formal'? You have X points, and the team commits to
> satisfying all X points before presenting the result to the P-O.
>
> I have seen some variation of how the definition of done is taught.
> Most CST's that I have seen thought of the definition of done as a
> collection of quality checks, e.g. we have checked in the SW, done a
> code review,  all unit tests green, etc. Ken Schwaber (I had the honor
> of attending his CSM course in Zürich last month) presented a template
> defining all the tasks needed to complete a product backlog item. His
> goal was to prevent 'undone' work:
>
> Developer: It's done.
> P-O: OK, so we can release it.
> Dev: Uh, no.
> P-O: Why not?
> Dev: Because we have to...
>
> Anything after the ellipses was undone work. As teams mature, the
> amount of undone work after a sprint should approach zero. So you get
> a rather long template for assuring that all PBI's are completed to
> satisfaction.
>
> Cheers,
>
> Peter
>
>
> Dan Rawsthorne wrote:
>
>> I love what you wrote, especially about the principles and values of
>> scrum, but I disagree with all of your constraints :)
>>
>>     * work committed at the beginning of a sprint must have value to the
>>       customer or user - I disagree. There are many sorts of value.
>>       Scrum is silent on which ones to use. All you know is that the PO
>>       prioritized it
>>
>>     * work committed at the beginning of a sprint must be finished at
>>       the end of the sprint. - I disagree. There is a commitment. It is
>>       unclear what that commitment means. If there is pressure to finish
>>       nomatter what, technical debt and unsustainable pace naturally
>>       follow. So, again, what do you value?
>>
>>     * the team must complete the work according to a formal definition
>>       of done - I nearly agree.I only disagree with the word "formal"
>>       here. I say "agreed to" definition of done
>>
>> The main think I know about scrum is once you get past the basics of
>> "inspect and adapt" for both your product and process, virtually
>> everything is malleable. That's on purpose, I think, because the purpose
>> is to maximize what your organization values, whatever that is.
>>
>> Dan Rawsthorne, PhD, CST
>> Senior Coach, Danube Technologies
>> dan@..., 425-269-8628
>>
>>
>>
>> Peter Stevens (cal) wrote:
>>
>>>
>>>
>>> Hi Adam,
>>>
>>> That's the problem with any self-reporting and lack of branding. What
>>> the asker of a question means with the question and how the respondent
>>> interprets the question can be two entirely different things.
>>>
>>> At last year's Agile Business Conference in London, keynote speaker
>>> Rob Thomsett defined Agile as a set of values, not as a set of
>>> practices: Openness, Trust, Honesty, Courage and Fiscal
>>> Responsibility. So projects using everything from Scrum to XP to DSDM
>>> to RUP could claim to be Agile.
>>>
>>> I conducted a poll last summer asking the 8 questions of the Nokia
>>> test. "Is anybody really doing Scrum
>>>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>?"
>>> 3/4th of the respondents scored 7 or less. Because of the tool used to
>>> collect the data, I couldn't tell how many satisfied Nokia's
>>> definition of Agile (First 3 questions). The number of respondents was
>>> also rather small -- 47 -- so one might question how representative
>>> this poll was. Since then, Robin Dymond has been started a project to
>>> get 1000 respondents to answer an extended version of the test. Last I
>>> heard, he had 360 respondents, so he hasn't published any results yet.
>>>
>>> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
>>> of tilllate.com, described his company's getting started with Scrum.
>>> When he started, he didn't believe that Scrum would work in his
>>> company, so he changed it. Pretty dramatically. For instance, time
>>> boxes yes, fixed length iterations no. At the beginning of his talk, I
>>> wondered if we could even call his process Scrum. He definitely broke
>>> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
>>> process brought him closer to Scrum by the book (adding
>>> retrospectives, daily scrums, ready to try again with fixed length
>>> iterations, etc).
>>>
>>> The talk was a real eye opener. If your top management gets the
>>> principles of Scrum, the practices are less of an issue. If they
>>> don't, well, it can be tough.
>>>
>>> Scrum doesn't actually specify any engineering practices. It specifies
>>> three constraints:
>>>
>>>     * work committed at the beginning of a sprint must have value to
>>>       the customer or user
>>>     * work committed at the beginning of a sprint must be finished at
>>>       the end of the sprint.
>>>     * the team must complete the work according to a formal definition
>>>       of done
>>>
>>> These constraints drive most teams to move towards XP engineering
>>> practices (even though there is no requirement to do so).  I am not
>>> aware of any evidence which shows that doing agile engineering leads
>>> companies to adopt agile management practices, so Scrum is the place
>>> to start.
>>>
>>> So, coming back to your original post, I think you've got the numbers
>>> and messages you need:
>>>
>>>    1. > 50% of all IT projects are doing (or trying to do) agile.
>>>    2. 84% of them do (or are trying to do) Scrum -- and this is the
>>>       place to start.
>>>    3. Scrum is hard, so management buy in and commitment are essential.
>>>
>>> Now it's time for management to self organize: "How do you convince
>>> yourselves the Scrum and Agile are worthy of serious commitment? How
>>> do you learn to walk the walk?"
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>>
>>>
>>> Adam Sroka wrote:
>>>
>>>> Ken's numbers match my experience, but I wonder how many of those 84%
>>>> are doing some kind of Scrum-but with absolutely none of the Agile
>>>> "engineering practices." And, of those who claim to be doing some form
>>>> of Agile that isn't Scrum, I wonder how many are actually doing
>>>> anything that would remotely resemble Agile to you or I.
>>>>
>>>> Also, as an aside, I've noticed that nearly every job description now
>>>> says "Experience with agile methodologies - especially Scrum or XP -
>>>> is desirable," or something quite similar. It makes using the job
>>>> boards more difficult, because nine out of ten of the results for
>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------
>>
>> To Post a message, send it to:   scrumdevelopment@eGroups.com
>> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...! Groups Links
>>
>>
>>
>>
>
>

Not right now. But, just look at the definitions of PM and PO and let me
know what you think.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Jean Richardson wrote:
>
>
> Dan, I am glad you raised this, and I was right with you until the
> last paragraph. Can you say more about what you have in mind there?
>
> -- Jean
>
> Dan Rawsthorne wrote:
>
> > I want to be pedantic for a second. We're actually asking the question
> > "what do we do with *people* that have been trained to be PMs, the
> > *people* that have been trained to be BAs?" Right? We need to be
> precise
> > here. What does the PM do? Well, it's a role, so the PM manages
> > projects. Period. Or he/she is not a PM.
> >
> > So, the opening statement below should be "we shouldn't assume Jill
> goes
> > to a customer-centric role just because she's been a PM, or has been
> > trained to be a PM, or whatever." Scrum focus on people, on the
> > self-organizing cross-functional team, right? So, stop talking about
> > roles and start talking about abilities... please.
> >
> > Now, an aside. If you have a scrum project, and it has a PM (somebody
> > designated by the organizational to manage the project), that that
> > person is your PO. We can start a discussion about that, if you wish,
> > but that's a different discussion than the one we're having here, I
> think.
> >
> > Dan Rawsthorne, PhD, CST
> > Senior Coach, Danube Technologies
> > dan@... <mailto:dan%40danube.com>, 425-269-8628
> >
> >
> >
> > Kathy Adams wrote:
> > >
> > >
> > > We shouldn't assume the PM goes to a customer-centric role. Some
> > > teams have Business Analysts who move in that direction. Our projects
> > > tend to use out-sourced resources, so the PM is often doing the
> > > administrative work of contract negotiation, invoice management,
> > > vendor management, etc. We also have recently trained our key user to
> > > be the product owner, leaving the BA to really own moving from user
> > > stories to deeper requirements and defining test criteria with the PO
> > > and managing or doing testing.
> > >
> > > PM's also tend to become the scrum master working on removing
> > > roadblocks. Our team uses a usability expert, documentation writer,
> > > occasionally when available a QA person, so the PM is often
> > > busy negotiating for those resources who aren't full time on our
> > > team. It may not sounds like " classic " agile, but we are very
> > > successfull with remote and less than full-time resources, given a
> > > little extra effort on the part of the scrum master (PMP, ex-PM ) to
> > > make it all come together.
> > >
> > > Also, learning to be a servant leader (scrum master) and learning
> > > team facilitation techniques are engaging activities to PM's who are
> > > ready to move to a deeper level of support for team.
> > >
>
> Jean Richardson, PMP, CSM
> c: 503-788-8998
>
>

Look at the definitions of PO and PM and tell me how that can be, Ron.
Then we can talk about it at Agile2009 :)

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Ron Jeffries wrote:
>
>
> Hello, Dan. On Friday, July 31, 2009, at 2:55:28 PM, you wrote:
>
> > Now, an aside. If you have a scrum project, and it has a PM (somebody
> > designated by the organizational to manage the project), that that
> > person is your PO. We can start a discussion about that, if you wish,
> > but that's a different discussion than the one we're having here, I
> think.
>
> I know of teams where that's not the case.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Education is the ability to listen to almost anything without losing
> your temper or your self-confidence. --Robert Frost
>
>

Ok, Ron, I slightly mispoke. "If you have a member of your team that is
the PM, then that person is your PO" is what I should have said. I left
off the "member of team" part. Sorry 'bout that.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Ron Jeffries wrote:
>
>
> Hello, Dan. On Friday, July 31, 2009, at 2:55:28 PM, you wrote:
>
> > Now, an aside. If you have a scrum project, and it has a PM (somebody
> > designated by the organizational to manage the project), that that
> > person is your PO. We can start a discussion about that, if you wish,
> > but that's a different discussion than the one we're having here, I
> think.
>
> I know of teams where that's not the case.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Education is the ability to listen to almost anything without losing
> your temper or your self-confidence. --Robert Frost
>
>

Hello, Dan.  On Friday, July 31, 2009, at 4:56:18 PM, you wrote:

> Look at the definitions of PO and PM and tell me how that can be, Ron.
> Then we can talk about it at Agile2009 :)

Definitions have little to do with reality. Some companies
   - have POs
   - have PMs
   - do Scrum.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

I find Dan technically correct in the hairsplitting contest, but I
sympathize more with Peter -- especially on the need to prioritize
with a customer-centric focus instead of appeasing all the internal
organizational crud that builds up as companies scale.

If we're brought in to transform organizations, what's the point of
emphasizing loopholes that encourage them to keep doing what they've
been doing?

--mj


On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...> wrote:
> * value to the user or customer -> what exactly should the product owner
> prioritize which doesn't have value to the customer or user? Lots of
> things, including things that have value to the business, the
> organization, the team, the product...
>
> Dan Rawsthorne, PhD, CST
> Senior Coach, Danube Technologies
> dan@..., 425-269-8628
>
>
>
> Peter Stevens (cal) wrote:
>>
>>
>> Hi Dan,
>>
>> I agree with your summary, but am puzzled by your disagreement on the
>> constraints.
>>
>> * value to the user or customer -> what exactly should the product
>> owner prioritize which doesn't have value to the customer or user?
>>
>> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
>> stong. The team commits to do its best to meet the sprint goal and
>> backlog commitments. Timebox and Quality (Definition of Done) are more
>> important than Scope.
>>
>> * definition of done. I agree that the definition is agreed betweeen
>> P-O and Team (or perhaps even part of a departmental or company-wide
>> standard, but that is advanced magic ;-) ), but what is the problem of
>> the word 'formal'? You have X points, and the team commits to
>> satisfying all X points before presenting the result to the P-O.
>>
>> I have seen some variation of how the definition of done is taught.
>> Most CST's that I have seen thought of the definition of done as a
>> collection of quality checks, e.g. we have checked in the SW, done a
>> code review,  all unit tests green, etc. Ken Schwaber (I had the honor
>> of attending his CSM course in Zürich last month) presented a template
>> defining all the tasks needed to complete a product backlog item. His
>> goal was to prevent 'undone' work:
>>
>> Developer: It's done.
>> P-O: OK, so we can release it.
>> Dev: Uh, no.
>> P-O: Why not?
>> Dev: Because we have to...
>>
>> Anything after the ellipses was undone work. As teams mature, the
>> amount of undone work after a sprint should approach zero. So you get
>> a rather long template for assuring that all PBI's are completed to
>> satisfaction.
>>
>> Cheers,
>>
>> Peter
>>
>>
>> Dan Rawsthorne wrote:
>>
>>> I love what you wrote, especially about the principles and values of
>>> scrum, but I disagree with all of your constraints :)
>>>
>>>     * work committed at the beginning of a sprint must have value to the
>>>       customer or user - I disagree. There are many sorts of value.
>>>       Scrum is silent on which ones to use. All you know is that the PO
>>>       prioritized it
>>>
>>>     * work committed at the beginning of a sprint must be finished at
>>>       the end of the sprint. - I disagree. There is a commitment. It is
>>>       unclear what that commitment means. If there is pressure to finish
>>>       nomatter what, technical debt and unsustainable pace naturally
>>>       follow. So, again, what do you value?
>>>
>>>     * the team must complete the work according to a formal definition
>>>       of done - I nearly agree.I only disagree with the word "formal"
>>>       here. I say "agreed to" definition of done
>>>
>>> The main think I know about scrum is once you get past the basics of
>>> "inspect and adapt" for both your product and process, virtually
>>> everything is malleable. That's on purpose, I think, because the purpose
>>> is to maximize what your organization values, whatever that is.
>>>
>>> Dan Rawsthorne, PhD, CST
>>> Senior Coach, Danube Technologies
>>> dan@..., 425-269-8628
>>>
>>>
>>>
>>> Peter Stevens (cal) wrote:
>>>
>>>>
>>>>
>>>> Hi Adam,
>>>>
>>>> That's the problem with any self-reporting and lack of branding. What
>>>> the asker of a question means with the question and how the respondent
>>>> interprets the question can be two entirely different things.
>>>>
>>>> At last year's Agile Business Conference in London, keynote speaker
>>>> Rob Thomsett defined Agile as a set of values, not as a set of
>>>> practices: Openness, Trust, Honesty, Courage and Fiscal
>>>> Responsibility. So projects using everything from Scrum to XP to DSDM
>>>> to RUP could claim to be Agile.
>>>>
>>>> I conducted a poll last summer asking the 8 questions of the Nokia
>>>> test. "Is anybody really doing Scrum
>>>>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>?"
>>>>
>>>> 3/4th of the respondents scored 7 or less. Because of the tool used to
>>>> collect the data, I couldn't tell how many satisfied Nokia's
>>>> definition of Agile (First 3 questions). The number of respondents was
>>>> also rather small -- 47 -- so one might question how representative
>>>> this poll was. Since then, Robin Dymond has been started a project to
>>>> get 1000 respondents to answer an extended version of the test. Last I
>>>> heard, he had 360 respondents, so he hasn't published any results yet.
>>>>
>>>> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
>>>> of tilllate.com, described his company's getting started with Scrum.
>>>> When he started, he didn't believe that Scrum would work in his
>>>> company, so he changed it. Pretty dramatically. For instance, time
>>>> boxes yes, fixed length iterations no. At the beginning of his talk, I
>>>> wondered if we could even call his process Scrum. He definitely broke
>>>> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
>>>> process brought him closer to Scrum by the book (adding
>>>> retrospectives, daily scrums, ready to try again with fixed length
>>>> iterations, etc).
>>>>
>>>> The talk was a real eye opener. If your top management gets the
>>>> principles of Scrum, the practices are less of an issue. If they
>>>> don't, well, it can be tough.
>>>>
>>>> Scrum doesn't actually specify any engineering practices. It specifies
>>>> three constraints:
>>>>
>>>>     * work committed at the beginning of a sprint must have value to
>>>>       the customer or user
>>>>     * work committed at the beginning of a sprint must be finished at
>>>>       the end of the sprint.
>>>>     * the team must complete the work according to a formal definition
>>>>       of done
>>>>
>>>> These constraints drive most teams to move towards XP engineering
>>>> practices (even though there is no requirement to do so).  I am not
>>>> aware of any evidence which shows that doing agile engineering leads
>>>> companies to adopt agile management practices, so Scrum is the place
>>>> to start.
>>>>
>>>> So, coming back to your original post, I think you've got the numbers
>>>> and messages you need:
>>>>
>>>>    1. > 50% of all IT projects are doing (or trying to do) agile.
>>>>    2. 84% of them do (or are trying to do) Scrum -- and this is the
>>>>       place to start.
>>>>    3. Scrum is hard, so management buy in and commitment are essential.
>>>>
>>>> Now it's time for management to self organize: "How do you convince
>>>> yourselves the Scrum and Agile are worthy of serious commitment? How
>>>> do you learn to walk the walk?"
>>>>
>>>> Cheers,
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> Adam Sroka wrote:
>>>>
>>>>> Ken's numbers match my experience, but I wonder how many of those 84%
>>>>> are doing some kind of Scrum-but with absolutely none of the Agile
>>>>> "engineering practices." And, of those who claim to be doing some form
>>>>> of Agile that isn't Scrum, I wonder how many are actually doing
>>>>> anything that would remotely resemble Agile to you or I.
>>>>>
>>>>> Also, as an aside, I've noticed that nearly every job description now
>>>>> says "Experience with agile methodologies - especially Scrum or XP -
>>>>> is desirable," or something quite similar. It makes using the job
>>>>> boards more difficult, because nine out of ten of the results for
>>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> To Post a message, send it to:   scrumdevelopment@eGroups.com
>>> To Unsubscribe, send a blank message to:
>>> scrumdevelopment-unsubscribe@...! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...! Groups Links
>
>
>
>

--
Sent from my mobile device

Yes, they have people that are called POs, and people that are called
PMs, and are doing something called scrum. But since scrum says you get
only one "wringable neck" and both the PM and the PO are defined by that
term, either they are the same person or one of them is not really doing
his/her job. Probably the latter, as many people misunderstand the terms
(both of them) and call people what they aren't. But, as I like to point
out in class, you are what you are, not what you say you are  :)

Just sayin'   Dan  ;-)

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Ron Jeffries wrote:
>
>
> Hello, Dan. On Friday, July 31, 2009, at 4:56:18 PM, you wrote:
>
> > Look at the definitions of PO and PM and tell me how that can be, Ron.
> > Then we can talk about it at Agile2009 :)
>
> Definitions have little to do with reality. Some companies
> - have POs
> - have PMs
> - do Scrum.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> I'm not bad, I'm just drawn that way. -- Jessica Rabbit
>
>

Ah, MJ, I agree with you. But I think that hairsplitting is important on
this group, because if we don't know exactly what we're talking about
here, how can we expect to explain it to others? The fact that I do
split hairs has allowed me to have conversations like "yes, you're doing
something like scrum, but you're not really Agile", and "yes, you're
using C++, but you're not object oriented." I think that bad behavior
hides in the mushiness, if we allow it.

And, MJ, of course you should prioritize with a customer-centric focus.
But that does not mean that you prioritize only things that have
customer value. I know, more hair-splitting... but I've seen and heard
of a lot of teams that have a hard time justifying something that
obviously needs to be done (like rearranging the team room) because it
doesn't have "customer value." The good news is that it's the SM's job
to question all this and ask "why is this valuable again?" and "don't we
need to do this?" when working with the PO. It's all about the
conversations, remember... there really aren't that many rules.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



Michael James wrote:
>
>
> I find Dan technically correct in the hairsplitting contest, but I
> sympathize more with Peter -- especially on the need to prioritize
> with a customer-centric focus instead of appeasing all the internal
> organizational crud that builds up as companies scale.
>
> If we're brought in to transform organizations, what's the point of
> emphasizing loopholes that encourage them to keep doing what they've
> been doing?
>
> --mj
>
> On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
> <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
> > * value to the user or customer -> what exactly should the product owner
> > prioritize which doesn't have value to the customer or user? Lots of
> > things, including things that have value to the business, the
> > organization, the team, the product...
> >
> > Dan Rawsthorne, PhD, CST
> > Senior Coach, Danube Technologies
> > dan@... <mailto:dan%40danube.com>, 425-269-8628
> >
> >
> >
> > Peter Stevens (cal) wrote:
> >>
> >>
> >> Hi Dan,
> >>
> >> I agree with your summary, but am puzzled by your disagreement on the
> >> constraints.
> >>
> >> * value to the user or customer -> what exactly should the product
> >> owner prioritize which doesn't have value to the customer or user?
> >>
> >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
> >> stong. The team commits to do its best to meet the sprint goal and
> >> backlog commitments. Timebox and Quality (Definition of Done) are more
> >> important than Scope.
> >>
> >> * definition of done. I agree that the definition is agreed betweeen
> >> P-O and Team (or perhaps even part of a departmental or company-wide
> >> standard, but that is advanced magic ;-) ), but what is the problem of
> >> the word 'formal'? You have X points, and the team commits to
> >> satisfying all X points before presenting the result to the P-O.
> >>
> >> I have seen some variation of how the definition of done is taught.
> >> Most CST's that I have seen thought of the definition of done as a
> >> collection of quality checks, e.g. we have checked in the SW, done a
> >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
> >> of attending his CSM course in Zürich last month) presented a template
> >> defining all the tasks needed to complete a product backlog item. His
> >> goal was to prevent 'undone' work:
> >>
> >> Developer: It's done.
> >> P-O: OK, so we can release it.
> >> Dev: Uh, no.
> >> P-O: Why not?
> >> Dev: Because we have to...
> >>
> >> Anything after the ellipses was undone work. As teams mature, the
> >> amount of undone work after a sprint should approach zero. So you get
> >> a rather long template for assuring that all PBI's are completed to
> >> satisfaction.
> >>
> >> Cheers,
> >>
> >> Peter
> >>
> >>
> >> Dan Rawsthorne wrote:
> >>
> >>> I love what you wrote, especially about the principles and values of
> >>> scrum, but I disagree with all of your constraints :)
> >>>
> >>> * work committed at the beginning of a sprint must have value to the
> >>> customer or user - I disagree. There are many sorts of value.
> >>> Scrum is silent on which ones to use. All you know is that the PO
> >>> prioritized it
> >>>
> >>> * work committed at the beginning of a sprint must be finished at
> >>> the end of the sprint. - I disagree. There is a commitment. It is
> >>> unclear what that commitment means. If there is pressure to finish
> >>> nomatter what, technical debt and unsustainable pace naturally
> >>> follow. So, again, what do you value?
> >>>
> >>> * the team must complete the work according to a formal definition
> >>> of done - I nearly agree.I only disagree with the word "formal"
> >>> here. I say "agreed to" definition of done
> >>>
> >>> The main think I know about scrum is once you get past the basics of
> >>> "inspect and adapt" for both your product and process, virtually
> >>> everything is malleable. That's on purpose, I think, because the
> purpose
> >>> is to maximize what your organization values, whatever that is.
> >>>
> >>> Dan Rawsthorne, PhD, CST
> >>> Senior Coach, Danube Technologies
> >>> dan@... <mailto:dan%40danube.com>, 425-269-8628
> >>>
> >>>
> >>>
> >>> Peter Stevens (cal) wrote:
> >>>
> >>>>
> >>>>
> >>>> Hi Adam,
> >>>>
> >>>> That's the problem with any self-reporting and lack of branding. What
> >>>> the asker of a question means with the question and how the
> respondent
> >>>> interprets the question can be two entirely different things.
> >>>>
> >>>> At last year's Agile Business Conference in London, keynote speaker
> >>>> Rob Thomsett defined Agile as a set of values, not as a set of
> >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
> >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
> >>>> to RUP could claim to be Agile.
> >>>>
> >>>> I conducted a poll last summer asking the 8 questions of the Nokia
> >>>> test. "Is anybody really doing Scrum
> >>>>
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml
>
<http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.ht\
ml>>?"
> >>>>
> >>>> 3/4th of the respondents scored 7 or less. Because of the tool
> used to
> >>>> collect the data, I couldn't tell how many satisfied Nokia's
> >>>> definition of Agile (First 3 questions). The number of
> respondents was
> >>>> also rather small -- 47 -- so one might question how representative
> >>>> this poll was. Since then, Robin Dymond has been started a project to
> >>>> get 1000 respondents to answer an extended version of the test.
> Last I
> >>>> heard, he had 360 respondents, so he hasn't published any results
> yet.
> >>>>
> >>>> The speaker at last month's the Scrum Breakfast, Silvan
> Mühlemann, CTO
> >>>> of tilllate.com, described his company's getting started with Scrum.
> >>>> When he started, he didn't believe that Scrum would work in his
> >>>> company, so he changed it. Pretty dramatically. For instance, time
> >>>> boxes yes, fixed length iterations no. At the beginning of his
> talk, I
> >>>> wondered if we could even call his process Scrum. He definitely broke
> >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
> That
> >>>> process brought him closer to Scrum by the book (adding
> >>>> retrospectives, daily scrums, ready to try again with fixed length
> >>>> iterations, etc).
> >>>>
> >>>> The talk was a real eye opener. If your top management gets the
> >>>> principles of Scrum, the practices are less of an issue. If they
> >>>> don't, well, it can be tough.
> >>>>
> >>>> Scrum doesn't actually specify any engineering practices. It
> specifies
> >>>> three constraints:
> >>>>
> >>>> * work committed at the beginning of a sprint must have value to
> >>>> the customer or user
> >>>> * work committed at the beginning of a sprint must be finished at
> >>>> the end of the sprint.
> >>>> * the team must complete the work according to a formal definition
> >>>> of done
> >>>>
> >>>> These constraints drive most teams to move towards XP engineering
> >>>> practices (even though there is no requirement to do so). I am not
> >>>> aware of any evidence which shows that doing agile engineering leads
> >>>> companies to adopt agile management practices, so Scrum is the place
> >>>> to start.
> >>>>
> >>>> So, coming back to your original post, I think you've got the numbers
> >>>> and messages you need:
> >>>>
> >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
> >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
> >>>> place to start.
> >>>> 3. Scrum is hard, so management buy in and commitment are essential.
> >>>>
> >>>> Now it's time for management to self organize: "How do you convince
> >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
> >>>> do you learn to walk the walk?"
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Peter
> >>>>
> >>>>
> >>>>
> >>>> Adam Sroka wrote:
> >>>>
> >>>>> Ken's numbers match my experience, but I wonder how many of
> those 84%
> >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
> >>>>> "engineering practices." And, of those who claim to be doing
> some form
> >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
> >>>>> anything that would remotely resemble Agile to you or I.
> >>>>>
> >>>>> Also, as an aside, I've noticed that nearly every job
> description now
> >>>>> says "Experience with agile methodologies - especially Scrum or XP -
> >>>>> is desirable," or something quite similar. It makes using the job
> >>>>> boards more difficult, because nine out of ten of the results for
> >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> To Post a message, send it to: scrumdevelopment@eGroups.com
> <mailto:scrumdevelopment%40eGroups.com>
> >>> To Unsubscribe, send a blank message to:
> >>> scrumdevelopment-unsubscribe@...
> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to: scrumdevelopment@eGroups.com
> <mailto:scrumdevelopment%40eGroups.com>
> > To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe@...
> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
> >
> >
> >
> >
>
> --
> Sent from my mobile device
>
>