I have to admit, Agile is a topic that makes me want to flip tables or have a Lewis Black style stroke simply because I am super passionate about good project management. Project management takes the rap for many ills in the organization that it ends up highlighting, possibly for the first time.
First, an apology. I do apologize now for any bo-bo headed, clueless, mutant project managing wanker you may have worked with in the past. Maybe they were untrained and unskilled. Maybe they were a closet sadist. Maybe they had some point to prove. Who knows. That is not project management competence. It's not leadership. It's not productive. Nobody likes to be painted with that brush and the "PMs" who do behave that way embarrass the rest of us. They make our jobs harder because we have to climb over the mess they leave behind. Having said that, here are the two biggest things I hear over and over from Agile authors and speakers that are just wrong and project managers should no longer need to apologize or make amends for. (Except for this guy!)
I should preface the rest of my comments to say I'm not against Agile. I'm not against iterative or spiral models or methods. RAD, XP, Kanban, Scrum, Scrumban, Fragile, SAFe, all the flavors of Agile have their proper place in the world. What I am against is scape-goating project management to sell Agile as the ultimate cure-all for things taking too long. I came through web development/e-commerce movement in private industry during the 90s before Agile, and have seen many silver bullets to solve that problem come and go. There are several Agile perceptions that persist as PM Crimes Against Productivity, and I'll cover the two most egregious here as one person's attempt to straighten the record. This is not an invitation to convert me, sell me, or tell me off.
#1 PMs only practice 1950s style project management.
How many times have you heard PMs accused of "having only one plan and it is never allowed to change", and that's why you should do Agile? Truthfully, I haven't met a real life PM who does it this way since my dad retired from COBOL & Fortran coding in the mid-80s. I do run into dinosaurs who expect this kind of rigid & omniscient style of project management. When I do, it tells me they need to get out more often and understand how real life works. They also need to provide a serious pay bump to PMs for being able to tell the future. (If I could tell the future, I would be at high-stakes baccarat in Monte Carlo, not in this low-walled cubicle farm. If I could control the future, well get down and kiss my pinky ring plebe.)
The "no changes" technique is notoriously unrealistic as an end to end
project management approach. Even the strictest software development contracts with hard freezes have a provision for change orders. The PMBOK has a whole section on dealing with change. The US Military doesn't even manage projects this way. Please. Do us all a favor and drop it. Please stop perpetuating this myth, especially when talking to experienced PMs. Anybody who goes down this path has instantly lost credibility with me. My thought is "this yay-hoo has no idea what current practices actually are." There were gosh-darn-good reasons why scheduling was so rigid in the early days, just like there are good reasons it has to be - and can be - super flexible today.
#2 The @$%# Waterfall.
I wish I had a dollar for every anti-project management, anti-PMI, anti-PMBOK speech by some highly paid consultant accusing every IT PM of only ever using Waterfall, and that's Why Nothing Gets Done, and if you just hire our firm, we will Straighten You All Out! That's bull-nuggets. They get paid high dollars to stand at a podium and decry Waterfall Project Methodology, which is like blaming the Trix Rabbit. They quote each other and create an echo chamber of jibber-jabber. Even PMI has been forced to adopt this terminology. Just remember, there is nothing new under the sun kids. I'm sorry to tell you it's not a project management lifestyle choice we make at the PMI temple during the Blessing of the Charter or Festival of Resolved Issues.
There is no such thing as Waterfall Project Methodology. It's a myth. It's a made up concept by people who never actually read or understood the PMBOK knowledge areas or process groups and can make big bucks by convincing you the problem is project management versus complex cultural and systemic problems in the organization, missing processes, missing roles, and missing spines. Waterfall, in IT, is and only ever has been one of two things:
I'll write on the difference between a PM framework and SDLC another time. Confusing these two things is a huge pet peeve of mine. I ask about this distinction when hiring PMs.
The documentation & meeting work blamed on PMs
Back in the day, all system design was literally done on notepads by engineers who had really nice mechanical pencils and lots of erasers (my dad was one). It took ages to deliver by today's standards. Do you know why? Not because they were stupid or lazy. These were people who could play 3-D chess with you in their sleep, so I'll have no mainframe programmer abuse here. It was not the PM who made everybody do it this way. In a nutshell, the reasoning behind the Waterfall approach was to offset several key realities below. The PMs get the rap because the PMs had to make it happen and hold people accountable.
It wasn't possible to begin coding without all the requirements. For real. Nobody said "We need a platform agnostic, location aware mobile, Apple-watch friendly sock finding app that also connects people to other sock aficionados nearby in a fun way." Today, you can do a lot with just that much info. Back in mainframe's heyday, that was not useful information. Requirements elaboration took time because they had to be tight. The #1 crime in IT was to cause rework due to its steep cost. Requirements & specs created a lot of documentation because it had to. It took time because accuracy and precision were mandatory.
Back to the present. Nobody has actually run a shop this way in decades (I'm sure there are rare exceptions somewhere in a CMM level 5 shop, but I'm not talking about them). Nobody has run a project like this in decades. Continuing to bring this up as a PM crime against flow is foolishness. We don't congregate at PM bars inventing new kinds of long meetings to have or how to make documentation even more onerous than ever before. Congratulations Alice, you've increased documentation hours by 20% this quarter, beating our goal of 18%!
Reminder to myself to post about Rolling Wave & Iterative scheduling techniques.
Any PM who sets up an entire schedule with F-S task dependencies should be able to explain it and why other dependency options won't work. Finish to Start is not always a bad thing. Stop demonizing. I will do it on a milestone-only schedule when I'm trying to align multiple work streams or multiple projects at the same time. But it's not how the project schedule is actually administrated.
So there you have it. Now you know. Once upon a time, documentation and review meetings were not the PM's fault. There is no such thing as Waterfall Project Management. Go forth and spread the word. Project Managers are not the enemy of getting things done. And if you say "Waterfall Project Management" and hear a cracking sound, it's me rolling my eyes.
First, an apology. I do apologize now for any bo-bo headed, clueless, mutant project managing wanker you may have worked with in the past. Maybe they were untrained and unskilled. Maybe they were a closet sadist. Maybe they had some point to prove. Who knows. That is not project management competence. It's not leadership. It's not productive. Nobody likes to be painted with that brush and the "PMs" who do behave that way embarrass the rest of us. They make our jobs harder because we have to climb over the mess they leave behind. Having said that, here are the two biggest things I hear over and over from Agile authors and speakers that are just wrong and project managers should no longer need to apologize or make amends for. (Except for this guy!)
I should preface the rest of my comments to say I'm not against Agile. I'm not against iterative or spiral models or methods. RAD, XP, Kanban, Scrum, Scrumban, Fragile, SAFe, all the flavors of Agile have their proper place in the world. What I am against is scape-goating project management to sell Agile as the ultimate cure-all for things taking too long. I came through web development/e-commerce movement in private industry during the 90s before Agile, and have seen many silver bullets to solve that problem come and go. There are several Agile perceptions that persist as PM Crimes Against Productivity, and I'll cover the two most egregious here as one person's attempt to straighten the record. This is not an invitation to convert me, sell me, or tell me off.
#1 PMs only practice 1950s style project management.
How many times have you heard PMs accused of "having only one plan and it is never allowed to change", and that's why you should do Agile? Truthfully, I haven't met a real life PM who does it this way since my dad retired from COBOL & Fortran coding in the mid-80s. I do run into dinosaurs who expect this kind of rigid & omniscient style of project management. When I do, it tells me they need to get out more often and understand how real life works. They also need to provide a serious pay bump to PMs for being able to tell the future. (If I could tell the future, I would be at high-stakes baccarat in Monte Carlo, not in this low-walled cubicle farm. If I could control the future, well get down and kiss my pinky ring plebe.)
The "no changes" technique is notoriously unrealistic as an end to end
project management approach. Even the strictest software development contracts with hard freezes have a provision for change orders. The PMBOK has a whole section on dealing with change. The US Military doesn't even manage projects this way. Please. Do us all a favor and drop it. Please stop perpetuating this myth, especially when talking to experienced PMs. Anybody who goes down this path has instantly lost credibility with me. My thought is "this yay-hoo has no idea what current practices actually are." There were gosh-darn-good reasons why scheduling was so rigid in the early days, just like there are good reasons it has to be - and can be - super flexible today.
#2 The @$%# Waterfall.
I wish I had a dollar for every anti-project management, anti-PMI, anti-PMBOK speech by some highly paid consultant accusing every IT PM of only ever using Waterfall, and that's Why Nothing Gets Done, and if you just hire our firm, we will Straighten You All Out! That's bull-nuggets. They get paid high dollars to stand at a podium and decry Waterfall Project Methodology, which is like blaming the Trix Rabbit. They quote each other and create an echo chamber of jibber-jabber. Even PMI has been forced to adopt this terminology. Just remember, there is nothing new under the sun kids. I'm sorry to tell you it's not a project management lifestyle choice we make at the PMI temple during the Blessing of the Charter or Festival of Resolved Issues.
There is no such thing as Waterfall Project Methodology. It's a myth. It's a made up concept by people who never actually read or understood the PMBOK knowledge areas or process groups and can make big bucks by convincing you the problem is project management versus complex cultural and systemic problems in the organization, missing processes, missing roles, and missing spines. Waterfall, in IT, is and only ever has been one of two things:
2. A. Waterfall is a software development methodology
It was born out of engineering practices. There are now somewhere around 120 software development methodologies in Wikipedia. Reality is not either waterfall or agile. Neither is a choice as well. Many software methodologies are iterative and predate Agile by many years. The PMBOK doesn't care what you're building. A ship, a hospital, a clean water system for an entire country, a wind farm, or even a mobile gaming app to sell virtual socks. PMBOK is industry and technology agnostic. The PMBOK also doesn't care if you follow iterative cycles or not. There is no book on Waterfall Risk Management or Waterfall Communication Planning. You may notice nobody goes on speaking tours about Waterfall Project Integration and Waterfall Financial Management, or Waterfall Resource & HR Management. Who is the expert on Waterfall Procurement and Solicitation? A project framework is not an SDLC. Software development is not project management. Project management is just so much more than that narrow slice and should be understood that way.I'll write on the difference between a PM framework and SDLC another time. Confusing these two things is a huge pet peeve of mine. I ask about this distinction when hiring PMs.
The documentation & meeting work blamed on PMs
Back in the day, all system design was literally done on notepads by engineers who had really nice mechanical pencils and lots of erasers (my dad was one). It took ages to deliver by today's standards. Do you know why? Not because they were stupid or lazy. These were people who could play 3-D chess with you in their sleep, so I'll have no mainframe programmer abuse here. It was not the PM who made everybody do it this way. In a nutshell, the reasoning behind the Waterfall approach was to offset several key realities below. The PMs get the rap because the PMs had to make it happen and hold people accountable.
It wasn't possible to begin coding without all the requirements. For real. Nobody said "We need a platform agnostic, location aware mobile, Apple-watch friendly sock finding app that also connects people to other sock aficionados nearby in a fun way." Today, you can do a lot with just that much info. Back in mainframe's heyday, that was not useful information. Requirements elaboration took time because they had to be tight. The #1 crime in IT was to cause rework due to its steep cost. Requirements & specs created a lot of documentation because it had to. It took time because accuracy and precision were mandatory.
- Requirements were rigorously reviewed for gaps, conflicts, & faults. They were reviewed for completeness as well. Programmers won't guess at the intention. Too much is at stake.
- Requirements begat specs (also reviewed) which begat design, also done on paper. Design reviews were pivotal to suss out missed requirements and early problems. Every condition had to be handled. Every fault, every if, then, or, and else. Or else! This was how Function Point Analysis and Estimates were possible. You can estimate what you can count.
- The design was then turned into routines & sub-routine code hand written on paper. Code had the living daylights reviewed out of it for all the same reasons. Design and coding really couldn't overlap. It was impractical. Design changes caused code rework. Code rework caused delays. Sorry Don, I guess you are going to have rewrite what you've worked on for the past month.
- Code was turned over to key-punch operators to create hundreds or thousands of cards or paper tape for the job control code plus the program and all its sub-routines. A little change at this point had a monster ripple effect. There could be other kinds of code required that also had to be key-punched. Key-punch operator was a full time skilled job that also had the expectation of fast perfection. When was the last time you had to hand your code to someone else to key in and create physical media for it?
- Documentation and code had to be strictly controlled and very detailed for maintenance, support, and enhancements. Poor and sloppy documentation was the sign of a two-bit hack. The documentation was just as critical as the code and media it was on. Documentation was reviewed just as rigorously as the other assets.
- Computing time for testing was scarce and expensive so it was a resource to be minimized via reviews, in meetings. There was usually only one computer in the organization or university, so no team had their own dev or test environment until much later. Your team had to wait its turn behind the other system development teams. A select few were allowed to control the computer directly. You hand over your cards to the operator and wait for the output report and your card stack, possibly the next day. Don't drop the cards!
- The more bugs in testing, the bigger the impact to the entire rest of the team there was. They were also working ahead on the next batch of code. Mistakes were a fast way to become very unpopular. Lack of documentation means the junior programmer assigned to change or add onto something would have no idea where to really start working. Time is wasted poking around trying to figure it out.
Back to the present. Nobody has actually run a shop this way in decades (I'm sure there are rare exceptions somewhere in a CMM level 5 shop, but I'm not talking about them). Nobody has run a project like this in decades. Continuing to bring this up as a PM crime against flow is foolishness. We don't congregate at PM bars inventing new kinds of long meetings to have or how to make documentation even more onerous than ever before. Congratulations Alice, you've increased documentation hours by 20% this quarter, beating our goal of 18%!
2.B. Waterfall also means strict finish to start (F-S) dependencies between tasks.
Task A must finish before task B can start. That's it. PMI's scheduling practice does NOT teach this as the way to make a schedule. The idea is just ridiculous. Some tasks have to be this way because many things are sequential. (Receive materials, build thing; or Mix concrete, pour concrete; provision server, install app for example.) The scheduling practice teaches PMs to setup the tasks, hook up the dependencies (there are 4 kinds - S-S, S-F, F-S, F-F), put in resources and estimates, and then LOOK FOR EFFICIENCIES in the schedule and rearrange things to shorten the schedule and budget. You'll never get to green earned value status if you don't do this.Reminder to myself to post about Rolling Wave & Iterative scheduling techniques.
Any PM who sets up an entire schedule with F-S task dependencies should be able to explain it and why other dependency options won't work. Finish to Start is not always a bad thing. Stop demonizing. I will do it on a milestone-only schedule when I'm trying to align multiple work streams or multiple projects at the same time. But it's not how the project schedule is actually administrated.
So there you have it. Now you know. Once upon a time, documentation and review meetings were not the PM's fault. There is no such thing as Waterfall Project Management. Go forth and spread the word. Project Managers are not the enemy of getting things done. And if you say "Waterfall Project Management" and hear a cracking sound, it's me rolling my eyes.
Comments
Post a Comment