Were we being Agile without realising?

In an earlier post, I mentioned how in one job in London we had no form of project planning.  Thinking about it, I may have been a bit harsh.  In fact, I reckon we may have been extremely Agile, and not realised.  Well, how could we, I left that job in 2000, and the Agile manifesto wasn't written until a year later.

After posting that blog, I received a tweet from one of the guys I used to work, he joked, saying we were ahead of the curve. 

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

So, in that job we weren't planning everything in advance, we certainly weren't following any kind of waterfall methodology.  Thankfully.  I found something out this week.  Waterfall is accredited to Winston Royce.  He never used the term "Waterfall" and he actually described the process as a model that didn't work.  He actually said "… the implementation described above is risky and invites failure"

So why would anyone adopt a waterfall approach to developing their software?   I don't have the answer.  All I know is that the guy accredited for coming up with it, said it was risky and invites failure.   So, does that mean that any waterfall project is likely to fail?

Anyway, back to that job and why I now think it was really quite agile.

Look at the manifesto.  The first line, individuals and interactions.  Well, we certainly had that.  Over the road from the office was a pub, I could virtually see the bar from my desk. We weren't in there every day, but looking back, it seems like it.  We could go over at lunch time and not go back to work.  Nobody thought it a problem.  We'd have developers, various members of the business, from people in production, to the CEO.  We'd all chat, come up with idea's, update each other.  There was a real strong team spirit.

Nowadays, in DSDM, we have standup's, in Scrum, we have scrums.  In those days we discussed the same things, but simply did it in the pub.  The effect was still the same.

We didn't spend masses of time writing documentation.   That didn't mean we didn't do it, but there was only half a dozen devs.  The business need was for us to deliver the software, and then move on to the next urgent requirement. 

Customer collaboration?  We'd come up with an idea, go away see if it was feasible.  Early on we wouldn't know exactly how long it would take, but we could give a rough estimate.  We'd come up with a prototype, continually involving members of the business.  Showing them where we were at, inviting suggestions, responding to change.

We were working iteratively, constantly changing path from the feedback we were receiving.  Did the changes bother us?   Certainly not.   We were giving our guys the software they actually wanted.   They were constantly involved, they understood what was going on.  They knew that if they wanted to introduce a big change, then something would have to get dropped, or we'd change the delivery date.  But that was their choice, they were fully in control of the software they received.

If there was something we could give them early on, we'd get it in and deliver it.  It was worth our while, we all knew that there would be a pint (or two) in for us. 

We rarely worked late, there was never any pressure.  I wouldn't say it was easy, but the delivery velocity was at a pretty constant pace, a pace the business was happy with. We were never at risk of burning ourselves out.  We were all friends, we trusted each other, we were all working for each other.

There are 12 principals of Agile development:

• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Close, daily co-operation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

We were certainly fulfilling all these principals.  We were agile and it has taken me 12 years to realise it.