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.