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

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

Expand Messages
  • Steve Ropa
    The kind of feedback you are describing is upper management s dream. We can t stand a bunch of reports saying things are great until all of a sudden they
    Message 1 of 119 , Mar 1, 2007
      The kind of feedback you are describing is upper management's dream. We
      can't stand a bunch of reports saying things are great until all of a sudden
      they aren't.



      What upper management hates most, in my limited but not miniscule
      experience, is surprises. You don't get a lot of surprises in Agile. We
      really don't want to have control. I'm not saying there aren't high level
      managers who won't surrender the control, but for most of us there just
      isn't time to try to manage every piece of the pie like that. Between golf
      and vendor appreciation lunches, we would never get anything done! :-)



      Seriously, a goal and a date are not bad things. I can set a hard date 6
      months in advance and still be agile, as long as I recognize that the plan
      and the number of features delivered will change constantly. I'm not
      talking about gantt charts and silly stuff like that, but let me know what
      the backlog is, what the release plan is, and keep me appraised of progress.
      Give me the velocity and what is left on the backlog, and I can be happy.



      The Other Steve







      _____

      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Steven Gordon
      Sent: Thursday, March 01, 2007 3:35 PM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] The nature of executive "pushback" to agile technologies?



      Agile is about steering projects based on feedback and learning, so setting
      a hard goal and detailed plan for a date months in advance will not allow
      any agility.

      A goal and date is good, but the goal and the plan both have to be flexible
      enough to allow for frequent changes in course base on feedback and learning
      and external forces. For an upper management culture who thought that all
      the company's problems were just due to the people doing the work not being
      able to execute plans effectively and reliably, looser goals and plans seems
      sloppy and a surrendering of control rather than something that could
      improve the effectiveness of their workforce.

      In a command and control culture, the people at the top only get negative
      feedback about projects when they are already off the rails. So, to allow
      agility to work, not only does upper management have to allow control to
      trickle down to the people actually doing the work, but they have to be
      prepared to receive and judiciously respond to lots of project feedback with
      a lot more nuances than the feedback they used to get from status reports:
      "doing great", "doing great", . . . , "doing great", "90% done", "90%
      done", ..., "90% done", "late", "does not work", ...

      Steve

      On 3/1/07, Chris Wheeler <christopher.
      <mailto:christopher.wheeler%40gmail.com> wheeler@...> wrote:
      >
      > >
      > > (since they have been doing the right stuff all along). They still
      > > want to be able to set a goal and a date and get back a detailed plan
      > > for reaching the goal by the date and a commitment to making the plan
      > > work.
      >
      > 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]
      >
      >
      >

      [Non-text portions of this message have been removed]





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