Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Re: The nature of executive "pushback" to agile technologies?

Expand Messages
  • Chris Wheeler
    Having changing business needs doesn t mean that you shouldn t plan a release. That s where my view is different. I really do think that today, I can know what
    Message 1 of 119 , Mar 1, 2007
    • 0 Attachment
      Having changing business needs doesn't mean that you shouldn't plan a
      release. That's where my view is different. I really do think that today, I
      can know what I want to deliver 6 months from today. In a month, that may
      change. But today, I know that I have an opportunity to capitalize on, and
      that's where I need to start from.

      As far as changing business goals, every project is different, granted. What
      I've noticed is that changing business goals means the following, most of
      the time:

      1) Change the ship date so that we can hit the market sooner
      2) Drop/add/change a feature based on user feedback
      3) Cancel the project because the market has changed and it doesn't make
      sense to do it anymore

      None of those mean that the initial goal was incorrect - from the beginning
      there needs to be a vision of what is wanted, when it's wanted, and why.

      Because of that, I truly believe that the role of the agile team is to
      deliver on that goal and to make sure that when business needs change, they
      react accordingly, never losing focus on the fact that they are there to
      deliver. What I don't believe is that it's the role of the agile team to
      run amok of the company and insist that goals, plans, and commitments are
      not real things.

      Chris.





      On 3/1/07, Steven Gordon <sgordonphd@...> wrote:
      >
      > I have no problem at all with fixed dates.
      >
      > However, today business goals are inherently dynamic. The business goal
      > whose details can be fixed several months in advance is rare, and getting
      > rarer by the minute (as companies who take a more agile approach to their
      > business goals are kicking the butts of the companies who do not in the
      > internet era).
      >
      > Given dynamic business goals, plans to meet those ever changing goals need
      > to be frequently revisited and revised. Constructing a detailed plan
      > based
      > on the knowledge available at beginning of the project and then executing
      > to
      > that plan (at least until the disconnect with the changing business goals
      > can no longer be ignored) is just not an effective way to meet dynamic
      > goals.
      >
      > In many of the companies where I see a managment resistance to agility,
      > upper management does not see that fixed business goals are unrealistic.
      > When they buy into the idea that agile approaches will allow the company
      > to
      > be more effective, what they hear is that it will make their workers more
      > effective. However, the truth is that it would make the whole management
      > chain more effective, not just the workers, because the business goals
      > have
      > to be dynamic, not fixed.
      >
      > If a companys has a top management with a command-and-control culture of
      > fixed plans for fixed business goals and the people doing the work are
      > using
      > iterative plans to address dynamic business goals, somewhere in the middle
      > of the management chain there will be problems that will lead to
      > resistance
      > to agility.
      >
      > Steve
      >
      > On 3/1/07, Chris Wheeler <christopher.wheeler@...> wrote:
      > >
      > > I think you missed the point - that may not be based on business
      > needs.
      > > I
      > > said, presume goal and date are business driven.
      > >
      > > On 3/1/07, ryanpcooper <ryan.p.cooper@...<
      > ryan.p.cooper%40gmail.com>>
      > > wrote:
      > > >
      > > > What's wrong with me telling you I expect you to climb mount everest
      > > > in 3 hours, and expecting you to tell me how you are going to do it?
      > > >
      > > > ;)
      > > >
      > > > --- In extremeprogramming@yahoogroups.com
      > <extremeprogramming%40yahoogroups.com>,
      > > "Chris Wheeler"
      > > > <christopher.wheeler@...> wrote:
      > > > >
      > > > > What's wrong with setting a goal and a date, and expecting a team to
      > > > tell
      > > > > you how they are going to meet that goal and that date? Presuming
      > > > that the
      > > > > goal and the date are both driven by business needs?
      > > > >
      > > > > Chris.
      > > > >
      > > > >
      > > > > [Non-text portions of this message have been removed]
      > > > >
      > > >
      > > >
      > > >
      > > >
      > > > To Post a message, send it to: extremeprogramming@...
      > <extremeprogramming%40eGroups.com>
      > > >
      > > > To Unsubscribe, send a blank message to:
      > > > extremeprogramming-unsubscribe@...
      > <extremeprogramming-unsubscribe%40eGroups.com>
      > > >
      > > > ad-free courtesy of objectmentor.com
      > > > Yahoo! Groups Links
      > > >
      > > >
      > > >
      > > >
      > >
      > > --
      > > --
      > > Chris Wheeler
      > > chriswheeler.blogspot.com
      > > coach, programmer & practitioner
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >


      --
      --
      Chris Wheeler
      chriswheeler.blogspot.com
      coach, programmer & practitioner


      [Non-text portions of this message have been removed]
    • Steve Ropa
      Oh, darn. I was just thinking I should create a rule that automatically deletes anything that comes in! So close! Oh well. Sorting your email as it comes
      Message 119 of 119 , Mar 6, 2007
      • 0 Attachment
        Oh, darn. I was just thinking I should create a rule that automatically
        deletes anything that comes in! So close! Oh well.



        Sorting your email as it comes in is an excellent way to triage what is
        important, what can wait, and what just doesn't matter.



        One approach I learned as a stockbroker (albeit with paper instead of email)
        is to automatically sort everything that comes in into its proper folder if
        it has one. Anything left in the inbox can wait until you have taken care
        of all of the sorted mail. Then, once a month, just wholesale delete
        everything in the main inbox. If it wasn't categorizable (not a real word),
        and you hadn't already acted on it, it couldn't have been important anyway.



        Anyway, I can tell that I currently have enough slack, because I can spend
        time arguing the merits of an empty inbox..



        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of John Roth
        Sent: Tuesday, March 06, 2007 1:19 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] What is "bad" management?



        It depends on how you want to set up your workflow,
        and where the bottlenecks occur.

        One insight I've gotten from GTD is that, if you leave
        stuff in your inbox, it's got two rather bad effects.
        First, you go over it multiple times deciding whether
        it's something to be dealt with now, and second, it
        isn't where you need it when you're ready to deal
        with a project.

        That doesn't mean you clean out your mail client!
        If you want to hold mail related to a project on the
        client in a separate folder until you're ready to deal
        with it, that's fine. They have to be easily locatable
        from the central point of the project, and out of the
        way until then.

        John Roth

        ----- Original Message -----
        From: "Steve Ropa" <sropa@xavient. <mailto:sropa%40xavient.com> com>
        To: <extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
        yahoogroups.com>
        Sent: Tuesday, March 06, 2007 10:56 AM
        Subject: RE: [XP] What is "bad" management?

        > Which means we might have uncovered where I am not understanding. What is
        > it about my inbox that affects rapid turnaround on work effects?
        >
        >
        >
        > _____
        >
        > From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
        yahoogroups.com
        > [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
        yahoogroups.com] On Behalf Of Phlip
        > Sent: Tuesday, March 06, 2007 10:22 AM
        > To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
        yahoogroups.com
        > Subject: Re: [XP] What is "bad" management?
        >
        >
        >
        > Steve Ropa wrote:
        >
        >> These are a lot of good suggestions if an empty inbox is a goal you have.
        >
        > Then we are back to the "Lean" notion of rapid turnaround on work effects.
        >
        > --
        > Phlip
        > http://c2.com/ <http://c2.com/ <http://c2.com/cgi/wiki?ZeekLand>
        cgi/wiki?ZeekLand> cgi/wiki?ZeekLand <-- NOT
        > a
        > blog!!
        >
        >
        >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >





        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.