X
Business

Agile software development still more a feel-good term than reality

'It breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better,' a co-author of the 2001 Agile Manifesto laments.
Written by Joe McKendrick, Contributing Writer

When one of the co-authors of the Agile Manifesto calls on developers to run away from agile development initiatives, you know something has lost its way.

sequoia-tree-darmstadt-germany-cropped-june-2018-photo-by-joe-mckendrick.jpg
Photo: Joe McKendrick

"It breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better," Ron Jeffries, co-creator of the Extreme Programming (XP) methodology, and longtime proponent of well-focused development practices, writes in a recent post. "It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work."

So what went wrong?

Basically, organizations have applied the "Agile" label to justify cracking the whip more often against developers to pump out more code faster than is sustainable. It's raising the intensity of a pressure cooker environment while cheering that "we're all in this together." Plus, "Agile" has taken on a much broader meaning, suggesting that the entire organization should be pliable enough to turn on a dime.

Agile has become just about everyone's corporate mantra, with 97% of organizations in the 2018 State of Agile survey stating they practice Agile software development methods.

As Jeffries describes it, such misuse or abuse of the concept leads "to more interference with developers, less time to do the work, higher pressure, and demands to go faster. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile.'"

He calls these approaches "Faux Agile" or "Dark Agile." Rather than opening up an organization's creative and collaborative juices, such approaches mean imposition of another, only semi-supported system or process in a sink-or-swim approach. As Jeffries puts it: "larger-scale 'Agile' methods appear actually to recommend imposition of process. I include here the so-called 'SAFe' method, Scaled Scrum, and LeSS among others. These are pitched to the enterprise, and the enterprise is expected to 'install' them, or 'roll them out.' As a developer, you can be sure that this roll-out will not go smoothly nor in a truly Agile fashion. You'll not likely be trained, much less educated, much less given the real help you need to do your job."

Such pronouncements also are intended to give comfort to business and IT leaders that they're "hip" to the latest thinking about running a business, as well as doing something to compete like a 21st-century business. Every business is now a software business, after all.

Rather than being crushed by attempts to shake up organizations to be "Agile,"Jeffries calls upon developers to continue striving for excellence, but also revive and promote the original, and timeless, concepts of the Agile Manifesto to the business. His advice includes the following:

  • "Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day."
  • "Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible."
  • "Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what's ready to go, and in terms of what they'd like you to do next."

The beliefs expressed in the Agile Manifesto still stand up like a guiding beacon 17 years after they were first published:

  • "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
  • "Welcome changing requirements, even late in development."
  • "Agile processes harness change for the customer's competitive advantage."
  • "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
  • "Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
  • "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
  • "Working software is the primary measure of progress."
  • "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
  • "Continuous attention to technical excellence and good design enhances agility."
  • "Simplicity--the art of maximizing the amount of work not done--is essential."
  • "The best architectures, requirements, and designs emerge from self-organizing teams."
  • "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Editorial standards