This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Tuesday, September 23, 2003
PMI Congress Notes: Managing Software Development Using Extreme Programming (James Goebel) -- Original scope of on-time, on-budget, on-scope is rarely the right scope and rarely results in real project succes.
Kent Beck's simple strategy - Do more of what is working. Do less of what is not working. Perform experiments instead of guessing, measure results.
War room. Pair programming. The process is not intended to solve problems. It's intended to highlight them so that they can be addressed.
Fundamental culture shift, deviation from intention highlighted by comparison with extreme "practices."
Challenging thoughts...
Increase communications by having fewer meetings. (One meeting a day, from 8-5 -- working together. Brief (90 sec per person) daily status stand-up session plus all day interaction.)
Interruptions of bottleneck experts is desirable -- to spread knowledge. (fp - hmmmm...As I've suspected, confirmation that the team is the resource, not the individual; get more out of team by subordinating exploitation of sub-bottlenecks. Iteration is task (project?) Team is resource!!!)
Analysts as stand-ins for users. Answer programmers' questions in real time. (They're in the room, too.)
Work authorization a key component of project control.
Budgeting/Planning process - 1 sheet, 2 people for 2 weeks. Tasks 2 weeks or less.
Developers love to estimate, but fixed-bid commitment estimates get in the way. Clarity of story cards aids estimation (fp - equivalent to clarity of task definitions in CCPM) Update estimate everytime you do something -- you've learned something new.
Break unnecessary continuity!!! Spreads knowledge. Avoids loss of learning.
Completion criteria translates to tests. Must be testable. Write test first.
Effectiveness is not a natural outcome of being efficient. (very small font on big white slide)
Most important part of extreme programming is delivering early and often. A six month project is at least six phases, each delivering more and more of the solution.
Change is documented as storycards are changed, eliminated, and/ore replaced.
PMBOK Guide talks about products and services "progressively elaborated." Do something. Use results to learn and move forward.
Identify things that do not work well. Replace them with something else. Do not assume that the fix is more complex. Try simple experiments and measure results. Effective change often involves cultural change. Cultural change is scary, but you can succeed.
posted by Frank - Permanent Link -
|
View Frank Patrick's profile
