I have been trying to expand my understanding of some of the newer PM and software development methodologies, Agile, XP, Scrum, TOC, etc. To that end I found this document at the CCPace website called Agile Project Management.
I was troubled by some of the assumptions that it makes about what it calls "traditional" project management. I was also troubled by the obvious derision the authors have for managers and project management as it has been practiced in the past (and contrary to their hopes, in most places in the present). "Traditional" project managers are "mechanistic", "Uninspired Taskmasters. Project Management has a "tendency towards slavish process “compliance” as a means of project control" and provide "a false sense of security that management was 'doing something' by exhaustively planning, measuring, and controlling."
The paper continually places management and 'the technical community' at odds with shots like: "While managers designed traditional methodologies in an effort to control projects, the technical community gave birth to agile methodologies in response to their frustrations with traditional management (or lack thereof) and the resulting impact on their products and morale."
The lowlight of this paper was this paragraph:
Regardless of the particular methodology, the traditional project manager is often seen as a “taskmaster” who develops and controls the master plan that documents (often in excruciating detail) the tasks, dependencies, and resources required to deliver the end product. The project manager then monitors the status of tasks and adjusts the plan as necessary. Underpinning this mechanistic approach is the assumption that equates individuals to interchangeable, controllable commodities.
Over the last 5 years I have worked with 20 or 30 software development organizations that nearly all used 'traditional' project management practices. NONE of them had anything close to an "assumption that equated individuals to interchangeable, controllable commodities." Sure for the sake of downstream planning there were several that used an analysis of what kind of developer might be needed on a project that was coming up in the mid to long term future but these were by no means viewing all resources as the same.
The paper goes on to say:
Traditional management theory assumes that:
○ Rigid procedures are needed to regulate change
○ Hierarchical organizational structures are means of establishing order
○ Increased control results in increased order
○ Organizations must be rigid, static hierarchies
○ Employees are interchangeable “parts” in the organizational “machine”
○ Problems are solved primarily through reductionist task breakdown and allocation
○ Projects and risks are adequately predictable to be managed through complex up-front planning
"Rigid procedures are needed to regulate change"
Well if 'Rigid procedures" means documenting the change so that it can be verified that the change was made then I agree I guess. How do you know the change was made unless other people know it needed to be made?
"Hierarchical organizational structures are means of establishing order"
Im not sure where these guys worked before they found the Agile religion but it was certainly a sad, sad place! :-) Hierarchies exist in all organizations regardless of the Agile utopia that the authors talk about. At some point someone on the Agile dev team has to report status to someone. Most PM organizations I ever worked with had managers and project managers but it was not as if the PMs were walking around with stop watches and clipboards timing the developers.
"Increased control results in increased order" and "Organizations must be rigid, static hierarchies"
Again, Im sad for the authors that they worked in such a place but none of the software development organizations I worked with were so into static hierarchies or increased control that it would rise to the level of an assumption of the system. There were semi-static hierarchies in that the development manager always reported to the same VP position and certain devs generally resided within the same organization but it was not as if it was this way as a means of control.
"Employees are interchangeable 'parts' in the organizational 'machine'."
None of the 20 or so dev orgs that I worked with had this assumption and neither have the other 50+ non-software organizations I have worked with. This is not an assumption of traditional PM it is the sign of a terribly broken organization. Im sure that there are orgs out there like this but they are like this NOT because they use traditional project management methods but rather because they have a fundamentally flawed way of dealing with their workforce.
"Problems are solved primarily through reductionist task breakdown and allocation"
I don't know of any traditional PM methodology that solves problems through 'reductionist task breakdown'. Now lots of them do chop the work into smaller and smaller parts as a way of being able to more easily track how much of the project is done and to help figure out which parts need to be completed in which order but I assume that Agile methods have a similar function as well. I would assume that Agile does not work like this: A customer says "I want a CRM system" and the dev team says OK and they put 10 devs on it and they all just start coding and exactly on time a CRM system is born. Maybe it does work that way I don’t know but I figure that at some point there is a requirements gathering (likely several of them, in iterations) that define what has to be built. Then it is defined by the team the different components required to build that 'thing to be built". That sounds a lot like a "reductionist task breakdown" to me. If the problem the authors have with this is that in traditional PM they think that the PM is the one doing the breakdown in a vacuum then I have solved their problem: they had a bad PM! If they had a PM that was breaking down the tasks into a WBS without talking with the team (and not just talking but REALLY sitting down and working out the breakdown) then they were just a bad PM. This goes for if you are doing iterations or waterfall. Most PMs don’t have the full technical skills to fully breakdown a complex project of any kind. If they do they are likely kidding themselves. Good PMs start their WBS process in a working group of experts on the subject (the team in most cases).
"Projects and risks are adequately predictable to be managed through complex up-front planning"
This is again assuming the presences not only of a pure 'Waterfall" methodology but also another case where a bad PM is to blame, not the PM method used. If you have a PM that plans the whole project up front and then does not change it based on changing realities as the project progresses then you have a bad PM not a bad method. If you have a PM that is doing risk analysis one time before the project starts then go to www.monster.com and post a job opening because you have a bad PM. If you have a project with rapidly changing requirements and the PM picked a waterfall methodology for the management of the project then you have a bad PM (or at least an ill-informed one).
The paper blames a misunderstanding of what Agile methods really are for why adoption has not been as fast as they might think. This may be true as I do think that Agile, XP, Scrum ,etc have some VERY valuable points to make about delivering good software but I find it ironic that they would say this given that their paper is so full of their own misunderstandings of "traditional" PM. Their characterization of 'traditional' PM and it's practitioners as "mechanistic", "slavish" and devotees of Taylor's scientific management theories may have a part in the slow adoption as well. How willing will anyone from the 'traditional' world of PM be to what you have to say if you say it in such a way as to ridicule and debase the things they now hold dear. You are trying to convert people to a new way of life. You don’t do that by telling them they are bad. You do it by showing them how doing something else might be better.
That said I do think there are huge benefits in much of what this paper has to say. It's underpinnings in complexity theory as a means of better dealing with, well, complexity have obvious benefits. Pair programming and the Agile\XP call for more serious and meaningful customer involvement in the requirements and development process seem more than obvious to me as a way to improve quality and customer satisfaction. Im no where near far enough along in my studies of these methods to have anything more meaningful to say about them in particular but I am still troubled at the way this paper characterizes the methods I do know enough about. As I continue to grow my understanding I will come back to these topics and try to expand my thoughts on these methods.