Ron Jeffries | 1 Jul 03:32 2008
Picon

Re: Re: Why are we still allowing the term "Agile Project Manager"?

Hello, Robert.  On Monday, June 30, 2008, at 5:08:58 PM, you wrote:

> I was thinking of things that might be hard to resolve at the broader
> business level, because decisions were being delayed, for example.
> So if the software was for a timecard system for a company, and they
> were delaying a decision about the way overtime was recorded while
> they negotiated with the union.

> Might that seem like an obstruction to developing the software?

Only if the PO had scheduled the story and then the info wasn't
available. The programmer should report the obstacle and the SM
should resolve it, probably by having the story cancelled.

Too often, however, teams just try to muddle through without knowing
what to do, waiting long intervals between Q and A, and such. That's
not so good.

> But maybe you should suggest an example of an obstruction too.

Handoffs, e.g. programmer to tester;
Technical tasks;
DBA not available;
Waiting for UI design for a story already scheduled;
Multi-Sprint work in progress, i.e. phased stories;
...

Ron Jeffries
www.XProgramming.com
I must create a system, or be enslaved by another man's;
(Continue reading)

George Dinwiddie | 1 Jul 04:01 2008

Re: Re: Company Standards

woynam wrote:
> If the original choices were poor, then it should be fairly
> straightforward to demonstrate the value of using a different
> framework or platform.

How would /you/ demonstrate the value of a different framework or 
platform without trying it out on a real project?

> As I discussed in my original response, R&D can be incorporated into
> the process in a controlled manner, rather than an
> every-team-for-themselves approach.

So far, I've only heard you talk about an "every-team-for-themselves 
approach."  Let's review the options mentioned:

  1. "a team should be able to deviate from company standards
*only* when they can demonstrate that there is value to be had in
deviating, and the value is greater than any cost associated with the
deviation."
  2. "an every-team-for-themselves approach."

Can you think of a third alternative?  "One choice is s trap.  Two 
choices is a dilemma.  Three choices is a choice."

> Besides, the original post on this thread discussed a team that chose
> to use different reporting tools, even though the company approved
> tools were sufficient for agile teams.

Were sufficient as deemed by those who chose the tools.

(Continue reading)

George Dinwiddie | 1 Jul 04:05 2008

Re: Failure or success?

Flávio Steffens de Castro wrote:
> Hello folks,
> 
>  I was reading and discussing about the change management when we are 
> creating an "agile" concept in a company. I read that some people think 
> that the best thing to do, in the first sprints, is to let the team 
> failure... so in the retrospectives, all this can be discussed and 
> analyzed generating lessons learned.
> 
> In other way, some people say that the best thing to do is creating a 
> environment where they will achieve success in the first sprints. This 
> will show them how to work with scrum, the benefits and improve the 
> motivation.
> 
> I can say that I prefer the "success path", at least in the first 
> sprints. People may be a little confused in the beginning, with the 
> changes. If we let them go to fail, we are making them think that "this 
> 'scrum' does not help us!".
> 
> What are your opinion about this?

Flavio, I agree that the "success path" is more inspiring and help 
people achieve future successes.  I don't know how to reliably engineer 
this situation, though.  Can you offer some suggestions from your own 
experience?

  - George

--

-- 
  ----------------------------------------------------------------------
(Continue reading)

Ron Jeffries | 1 Jul 04:46 2008
Picon

Re: Company Standards (Was Re:Voting the entire team off the island)

Hello, woynam.  On Monday, June 30, 2008, at 5:06:00 PM, you wrote:

> However, it sounds like you're suggesting that the team is free to
> choose any tool or approach they like without first demonstrating that
>  the "company standard" is in fact an impediment to success.

> I find that quite odd. We warn people about piling too many features
> into a product before knowing that the features are actually useful.
> We say that they should prioritize, and only build the highest
> priority features.

> Shouldn't it be the team's responsibility to demonstrate that an
> existing approach is deficient? Just because something is a standard
> doesn't mean it's not good. Sure, there may be something technically
> better, but is it really better from a business value standpoint?
> What's the cost associated with purchasing, training, and supporting
> multiple tools/frameworks? It doesn't come for free.

