Agile practices are a triumph of marketing:  Who would want to admit that they are not agile?  (There’s even an Agile Manifesto — programmers of the world, unite!)

As software has become an essential component of modern life, the demand for software continues to grow, and the methodology of the day is Agile.  Widespread adoption meana Agile software development practices are now spreading into general business, as mentioned in my recent post concerning business transformation at GE and elsewhere.  (Speaking of my old employer GE, when was the last time you saw a global firm advertising nationally to hire programmers?  Another sign of the times.)

But because Agile is a set of best practices, not a prescriptive methodology, no two companies perform Agile development in the same way.   And for a very good reason:  Our job as software managers within a particular company and industry is to adopt the practices that make sense for our business today.  One size does not fit all.

Here’s my list of the Agile practices which are most proven, most over-hyped, best ignored, and what Agile won’t help you with at all:

Good Agile Practices:  Just Do Them.
  • Short daily meetings by co-located teams.  Good software teams combine brains, mutual trust and high bandwidth communications.
  • Short sprints, task boards, burn down charts.  Makes team productivity much more visible and therefore manageable.
  • Time-boxing.  Keeping sprint duration constant encourages teams to meet commitments even when the going gets tough.
  • Scope freeze.  Product owners changing requirements mid-development is the bane of productivity.  
  • Always have working software every sprint.  Makes progress visible to team and product owners alike.
  • Test-driven development.  Avoids the most common coding short-cut and form of technical debt:  No regression tests or automation.
  • Continuous integration.  Confirm that all software components always fit together to avoid schedule slips.
Over-Hyped Agile Practices: Exercise with Caution and use Common Sense.
  • User stories.  Narratives are a useful tool for general understanding, but a poor substitute for requirement methodologies such as UML or any number of other techniques essential for mission critical engineering.  Especially inappropriate for non-functional requirements like scalability, extensibility, etc.
  • Self-organizing teams.  A poor substitute for a good manager. 
  • Working at a sustainable pace.  Nice in theory, but ignores the business, economic, social, and personal issues that managers are paid to resolve.   Another attempt to skirt the need for management.  
  • Open space work plans.  If you pay someone to concentrate and think, why put them in the middle of guaranteed distraction?
  • Pair programming, shared code ownership, cross-functional teams.  Ignores the significant differences in skills and expertise required; yet more attempts to pretend managers are unnecessary.
  • Minimal viable product.  A vague concept beyond the self-evident “why would anyone develop more than necessary?”  Usually includes invidious comparisons to Microsoft products.
  • Minimize documentation.   Can inhibit cross-functional understanding of what’s going on, delaying deployments or go-to-market.
  • Refactoring.  Software needs to be rewritten when core assumptions and requirements change, but practiced without good judgment, can lead to unnecessary rework, and a lack of design for reusability.
Just Plain Bad Ideas:  Spike These.
  • Agile encourages a lack of up-front anything (ready-fire-aim).  What’s so wrong with thinking carefully before you act?  Fast-thinking tends to be emotional vs slow-thinking more logically.
  • Deprecates planning of all sorts.  How many open-ended budgets and schedules have you been given in your career?  That’s what I thought.
  • Deprecates research in favor of immediate activity and experiential learning.  What’s so wrong with trying to avoid other people’s mistakes?
  • Deprecates architecture in favor of user function, and assumes that long-lived foundations are easily changed without cost.  Would you build the house first, then work on the foundation?  Be sure you want a mobile home.
Left Out Entirely:  You are on your Own
  • There is no methodology for large programs built using multiple agile teams.  Most companies create a “scrum of scrums” and/or attempt to track dependencies via Kanban boards, but it’s a poor substitute for good project or program management.  (There is a process called Nexus, but without much adoption that I know of.)
  • There is no practice for agile systems integration, especially between firms.
  • Anything to do with HR, profit and loss, budgets, contracts, hiring, training, managing-up, and all the other constraints that real world managers have to deal with daily.  


Software development has always been an expensive and error-filled activity rife with waste and confusion and miscommunication — and that’s before the software is released into the wild.  From it’s earliest days, software development managers have worked to lower cost and improve the quality of code.  But the nature of software is such that there is never going to be a silver bullet that solves all of the ways software development can go south.  

Especially with business people whose understanding of software development is glib, naive or overly optimistic, keep these points in mind:

  • Agile is not a cost optimized methodology.
  • Agile works poorly with fixed schedules.
  • Fast moving Agile projects get stuck easily when dependent on slower moving business processes.


Methodologies mostly protect you on the downside.  The productivity of software development is even more sensitive to the quality of management than other business processes, because of the huge variability of productivity among programmers, the variability of software products and their uses, and the availability of software components for reuse.  But that’s a topic for another day.

(This post draws heavily from Bertrand Meyer’s excellent “Agile!  The Good, the Hype and the Ugly”, a title I recommend for its historical perspective from a long-time software engineering leader.)