Services | Pragmatic Agile Process

Introduced in the Manifesto for Agile Software Development back in 2001, Agile processes promised “better ways of developing software” by valuing:

• Individuals and interactions over (not instead of) processes and tools,
• Working software over (not instead of) comprehensive documentation,
• Customer collaboration over (not instead of) contract negotiation, and
• Responding to change over (not instead of) following a plan

The manifesto was supported by 12 fairly revolutionary (at the time) principles, including:

• Satisfying the customer through “early and continuous delivery of valuable software“, as opposed to delivery months or even years later as had been the case with Agile’s predecessor, the waterfall model,
• Welcoming “changing requirements, even late in development”,
• Delivering working software “frequently, from a couple of weeks to a couple of months”,
• Getting business people and developers to “work together daily throughout the project”, and
• Reflecting as a team on “how to become more effective” and then adjusting the team’s behavior accordingly

It’s hard to overstate just how radical these ideas were and how different the world was when they were introduced.

Over the years, many different “flavors” of Agile process emerged — iterative (e.g. Scrum, Dynamic System Development Method or DSDM, Feature-Driven Development or FDD, etc), continuous (e.g. Kanban), etc — and rituals (e.g. daily standup meetings, capturing requirements as user stories, tasks, epics, and features or initiatives, estimation, backlog grooming, sprint demo, sprint retrospective, etc) developed and began to “stand in” for the important ideas espoused in the manifesto and for the principles that support it.

Like most processes, the steps must be understood and followed in order to be successful.  Think about the mess that the process of baking a cake would create if the purpose or importance of certain ingredients or steps were misunderstood, the wrong ingredients were used, the right ingredients were used in the wrong proportions, or the steps were skipped or performed in the wrong order.

In a hurry to deliver game-changing results, many organizations attempted to use Agile processes without really understanding or following them, and today the “religious” wars over whether Agile is a panacea or a placebo rage on as a result.

The truth is that dogmatically following the easy parts of the Agile process (e.g. daily standup meetings) while ignoring, misunderstanding, or poorly implementing others will never produce predictably high-quality results.  It’s been said that Agile isn’t a magic solution that organizations can “sprinkle on“; it must be “baked in” in order to be effective.

What’s needed is a pragmatic rather than dogmatic approach.

The Agile manifesto was not a rejection of up-front technical vision or design, nor a rejection of documentation, but has been taken by some teams as license to do away with the things they don’t enjoy in favor of the thing they enjoy most: coding.

For example, the Agile principle that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation” may be true, but if the information that is conveyed is not written down (aka documented), it will be lost, misconstrued, argued about, and ultimately result in re-work.

If it’s true that “continuous attention to technical excellence and good design enhances agility”, then why do so many teams rush through development with little to no design, focusing only on getting something to work rather than on technical excellence and still expect to succeed?

And in 20+ years, I’ve yet to actually see “the best architectures, requirements, and designs emerge from self-organizing teams”.  Leadership must set expectations and exercise its authority in order to get the most from Agile processes.

Let’s understand, select, and implement that Agile processes that will most benefit your organization, improving quality and collaboration between business stakeholders in order to predictably deliver real value to your customers!