> By focusing on optimizing *your* project, you may be guilty of
> suboptimizing the whole organization. You can't look at things in
> isolation, at least not in a large enterprise.

You seem to think that there is some automatic benefit to a company
standard. Is that the case? If so, what is that benefit?

If a team is familiar with the company standard, and still wishes to
use some other tools, that seems quite significant, doesn't it?

If they are not familiar with the company standard, and are familiar
with the tools they want to use, that seems efficient, doesn't it?
(Continue reading)

Tobias Mayer | 1 Jul 05:07 2008
Picon

Re: Company Standards (Was Re:Voting the entire team off the island)

Ron,

> If they are not familiar with the company standard, and are familiar with the tools they want to use, that seems efficient, doesn't it?

Yes.  But not necessarily effective.  I believe the team has a duty to become familiar with the company standard and then make an informed choice. 

It is useful to have some consistency and/or common understanding across teams.  If that comes from a top-down directive it is unlikely to be embraced.  It is better for such a "standard" to arise from the teams themselves.  And it should always be reviewed. 

Blindly following a company standard is clearly undesirable, but then so is just staying with what you know and not exploring alternatives.

Tobias



--- On Mon, 6/30/08, Ron Jeffries <ronjeffries <at> acm.org> wrote:
From: Ron Jeffries <ronjeffries <at> acm.org>
Subject: Re: [scrumdevelopment] Company Standards (Was Re:Voting the entire team off the island)
To: scrumdevelopment <at> yahoogroups.com
Date: Monday, June 30, 2008, 7:46 PM

Hello, woynam. On Monday, June 30, 2008, at 5:06:00 PM, you wrote:

> However, it sounds like you're suggesting that the team is free to
> choose any tool or approach they like without first demonstrating that
> the "company standard" is in fact an impediment to success.

> I find that quite odd. We warn people about piling too many features
> into a product before knowing that the features are actually useful.
> We say that they should prioritize, and only build the highest
> priority features.

> Shouldn't it be the team's responsibility to demonstrate that an
> existing approach is deficient? Just because something is a standard
> doesn't mean it's not good. Sure, there may be something technically
> better, but is it really better from a business value standpoint?
> What's the cost associated with purchasing, training, and supporting
> multiple tools/frameworks? It doesn't come for free.

> By focusing on optimizing *your* project, you may be guilty of
> suboptimizing the whole organization. You can't look at things in
> isolation, at least not in a large enterprise.

You seem to think that there is some automatic benefit to a company
standard. Is that the case? If so, what is that benefit?

If a team is familiar with the company standard, and still wishes to
use some other tools, that seems quite significant, doesn't it?

If they are not familiar with the company standard, and are familiar
with the tools they want to use, that seems efficient, doesn't it?

What's really trying to be accomplished with the company standard?

Ron Jeffries
www.XProgramming. com
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting. --Millard Fuller

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Flávio Steffens de Castro | 1 Jul 05:25 2008
Picon

Re: Failure or success?

Hey George!

My idea is just simple: if you really know something about the team, dont make them promise as the "selected product backlog" as big as they can. People like to think that they can achieve challenges, without know their limits. We can engineer this by making them stand on the ground (not fly to the skies). "People, let's try to deliver one or two little features in this first sprint, so you can live a little more of the SCRUM". Things like this. Very simple and very realistic :)

Thanks!

Flavio

_____________________
Flavio Steffens de Castro

On Mon, Jun 30, 2008 at 11:05 PM, George Dinwiddie <lists <at> idiacomputing.com> wrote:

