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

RE: [agile-usability] A crash course on Agile programming / organization?

Expand Messages
  • Chris Pehura
    One time there was this project always missing it s deadlines. Reason was no visibility for all tasks and activities. They would make visible bug fixes, but
    Message 1 of 19 , Sep 14 9:02 AM
    • 0 Attachment
      One time there was this project always missing it's deadlines. Reason was no visibility for all tasks and activities. They would make visible bug fixes, but not maintenance to cleanup architecture. Once all tasks were made transparent, the deadlines were adjusted and easily met.
       
      This all started a few years back when the execs questioned the department "it was already built, why are you building it again?". Rather than answering the question, the department hid activities.
      -----Original Message-----
      From: Mike Dwyer [mailto:mdwyer@...]
      Sent: Tuesday, September 14, 2004 7:48 AM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] A crash course on Agile programming / organization?

      Dale;

      I have found that Mary Poppendeck’s book “Lean Manufacturing” has several great ways to not only map the team, but also map the entire Agile Food Chain.  People (team members, leadership, management, as well as administration) buy in because it is so transparent.  It is also a good starting point for budget and Sprint planning, as it makes visible the functional value of many ‘non functional’ tasks that can be hard to move up in priority and funding.

       

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

      Mike Dwyer

      Program Manager – Information Technology

      American Healthways

      -----Original Message-----
      From: Dale Emery [mailto:dale@...]
      Sent:
      Tuesday, September 14, 2004 4:20 AM
      To: agile-usability@yahoogroups.com
      Subject: Re: [agile-usability] A crash course on Agile programming / organization?

       

      Hi Chris,

      > Steps I do to establish buy in for workflow changes are
      > 1. formalize the current workflow (usually use diagrams
      > dependent on what the team considers useful)
      > 2. establish metrics for each activity for each component
      > (based on historic numbers)
      > 3. make it very visible to the team, and keep asking for
      > feedback
      > 4. ask for team's permission to make it visible to their
      > direct manager, and keep asking for permission right up the
      > food chain.

      I've found that #1 is usually enough to motivate a team.  I've
      helped dozens of teams diagram what they're currently doing.
      Every time, before they've described much of what they're doing,
      the team sees lots of ways to make improvements.  Simply
      describing the current process /as a team/ makes certain kinds of
      flaws so glaringly obvious that the team wants to jump
      immediately into fixing them.  The motivation to change the
      process is usually so strong that it's a struggle to finish
      describing the current way.

      Dale

      --
      Dale Emery, Consultant
      Collaborative Leadership for Software People
      Web:    http://www.dhemery.com
      Weblog: http://www.dhemery.com/cwd

      The most serious charge which can be brought against New England
      is not Puritanism but February. --Joseph Wood Krutch




    Your message has been successfully submitted and would be delivered to recipients shortly.