Received Knowledge, Fanaticism, and Software Consultants

Professor Harold HillBack in the 70’s and 80’s, when I was a young coder, you could generally group programmers into two camps: those who thought that the GOTO statement was evil (including such luminaries as PJ Plauger and Edsger Dijkstra), and those who thought it was perfectly acceptable, when used responsibly (such as algorithm guru Donald Knuth). Of course, by the late 80’s, we were all migrating to object-oriented languages, and the notion of structured programming seemed … quaint. Objects were going to free us from the anarchy of procedural code, just as relational database management systems freed us from whatever-the-Hell we’d previously been tinkering with.

But a funny thing happened on the way to high-quality code: bad coders. Oh, there were always bad coders. We simply pretended that the problem was our choice of programming paradigm, and that Bjarne Stroustrop’s preprocessor would suddenly make lousy C programmers into great C++ programmers.  Of course, it didn’t.  So some other coders-in-denial created Java, with the intent of encapsulating great code into packages that could be called by lesser practitioners. It was an incremental improvement, but it opened the career door to many more programmers. And many of them were also bad coders. IDC recently estimated that there are now eleven million professional programmers in the world, and nearly eight million more that they refer to as “hobbyists.” Not me; not any more. I moved on, a long time ago. I just got tired of repairing the software equivalent of a film by Troma Studios – as one critic memorably put it, “dogshit with sprocket holes.”

“Ninety percent of everything is crud.” Theodore Sturgeon

The rise of Agile methods, as they are now called, began well before the 2001 conference in Snowbird, Utah that produced the Agile Manifesto. Scrum and Extreme Programming were in wide use, even as we were correcting old dogshit code in preparation for the year 2000.  The serious improvements came from XP’s pair programming and test-driven development. As long as you didn’t pair two bad coders, you got better code, and eventually, better coders. Then came Snowbird, and the Manifesto, and the Agile Coaches. And the obvious Pareto-truth, that 80% of the bugs were being inserted by 20% of the coders, was papered over in favor of Yet Another Salvation Myth.

Instead of focusing on the coders, the consultants wanted us to focus on how we organized, and planned our work. It wasn’t the coders’ fault that their code sucked – it was the way they were being managed.  The words “traditional” and “waterfall” became epithets, used to describe the reactionaries who would have us focus on code quality, rather than methods. The new word was “refactoring,” which sounds less judgmental than “we have to replace this unmaintainable, write-only, dogshit code.” Yessir, the real problem was project management, and (lately) this fixation on providing cost and schedule estimates. And all of these proof-free assertions fed on each other, until it seemed like you weren’t a real Agile coach unless you dismissed project management, not just for coders, but for all human endeavors. I recently had the temerity to say I wouldn’t want to fly in a commercial aircraft designed using Scrum, and was tut-tutted by a True Believer who reminded me that many modern software practices have their roots in auto manufacturing practices. Not “design,” but “manufacturing.” Egad, have you even read The Scrum Guide?

So I got quite a chuckle this morning out of Nick Pisano’s rebuttal to Neil Killick’s recent expansion of the War on Management, demonizing the “traditional” software contract. It’s bad enough that Neil and his fellow Accusers insist that any approach they don’t like is “command and control;” now they’re going to prepend “traditional” to software contracts? Intolerable! Nick shredded Neil’s assertions, admirably. I was still laughing when I sat down to write this, late in the evening.

To be clear: I embrace the values in the Agile Manifesto, as do most software project managers. I embrace Scrum, as an effective method of organizing small teams of software developers to deal with uncertainty. I follow Neil’s blog, and Tobias Meyer’s, and several other Scrum-lord blogs. They know a lot about Scrum, and modern methods. That they are wrong about other things is immaterial. I have no problem with them dispensing received knowledge and calling it science. Of course, I feel no particular sympathy for the lousy coders who find affirmation in their anti-PM blather, nor for their more skilled colleagues who enable their inability by cleaning up after them. As long as the ratio of chaff to wheat is tolerable, I have no objection to separating them.

But I fear that, until the competent software developers address the real problem – bad coders – we will still be fixing dogshit code, under one procedural name or another, for a very long time to come (“Technical debt?” Coder, please …). And since I am a project manager, I have to point out that these competent coders are thus assuming a risk they could easily avoid, if only they weren’t in denial.

New PM Articles for the Week of March 24 – 30

Cartoon News ReadersNew project management articles published on the web during the week of March 24 – 30. We read all of this stuff so you don’t have to! Recommended:

