The Regenerate Web
facilitating the regeneration of software teamsNavigation
User login
Syndicate
Services
Project
Browse archives
| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
Analysis
Staff
Who's online
There are currently 0 users and 0 guests online.
Is there such a thing as "Agile Project Management"
Glen Alleman of Herding Cats has been blogging about "agile project
management" - and mostly I would agree with him. Agile
project management is mostly wrapped up in a software development
lifecycle, and doesn't really apply to projects dealing with in the
domains of construction, engineering, or the like. I also
agree that agile project management is a misnomer, because it misses
many of the aspects of project management altogether. On the
otherhand, it is more than a means of fulfilling certain project
management activities, because it attempts to alter the conversation
with the customer.
OK Glen, so perhaps by your definition, I am not an agilist. However, I suspect that your statement about agilist's abandoning planning, and scheduling are unfair.
When I started to investigate agile "practices", it was primarily a reaction to the culture of the organization that I was in, and a particular fixation with the schedule. My experience with software development projects as a practitioner (software developer/requirements engineer/analyst/designer) revealed that once the schedule was proposed, all discussion of value delivery stopped. As project lead, my job became to delay the proposal of schedules until all of the scope decisions had been made. Because the schedule was fixed, we weren't free to re-sequence delivery, we couldn't dynamically swap one valued feature for another. We were required to adopt a "change control" mentality that effectively blocked out change at any time in the lifecycle after the schedule was proposed, because any change would cause the schedule to move. Management was completely fixated on the schedule. I have blogged about this phenomenon before.
What I found with agile practices was not a solution to all of the problems of software development (agile does not help you design a user interface), nor a comprehensive solution to the problems associated with software development projects. What I found was a different way of framing the value/scope/schedule discussion, so that I could fix the schedule in smaller chunks (iterations) and the business could continue to evolve their priorities without imposing change on the current fixed portion of the schedule.
So, now agile has devolved into XP+Scrum, and the rest of the practices that were agile, have sort of gone their way, there are many people who are "post-agile" - those that embraced the agile practices, understood them for what they are, and adopted those that added value to their work. As I work in the financial industry, I have had to adopt a more "enterprise-friendly" set of agile practices. But the benefit of being able to have a continuous conversation about scope, priorities, and value deliverywith your customer and user community, is that one can deliver value in smaller chunks, much more frequently, and this mitigates the risk of DAO (delivered already obsolete) software, or having your project cancelled before you delivered anything (I have lived through both).
Lemme rip into another statement you made casually in a previous post called more statistics.
OK Glen, so perhaps by your definition, I am not an agilist. However, I suspect that your statement about agilist's abandoning planning, and scheduling are unfair.
When I started to investigate agile "practices", it was primarily a reaction to the culture of the organization that I was in, and a particular fixation with the schedule. My experience with software development projects as a practitioner (software developer/requirements engineer/analyst/designer) revealed that once the schedule was proposed, all discussion of value delivery stopped. As project lead, my job became to delay the proposal of schedules until all of the scope decisions had been made. Because the schedule was fixed, we weren't free to re-sequence delivery, we couldn't dynamically swap one valued feature for another. We were required to adopt a "change control" mentality that effectively blocked out change at any time in the lifecycle after the schedule was proposed, because any change would cause the schedule to move. Management was completely fixated on the schedule. I have blogged about this phenomenon before.
What I found with agile practices was not a solution to all of the problems of software development (agile does not help you design a user interface), nor a comprehensive solution to the problems associated with software development projects. What I found was a different way of framing the value/scope/schedule discussion, so that I could fix the schedule in smaller chunks (iterations) and the business could continue to evolve their priorities without imposing change on the current fixed portion of the schedule.
So, now agile has devolved into XP+Scrum, and the rest of the practices that were agile, have sort of gone their way, there are many people who are "post-agile" - those that embraced the agile practices, understood them for what they are, and adopted those that added value to their work. As I work in the financial industry, I have had to adopt a more "enterprise-friendly" set of agile practices. But the benefit of being able to have a continuous conversation about scope, priorities, and value deliverywith your customer and user community, is that one can deliver value in smaller chunks, much more frequently, and this mitigates the risk of DAO (delivered already obsolete) software, or having your project cancelled before you delivered anything (I have lived through both).
Lemme rip into another statement you made casually in a previous post called more statistics.
"The traditional agile
approach is to push these questions to the
customer, then use velocity or some other "driving in the rear view
mirror" approach to inform the customer how much money has been spent
and how many features made it into the current release. All interesting
things to cost accountants. But not that useful for forecasting the
credibility of the plan, compliance with the "not to exceed" budget and
the probability of fulfilling the business case on the "go live" date."
The planning/tracking approaches that I have been promoting fall
directly in the path of forecasting the credibility of the plan,
compliance with budget, but not the probability of fulfilling the
business case on live date - unless you wish to consider work moved out
of scope to comply with a schedule or budget. Perhaps what
you are missing is the connection between velocity and distance to the
target. By taking weekly snapshots of resource burn, distance
to the target, and velocity of the team, we can create a very
credible forecast. Any planning/tracking approach, is based
on metrics that ought to be designed to corner the truth of our status
with some certainty (or very little wiggle room).
The problem with these or any other metrics, is that when there are no adjustments to be made on the race car, the metrics only tell us that we are going to lose the race. When your budget cannot accomodate any additional resources, your dates cannot slip, there are two choices - reduce value delivery, reduce quality, or both. What the agile practices do better for software projects is to move initial value delivery (and the conversations that go with it) earlier in the lifecycle.
The problem with these or any other metrics, is that when there are no adjustments to be made on the race car, the metrics only tell us that we are going to lose the race. When your budget cannot accomodate any additional resources, your dates cannot slip, there are two choices - reduce value delivery, reduce quality, or both. What the agile practices do better for software projects is to move initial value delivery (and the conversations that go with it) earlier in the lifecycle.