What “Being Agile” Means To Me

At university I was taught the principles of software engineering. The methodology we used was termed “the waterfall model”. Given I was a self-taught programmer until then, it sounded great – a structured, disciplined and “engineering”-like process that would turn me into a coding professional.

The trouble was, outside of the ivory towers of academia it just wouldn’t fit. I jokingly say to people that the process works great if you know exactly what you want at the beginning, everything works exactly to plan and you’re probably NASA. For everyone else, no project plan survives first contact.

I tried for some time to apply rigid software engineering principles in the hope the lack of success was down to inexperience and poor technical skills. Gradually I realised the problem wasn’t the methodology as such, it was that each step in the process wasn’t an exact science, nor did they follow a linear sequence. We can’t do a perfect design up front, because no customer knows exactly what they want. We can’t do exact time and cost estimations at the start, because no developer knows exactly how long it will take to build or even how it will be built. No wonder the poor project manager wonders why their Gantt chart goes stale so quickly, and the customer gets shipped a lemon six months or a year down the line.

There is only one time when everyone knows the whats, whens, whys and hows of a project with any certainty: when the project has finished. And given that many projects are, supposedly, shipped late and over budget that knowledge is often painfully gained. There’s a reason why some organisations call retrospectives “post-mortems”.

Wouldn’t it be great to have the benefit of hindsight for each and every project? Yes, it would. Better yet, we already do to an extent. For every project we work on, we gain knowledge and experience that we apply (one hopes) to future projects. Unfortunately, every project is different. Teams change, customers change, technologies change, budgets change, tasks change, deadlines change, risks change. Even redoing a known project from scratch, using exactly the same customer and team will result in something different. (If it doesn’t, you have a big problem).

Change is often seen as a bad thing, because people don’t normally like change. Go order a mass desk move to a team in mid-project and take copious notes on the response. Bonus points if the move is the day before a hard deadline.

For me, Agile is about managing change. Scratch that, it’s about embracing change.

When we start a project it’s fresh, new… and rather hazy. The customer has a vague idea of what they want, and the development team has a vague idea of what needs to be done. If you’re lucky, those two vague ideas are of the same hazy vision. As we progress through the project, our collective understanding of the domain improves, and the overall vision is refined. The customer slowly realises what they really want, and the developer slowly understands what the customer is aiming for. The developer’s estimates become more accurate, the design takes a more definite shape, the software yields more value to the customer. We all get better.

By embracing change, by acknowledging it’s going to happen, we work on ways to make change less painful. Changing something after a lot of time and effort is not fun, so short iterations of work mean more plentiful feedback and thus more regular course corrections. Short iterations of work mean concentrating on building only what we need for an iteration – we keep our design and our code supple, working on what we need to work on at a given time. We make our code simple and understandable, so changes are easy, and testable, so we can implement and refactor with confidence.

Agile at its very core is about embracing change. Change happens all the time, we can’t avoid it, so we need to take it into account when we develop software. No matter what Agile methodology you use, or want to use, XP, Scrum, RUP, whatever – it’s important that it allows you to deal with change effectively and naturally.

Without that, it just ain’t Agile.


4 thoughts on “What “Being Agile” Means To Me

  1. Rather than a waterfall, maybe what’s needed is a ‘watershed’ approach? ;D

    Seriously though, as a hobbyist programmer mostly working solo this topic interests me. And a watershed isn’t really that bad of an analogy, if you consider the design process starting from the deepest, highest point and then working its way down, as bigger and bigger ‘streams’ join the main course, until you reach sea level, ship it and the money rolls in…

    My Dad, a programmer who got started in the 50s, would always relate one anecdote of how his co-workers would start a project by writing code immediately, while he would patiently design the whole thing first. Basically a waterfall model as I understand it, with the difference being that he was only working on one assigned piece of the project. At first it would appear he wasn’t getting any work done, until things started getting tested, and his code worked much better than the hastily coded ones!

    I’m sure this is one of those tales that grow tall around the fire, but with such an emphasis on agile over the waterfall, I wonder if there isn’t a lack of attention on the usefulness of careful design?

    I can’t really speak to this — I hardly design things at all when I program ;D, which is something I’m trying to remedy by learning better practices. But I’m curious about a professional’s perspective on this.

  2. The problem is indeed not in the methodology, it is in the nature of software projects. Generally, software development is still not a mature industry (like construction, for example), which greatly affects the implementation. I’ve predicted that in 20 years from now, software development will be standardized. Of course, until then, we have to live iterative methodologies such as Agile.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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