There was a movement some years ago towards standardizing Federal Sentencing Guidelines. It succeeded and indeed looks about Olympian as the Ten Commandments. The rationale behind this effort had to do with the prejudices that a given environment (Jurisdiction or Circuit) may have towards the people who live within that environment. Minorities were consistently receiving harsher sentences than their Caucasian or more wealthy counterparts for the same offenses – particularly in certain areas of the country. This led to a Draconian, grid-style sentencing guidelines table and the mandate that if a judge departs from this set of guidelines they will have to defend their decision. Judges, after the mandates imposed by the Sentencting Guidelines, are no longer afforded a substantial measure of influence over the sentences they find. Judges became cogs in the wheel of Justice (yes, I know it is a scale, but work with me here). This is slowly breaking down with the United States v. Booker, and will ultimately become more agile. What is important to keep in mind is that the motivation behind standardized sentencing was the desire to eliminate the possibility of unfair treatment. Indeed, to the letter of the law, everyone gets treated equally. But is it always effective? Is it always appropriate to forego human factors, environmental factors, etc? Is a single methodology that removes the individual from the equation appropriate for the sentencing of individuals?
Is PMI or RUP or (name your PM buzzword) the right approach, always? Even under optimum conditions?
Needless to say, there are many who resist and resent the Federal Guidelines. What resulted was the “Let Judges be Judges” movement. It stipulates that a codified and pseudo-scientific sentencing approach does more harm than good; it eliminates the ability for special circumstances to be taken into account and for Judges to judge. This is over-simplifying a bit, because there are downward and upward departures, but the overall spirit of the Let Judges be Judges movement is that people are individuals and a crime is never committed twice – just like a project is never executed twice. Circumstances are dynamic and cannot be disregarded, deemed secondary to an overarching Guideline, or taken as less than the very essence of the situation.
In law, and in software, it is imperative that a blueprint is regarded as a guideline, not a mandate.
And so, with Agile Software Development, we have UML models that serve not to define the System, but to help us realize the System. The Agile Project Manager, once preoccupied with resources and tasks and WBS numbers and bars on Gantt Charts… becomes an advocate. They are not managing projects as much as they are acting as the catalyst for progress and the liaison for the client, the technical staff, and the stakeholders/product owner. They are the Quarterback, but they are also the Cheerleader. Yes, I am man enough to admit that.
This is a different kind of Manager. Soft skills are very important. Empirical data becomes more important that speculative data, and a PM must learn that although they might be the grease, there are no interchangeable parts to lubricate. One developer is not the same as another. The Mythical Man-Month is real. Finesse is as or more important than .mpp skills. It is hard to quantify these skills, but it can be done.
Under a more Agile roof, developers are given the freedom to make decisions about development. The artifacts that served as definitions now serve as visionary guidelines, and the people who existed to enforce methodologies (Procrustean, minus the torture) now enforce principles. Judges can be judges. Decisions are made by informed people within their domain of expertise.
While PMI and the like will speak of “continuous integration”, this is misleading (in my opinion) because it again assumes that a larger dictum is in fact, universally true. We all know that in complex software Systems, there is no final blueprint until the source code has been written. Software Engineering is not like Building Construction, and although the attempt to establish a toolkit that can accommodate any endeavor is admirable and would be helpful for sure, I submit that the toolkit itself assumes specific functions and constrains more than it assists. The Project Manager looks to their toolkit to manage projects. It is as simple as that. I have read more than a few posts by PMI or Rational PMs that vehemently deny the utility of an Agile approach. I can’t help but wonder if they are a bit worried that this Agile thing will continue to get traction and the PMP will not be the litmus test for HR anymore.
In Complex Adaptive Systems, the team organizes itself and adapts, often without outwardly discernible impetus or organization, in response to developments in the project or effort. Watch a flock of birds. A school of fish. The fans at a Yanni concert. These are large groups of individuals that move or act together without being told to and do so more effectively than if they had to follow a list of rules. Everyone breaks out a lighter and sways without being told to. If I have two and you dont have one, I give you one so you can be part of the magic of the Whole. The whole is important. The vision is important, and the Project Manager without her/his Gantt Chart may feel naked.
Software teams are Complex Adaptive Systems. The Project Manager serves to foster the product vision, remove obstacles, assist the individual team members, and play Captain Kirk, keeping the Prime Directive in mind at all times.
Let Developers be Developers. They know how to fix a problem with message queuing within a Host Integration Services project using WCF better than a PMP does. Why insert the PMP into the picture to break down into tasks and subtasks what the dev already knows and can be done with before the spec is written? Code, test, code, test, show, code, test, show, etc. Test-driven or feature-driven development will keep you safe.
Interestingly enough, and I will write more about this later, in science and the fascinating world of drug discovery, a test-driven approach to development is the norm. You could say it is the only way to do it. But I will get into this later. I need to quiz my wife (a PhD student in drug delivery systems) before I say too much.
It is very liberating to participate in an Agile development environment, and if you are lucky enough to have clients that are on board with the process, you can do amazing things. I am (partly) a Project Manager. I do not like Gantt Charts. I like CAS theory and Agile philosophy. If you have been reading my blog for any period of time, you will recognize that my beliefs are shifting. I maintain that requirements are valuable, and I still really dig UML (I can do Sequence Diagrams complete with 2.0 compliant pins that will knock your socks off, and Context Diagrams are just plain handy), but these are not artifacts forged from stone. They are not Olymipan.
Keep it Barely Good Enough, keep it useful, and allow talented people to do what they are talented at.
Viva Agilidad!
Okay, thats cheesy.
Be well,
Josh