Skip to content

Quick Note: Doing Agile vs Being Agile

March 2, 2012

This Quick Note discusses a very interesting post by iDesign architect Michael Montgomery. Available on the iDesign website, “From the Field: Agile and the Architect” takes a look at the current state of Agile development techniques in the field of software development.

If you are not familiar with Agile software development, Montgomery summarizes the movement this way “The Agile Manifesto [1] was chartered in 2001, by a collection of very senior developers and software gurus. The idea was to shed the glacial pace of corporate software development of the previous decade and reinstate the end user as one of the chief stakeholders in the process.” [italics added by me to quotes from the post, and links have been preserved from the original post] And he goes on to explain that “out of this comes many practical ideas like daily standups (aka Scrums), small teams, direct stakeholder involvement, breaking large problems into consumable tasks, backlogs, prioritization, iteration, pair programming, testing and a desire for transparency at all levels into the state of software development as it’s unfolding.

In the “real world,” Agile techniques certainly represent attractive and easy-to-implement best practices for software development. But Agile has largely failed to live up to its promise to deliver in the workplace.  The hard question to answer is “why?” Montgomery takes on this question in this passage:

Original Agile Manifesto [1] signatory Andy Hunt, upon observing how the majority of dev shops operate today has been quoted as saying [7], “…they could have been a poster child for Agile methods…But these weren’t productive developers freed from mindless process dogma. They were Agile slaves.”

He goes on to say, “…they weren’t thinking, they weren’t reacting, they weren’t being agile. When problems came up, they addressed them with all the grace and elegance of a deer caught in the terrifying blaze of alien headlights…”

He concludes the thought with the insightful observation “…they knew how to do Agile; they didn’t know how to be agile…”  [the bold emphasis here is mine, also]

Montgomery has written a concise, easy-to-digest piece that strikes at the heart of the issue of why organizations succeed or fail at software engineering, and exposes that often it doesn’t have much to do with how agile or traditional their SDLC practices are. He summarizes his philosophy in this passage: “As architects, confronted with the Brave New World in which we find ourselves, perhaps the best thing we can do to be agile is to design systems that are more agile. And if the systems we design are better equipped to adapt to change, then so too might the organizations that we help to build them.”

If you are involved with software engineering, and especially if you use or are considering the use of Agile practices, this article should be considered required reading. Enjoy it.


From → Computers, Technology

One Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: