RE: [agile-usability] A crash course on Agile programming / organization?
- 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
Subject: RE: [agile-usability] A crash course on Agile programming / organization?
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.
Program Manager – Information Technology
From: Dale Emery [mailto:dale@...]
Sent: Tuesday, September 14, 2004 4:20 AM
Subject: Re: [agile-usability] A crash course on Agile programming / organization?
> 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
> 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 Emery, Consultant
Collaborative Leadership for Software People
The most serious charge which can be brought against New England
is not Puritanism but February. --Joseph Wood Krutch