Flávio Steffens de Castro wrote:
> Hello folks,
>
> I was reading and discussing about the change management when we are
> creating an "agile" concept in a company. I read that some people think
> that the best thing to do, in the first sprints, is to let the team
> failure... so in the retrospectives, all this can be discussed and
> analyzed generating lessons learned.
>
> In other way, some people say that the best thing to do is creating a
> environment where they will achieve success in the first sprints. This
> will show them how to work with scrum, the benefits and improve the
> motivation.
>
> I can say that I prefer the "success path", at least in the first
> sprints. People may be a little confused in the beginning, with the
> changes. If we let them go to fail, we are making them think that "this
> 'scrum' does not help us!".
>
> What are your opinion about this?

Flavio, I agree that the "success path" is more inspiring and help
people achieve future successes. I don't know how to reliably engineer
this situation, though. Can you offer some suggestions from your own
experience?

- George

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


__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Ron Jeffries | 1 Jul 05:47 2008
Picon

Re: Company Standards (Was Re:Voting the entire team off the island)

Hello, Tobias.  On Monday, June 30, 2008, at 11:07:20 PM, you
wrote:

> If they are not familiar with the company standard, and are
> familiar with the tools they want to use, that seems efficient, doesn't it?

> Yes.  But not necessarily effective.  I believe the team has a
> duty to become familiar with the company standard and then make an informed choice. 

Why? Cui bono?

> It is useful to have some consistency and/or common understanding
> across teams.  If that comes from a top-down directive it is
> unlikely to be embraced.  It is better for such a "standard" to
> arise from the teams themselves.  And it should always be reviewed. 

What are the top few reasons it is useful and what are they worth
in, oh, money. US Lire, for example.

> Blindly following a company standard is clearly undesirable, but
> then so is just staying with what you know and not exploring alternatives.

Depends on whether one can identify obstacles in the use, doesn't
it?

Ron Jeffries
www.XProgramming.com
Now -- Bring me that horizon.  -- Captain Jack Sparrow

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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 <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Tobias Mayer | 1 Jul 06:05 2008
Picon

Re: Company Standards (Was Re:Voting the entire team off the island)

Hi Ron.

>> I believe the team has a duty to become familiar with the company standard and then make an informed choice.
> Why? Cui bono?
To the benefit of both the team and the organization.  The was probably some reason that the standard appeared in the first place.  Perhaps a good reason, perhaps not.  Quite probable no one has questioned it yet. Before rejecting things I like to understand what I am rejecting.  An understanding of the standards, and/or reason for those standards helps us to have informed discussion.

Many company standards are just part of the "that's just the way tings work around here".   Sure, we want to challenge that attitude every step of the way, but let's also be open to the fact that some current practices and technologies may be useful.  Learn them, then decide.  That's all.

>> It is useful to have some consistency and/or common understanding across teams.
> What are the top few reasons it is useful
I guessed you'd ask that :-)  I think perhaps it allows team members to move more freely through the organization... helps individuals understand the bigger picture... keeps us from being territorial... It isn't alway necessary to have complete consistency, it is just sometimes useful.

I didn't understand your last comment, but whether we follow a standard or create new ways of working we should always be looking for ways to improve.  I think we agree on that.

Tobias

--- On Mon, 6/30/08, Ron Jeffries <ronjeffries <at> acm.org> wrote:
From: Ron Jeffries <ronjeffries <at> acm.org>
Subject: Re: [scrumdevelopment] Company Standards (Was Re:Voting the entire team off the island)
To: scrumdevelopment <at> yahoogroups.com
Date: Monday, June 30, 2008, 8:47 PM

Hello, Tobias. On Monday, June 30, 2008, at 11:07:20 PM, you
wrote:

> If they are not familiar with the company standard, and are
> familiar with the tools they want to use, that seems efficient, doesn't it?

> Yes. But not necessarily effective. I believe the team has a
> duty to become familiar with the company standard and then make an informed choice.

Why? Cui bono?

> It is useful to have some consistency and/or common understanding
> across teams. If that comes from a top-down directive it is
> unlikely to be embraced. It is better for such a "standard" to
> arise from the teams themselves. And it should always be reviewed.

What are the top few reasons it is useful and what are they worth
in, oh, money. US Lire, for example.

> Blindly following a company standard is clearly undesirable, but
> then so is just staying with what you know and not exploring alternatives.

