-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
-
The Power of Process: How Bad Project Management Kills Great Ideas
February 7, 2012
The Degradation of Agile Project Management
June 23, 2009 | Author: PM Hut | Filed under: Agile Project Management, Project Management Musings
The Degradation of Agile Project Management
By Robert McIlree
It’s always easy to tell when something is resonating within organizations - and Agile is now firmly in that camp based on my experiences over the past two years. There is a tremendous amount of interest in Agile methods and many organizations are taking their first or second steps with it. On the surface, this looks great, but some of my experiences have led me to believe that Agile is thought of not as a different, solid approach to software design and development, but more (as I originally feared) as a silver bullet, completely misunderstood, or license-to-hack with little or no accountability for outcomes.
Herewith are a number of ‘incidents’ that I’ve recently observed or participated in:
- Regular loss-of-control-and-context in standup meetings, which at times make them drag on for hours. Scrum masters and PMs/facilitators must be vigilant in staying to the script, and taking issues off-line when necessary - and it very often is necessary. The result of not doing so is completely wasting uninvolved team members’ time. Think of it this way: if standups are routinely going for an hour instead of 15 minutes, usually for one team member’s issues, you are wasting 45 minutes of other people’s time X the number of uninvolved team members. If this occurs on a daily or near-daily basis, the amount of wasted time is huge. And, since you’re operating under iteration and timeboxing constraints, wasting team members’ time like this will cause iteration goals to be missed repeatedly, and perhaps kill your project. Take very-specific issues brought up in standup that don’t involve the entire team offline!
- “We’re going to ‘organizationalize’ Agile.” Which translated means “we’re going to superimpose our culture and previous practices into whatever Agile methods (or parts) that we’ve selected. Translated further, this means that what will be superimposed is a lot of politics and waterfall/SDLC when Agile doesn’t jibe with the existing organizational scheme - bad, bad move. Every time I’ve seen this happen, the projects involved are in trouble, and some have failed outright
- Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner.
- PMs, Scrum Masters, or Product/Business owners reverting to the term “Agile” when making decisions or taking action that are not, by any stretch, Agile. Examples: ignoring the self-directed team concept in Scrum by timeboxing work without consulting the team - which in reality is “make my date” project management - pick the date, work backwards to today, and tell the team when the work they are responsible for is due, regardless of team inputs, risks, or other schedules. Another example: assuming 100% dedicated team members and scheduling work when, in reality, the team members involved are not 100% dedicated because of other responsibilities they cannot get out of or pass to others. Finally, there are multiple product owners (ouch) that must come to consensus on stories and other direction - often quickly - and cannot or will not. The team is then left spinning their wheels waiting or worse, attempting to get some work completed by guessing what the stories/intent are - and the risk of being wrong is often high enough to cause a great deal of problems.
Based on these experiences and what I’ve been told by my students and colleagues, I get the strong impression that Agile is often used as an ‘excuse’ to advance a particular agenda. It’s usually mentioned as a ’selling point’ for projects - particularly to management and project sponsors/stakeholders to get projects approved and funded. It is also used for behaviors that are not Agile at all - when the PM who played the ‘make my date’ card on the project schedule was challenged in a meeting for not consulting with the people actually doing the work about the proposed dates, she replied, “Look, these are week-long iterations. It’s Agile!” No, it isn’t when the team isn’t involved; it’s ‘make my date’ and the consequent rectally-generated analysis that always follows.
My advice here remains the same as always: if you’re going to do Agile development - do it. Completely and without compromise. When I am challenged in my Agile classes about modifying Scrum or XP or FDD to ‘fit’ some organizational political or budget scenario, my answer is always the same: “If you do that, then you are not doing Scrum/XP/FDD/etc. You are doing something, but not Agile methods.”
And its always that “something” that leads organizations and groups who rationalize projects in this manner to fail.
Robert McIlree is a consultant and university lecturer/speaker specializing in enterprise architecture and project management. His blog can be found at http://enterprisearchitect.typepad.com/.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized