Image Image Image Image Image Image Image Image Image Image

Being Brunel |

Scroll to top

Top

One Comment

Agile Engineering

Agile Engineering

In 2001 a bunch of software developers went on a jolly to a ski resort in Utah, and that (in an extremely tight nutshell) is how the mysterious “Agile” process you’ve probably heard bandied about by over excited managers began.

Something that I find fascinating is that when software started delivering large projects they looked to us to see how we did it, and inherited our “waterfall” methodology. That is- define the requirements up front, find the dependencies and link them together to form the shortest chain, complete and finally ask the client if it’s what they wanted.

Agile is a manifesto, it is not a defined process. I think this is a common misconception from people looking in.

By the time these developers went skiing however, they’d already found this process broken; clients weren’t good at knowing everything they wanted before work began, change was expensive as it broke the “critical path” and at the end everyone sued each other in disappointment. Sound familiar?

Software moves faster than engineering. Before the ski lodge incident these developers had already defined new ways of working with a variety of stupid names (scrum, kanban, xp, etc.). They actually went to Utah to try and find some common ground. And that’s where Agile was born (in fact the only thing they disagreed on was the name; as the Brit in the group felt that Americans couldn’t say agile properly!)

Agile is a manifesto, it is not a defined process. I think this is a common misconception from people looking in. To be agile means committing to these twelve commandments. I’ll talk about some of the processes that can be used another time. But for this post I want to introduce the manifesto in its original form:

  • 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.

So that’s Agile. And I’ll tell you something; it works. It’s become the poster child for successful projects in software development; you should see the way programmers spit the word “waterfall”. So the question is, can, and should we engineers be agile?

Over the next few weeks I’ll be touching on this subject; comparing my projects as both a civil and software engineer- working waterfall and agile- and reflecting on what that means. But for now, I invite you to consider, armed with the manifesto, how much of that do you think applies to the built environment?

Submit a Comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackbacks

  1. […] my last post about that buzzword ‘agile’, I introduced you to its history, and the twelve principles that underpin Agile Software […]