PM Best Practices

  • Glen Alleman takes aim once again at poor estimating practices.
  • Anna Erdmanska asked her network for ideas on how to create positive energy on a project. She distills it all down to twelve points.
  • Michael Shaye warns of the “secret stakeholder,” perhaps the boss of the person you thought would be the approver.
  • Michel Dion notes that getting support for your project requires leadership.
  • Neil Pragnell tells why he carries a message from a fortune cookie in his wallet. “You are far more influential than you think.”
  • Daniel Burrus explains what it means to lead by anticipating.
  • John Goodpasture notes the impact of “prospect theory” on self-esteem and drives different performance in different groups.
  • Gina Abudi advocates the importance of effective communications in keeping control of our projects. Part two looks at reporting status.
  • Bart Gerardi shoots down the value of the “stoplight” status with the Watermelon Project: green on the outside, oh-so-red on the inside.
  • Allen Ruddock looks at cost overruns in small to medium-sized projects, and finds a few simple preventive steps we can take.
  • Shim Marom concludes his series on the business case with a summary of a research paper, “Building Better Business Cases for IT Investments.”

Managing Within Our Neuroses

  • Kerry Wills extols the virtues of the neurotic project manager.
  • Ian Whittingham explores the virtues of channeling our anxieties, when sorting out a complex project.
  • Martin Webster has a checklist of activities for avoiding stress at work.
  • Michael Lopp offers some practical advice for business travelers with OCD. Ah, it’s good to be a migrant computer worker …
  • Elizabeth Harrin pauses from her project manager and mother-of-two duties to note that we have to prioritize, accept our limitations, and adjust our expectations in order to prevail.
  • Kevin Korterud recounts the warning signs that the risk level has exceed our tolerance level.

Agile Methods

  • Steven Crago has some thoughts on integrating work products from a mix of Scrum and Waterfall teams.
  • Pawel Brodzinski: “Let me make a bold observation: neither Agile nor Lean seem to be making a difference… adopting practices and tools is simply a cargo cult.” Wow!
  • Dave Prior interviews Peter Saddington, who tells what he learned while pursuing the SAFe framework credential. Just 19 minutes, safe for work (if not SAFe).
  • Mukesh Rao recalls his experience spinning up a new Scrum team, estimating work using the “Ideal Days” method described by Mike Cohn in “Agile Estimating and Planning.”
  • Mike Cohn notes that three roles must be participating in planning poker, even if two of them aren’t asked to share their estimates.
  • Adrian Fittolani shares his list of favorite “non-Agile” books for those who want to practice Agility. If you haven’t read at least one of these, shame on you!

Enjoy!

New PM Articles for the Week of March 17 – 23

NewspapersNew project management articles published on the web during the week of March 17 – 23. We read all of this stuff so you don’t have to! Recommended:

Innovation

  • John Bauer provides a history lesson and some predictions on the evolution of corporate IT, their relationship with the business, and everything-as-a-service.
  • Peter Bruzzese sees the end of on-premises IT, as we move everything to the Cloud.
  • Ammar Mango examines the intersection of innovation and project management.
  • John Goodpasture suggests that when the evidence doesn’t indicate a clear course of action, you should make an informed judgment.
  • Bruce Benson observes one key project management lesson from ObamaCare is “Try something new.” Just providing an alternative can sometimes drive innovation.
  • Elizabeth Harrin provides her round up of project management news for this month.
  • Lyndsey Gilpin shares photos and stories of the women who created the technology industry: Ada Lovelace, Grace Hopper, Hedy Lamarr, and more!

PM Best Practices

  •  Vicki Wrona shares best practices for effective brainstorming, including a technique called Reverse Brainstorming.
  • Brad Egeland presents his approach to planning and conducting meetings that are productive, organized, and effective.
  • Graham Oakes examines risk management from the perspective of the trigger point, e.g. when the probabilistic risk event actually occurs.
  • Martin Webster presents a slightly facetious case for avoiding blame by avoiding risk.
  • Coert Visser explains why it seems like other people succeed so easily, when we have to work so hard. Short answer: we’re mistaken about how much it takes.
  • Cheri Baker models three short examples of pushing back.
  • Cesar Abeid interviews Dave Stachowiak on how to manage, lead, and influence without authority. Just 57 minutes, safe for work.
  • Srinath Ramakrishnan summarizes five change management models.
  • Glen Alleman extracts key points from James Dewar’s “Assumption-Based Planning.”
  • Andy Jordan recommends that we partner with the customer to select the right project execution approach (Agile vs. Waterfall).
  • Anne-Marie Charrett refutes the “waterfall is never the right approach mindset,” by debunking the most common memes.

Agile Methods

  • David Clarke explains why SaaS provider Workday has moved to a single codeline model for continuous development and release. Read this one twice!
  • Dave Prior interviews Dr. Sallyann Freudenberg on the psychological basis for the effectiveness of pair programming. Just 15 minutes, safe for work.
  • Mike Cohn explores the subtle differences in two definitions of velocity.
  • Clinton Ages explains how his business analyst skill set best fits in with a Scrum team.

Governance

  • Shim Marom begins a series on IT investment, with the need for a business case.
  • Emanuele Passera begins a series on portfolio management, using rigorous financial analysis.
  • Henny Portman provides a bullet list of questions to ask about the actions of the project owner before replacing the manager of a troubled project.

Enjoy!