Bad Things I’ve Wanted to Say About Lean and Agile

Executives: “Lean” and “Agile” won’t fix a broken vision. Instead, when done right, it will make it glaringly obvious because “garbage in, garbage out” applies, same as it always did, only MUCH MORE SO and MUCH EARLIER. Moving away from “traditional” project delivery means much greater transparency which will highlight organizational dysfunction, broken customer relationships and confused product strategies, bringing them out in the open. If it doesn’t, you’re doing it wrong: Making these things visible so they can be continuously assessed, learned from and used to drive towards successful outcomes is what makes “Lean” and “Agile” work.

Product Managers: “Lean” and “Agile” won’t improve on the lack of focus and hit-and-miss results which come with opinion-based decision making. If Marvin in Sales has a great idea which will sell like hotcakes, then go work with Marvin to figure out how many hotcakes, at what cost in money and other opportunities and what it could mean for lifecycle profits. Look for experimental evidence, however incomplete, because it’s much better than guessing. If none is available, get some by doing simple experiments to validate assumptions. Experimenting takes courage because experiments can fail. If experimenting takes too much courage you’re doing it wrong because you aren’t experimenting safely. Experimenting safely means not betting the farm and not punishing failure. Not appearing to bet the farm is almost too easy. Not punishing failure and instead turning it into shared learning which is systematically leveraged as a competitive advantage is very hard.

Project Managers: “Lean” and “Agile” won’t help you dig more ditches faster. That’s because compared to digging ditches, status and progress of software projects is hard to see, side effect prone and more liable to reversals and sudden changes in direction. The latter have the potential to be essential for meeting your objectives or they can turn out to be utterly disastrous. You won’t be able to tell which one it is unless all your project’s stakeholders (including developers) share an economic, business value based frame of reference by which to make decisions. If this frame of reference doesn’t exist and/or isn’t communicated and/or you do not wish to delegate decision making, you will feel tempted to centralize, plan top-down and verify and audit outcomes for alignment with the plan. If you do, you will only be making feedback cycles longer, thereby limiting opportunities to adapt to change. As a result, you will be forced to choose between “locking down” features so you don’t have to deal with change and longer timelines so change can be accommodated. In complex environments with variability the resulting compromises lead to long delivery timelines and/or products unable to adapt and evolve in a competitive marketplace. It seems futile to try the centralization / pre-planning experiment again because the outcomes can be predicted with a high degree of accuracy. The results have been reproduced many times, by numerous experimenters in many kinds of different organizations. The most comprehensive attempts were the centrally planned Soviet bloc economies of the 20th century.

Developers: “Lean” and “Agile” won’t fix bad code. The fastest way to build complex software is to do it right. Most software is complex. Doing it right means building discreet, single-purpose components (… classes, services, methods, blocks of code in a transaction script, whatever …) with low coupling and a high degree of cohesion, with consistent levels of abstraction and well-understood interfaces between them. If you don’t think so because that’s not how it worked when you tried it or if you don’t know what these things mean then you have yet to master the fundamentals of your craft. I don’t care how many years you have been slinging code and what your job title is. You are a beginner, in thrall to an IT industry so broken that it’s possible to spend years in shops where no one ever experiences the productivity gains which come from well-made, supple, fit-for-their-purpose, easy to maintain software applications. The notion that complex systems are best assembled from easier to understand and managed subassemblies has been validated by generations of engineers before you, going back at least to the beginnings of the industrial revolution. As a result, you won’t need to fiddle with the carburetor of your car in order to install a new stereo. The power windows won’t go up and down when you step on the gas. Having seat belts and fan belts doesn’t mean they live in a shared belt subassembly. That’s what good software is like.

About the Author: Robert Reppel first quit his day job and started doing software full-time more than 25 years ago. He is by now thoroughly co-opted.

Comments are closed, but trackbacks and pingbacks are open.