Depends on whether one can identify obstacles in the use, doesn't
it?

Ron Jeffries
www.XProgramming. com
Now -- Bring me that horizon. -- Captain Jack Sparrow

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Mark Jean | 1 Jul 07:29 2008
Picon

Scrum - The Universally Enlightened

Wow! What can't Scrum do?  

From recent threads on this list, it appears Scrum is becoming 
the "be all - end all." If Scrum can't do it now, it will soon.

Wait a minute!? Isn't Scrum simply a way to develop software? 

Who wouldn't agree that all companies need to rip out their best 
practices & substitute them with Scrum practices? If Scrum doesn't 
have a best practice for it yet - it will soon! Lean Six Sigma - 
garbage!  INCOSE - unenlightened!  PMI - crap!!!

While we're engage at anarchy - let's get rid of all those overpaid C-
level executives.  They're the real problem. Let's empower all 
employees to collectively guide their companies! Yeah! That will 
work! They'll use Scrum to collectively figure it all out on their 
own. Jack Welch - idiot.  John Chambers - knucklehead.  Steve Jobs - 
freak.  Peter Drucker - delerious & deluded.  Non-Scrum structure is 
for simpletons.  Non-Scrum disciplines are for the dull.

Hello!  What possible value is created by extending Scrum into areas 
it is clearly not good at? Please overthrow the bozos & crappy 
business practices via other vehicles. Keep Scrum focused on what 
it's good at - building things. 

That way, more change agents (people) will be successful getting 
their companies to adopt Scrum. Or is helping people implement Scrum 
product development too boring?

Too boring? Then go right ahead & extend ssssscrummmmmmmm. Line 
extensions are for fools & idiots. Extending Scrum into everything is 
ego-driven line extension. If the Scrum elite keep extending Scrum, 
it will be replaced by the next disruptive product development 
technology.

Branding = Focus = Success  (but this marketing principle isn't 
a "Scrum best practice" - therefore it's fundamentally flawed!)

Focus on what Scrum is good at - and what it enables people to do. 
Else "Scrum" is appearing more & more cult-like.

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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 <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Ilja Preuss | 1 Jul 07:43 2008
Picon

Re: Company Standards (Was Re:Voting the entire team off the island)

woynam wrote:
> The basic premise of Scrum is that it's an empirical process that
> allows the team to improve by identifying and removing impediments.

I'm not sure that that's an as complete description of Scrum as you seem 
to imply, but I'm also not sure that that's relevant.

> However, it sounds like you're suggesting that the team is free to
> choose any tool or approach they like without first demonstrating that
>  the "company standard" is in fact an impediment to success.

I guess you could say it that way.

> I find that quite odd. We warn people about piling too many features
> into a product before knowing that the features are actually useful.
> We say that they should prioritize, and only build the highest
> priority features.

Yes. I haven't yet seen someone propose to give the customer a list of 
standard features and let him prove that it's actually different 
features that would provide higher value.

> Shouldn't it be the team's responsibility to demonstrate that an
> existing approach is deficient?

I think it should be the responsibility of those who are creating the 
standard to communicate why the standard is important, in a way that 
makes teams *want* to follow it where it makes sense. I'd think that we 
need teams that we can trust to make good decisions - and that if we 
can't, we have bigger problems to solve than imposing company standards.

 > Just because something is a standard
> doesn't mean it's not good. Sure, there may be something technically
> better, but is it really better from a business value standpoint?
> What's the cost associated with purchasing, training, and supporting
> multiple tools/frameworks? It doesn't come for free.

I'm certainly all for looking at all the costs and benefits before 
making a decision. I don't see how making a company standard the default 
is the best tool to do that.

> By focusing on optimizing *your* project, you may be guilty of
> suboptimizing the whole organization. You can't look at things in
> isolation, at least not in a large enterprise.

I'm certainly all for keeping the big picture in mind. I don't see how a 
company standard, used in the manner you seem to describe, is the best 
tool for that, either.

Cheers, Ilja

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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 <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/


Gmane