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

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

Expand Messages
  • Steven Gordon
    I suspect we differ on the definitions of things like goals and plans. Yes, if high level visionary goals are shifting, the business has a problem. What high
    Message 1 of 119 , Mar 1, 2007
    • 0 Attachment
      I suspect we differ on the definitions of things like goals and plans.

      Yes, if high level visionary goals are shifting, the business has a
      problem. What high level features will be in a release in 6 months is not
      going to change greatly (although it is not unusual for a feature to be
      postponed or thinned down due to time crunch, unforeseen issues or the
      discover of a more important feature). Exactly what those features entail
      is likely to change a bit. The specific bells and whistles will almost
      certainly change quite a bit.

      The business goals that the customer will be able to acoomplish with the
      software will change much less than the specific ways that the customer will
      be able to accomplish those goals with the software.

      When the product owner asks can if we can guarantee delivering X in 6
      months, my best answer will always be that we can only guarantee working
      software in 6 months with the most important features implemented. However,
      every 2 weeks we can:
      - provide a concrete demonstration of what has been produced so far,
      - use that to understand better what can be delivered by the due date, and
      - adjust what we undertake the following 2 weeks.

      Its a bit more collaborative than the "come back when you are finished"
      approach.

      Steve

      On 3/1/07, Chris Wheeler <christopher.wheeler@...> wrote:
      >
      > 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.
      >
      >
      >
      >


      [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.