Learning to be Agile

Posted on 11 September, 2012


Oft misunderstood, oft mis-applied, an agile approach to project delivery promises much and can certainly deliver, if done properly.  Thus I was delighted to attend the Certified Scrum Master course last week where I was able to refresh my mind on a few ideas that I’ve used in the past but perhaps not applied much in my current role, and at the same time was introduced to many new concepts, approaches and techniques.

In many an interview or meeting over the years I’ve often made a statement of valuing “people over process”, something I truly believe and endeavour to support wherever possible.  I hadn’t however realised it was actually one of the key components of the agile manifesto.  For my own future reminder, here’s the full manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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.

The training itself included a great range of exercises designed to reveal and explore key features of a scrum approach to project delivery, including designing a process, iterative improvement and refinement, approaches to estimation, feature prioritisation, release and sprint planning and review.

The biggest exercise involved the creation of our epic lego city through creating a vision, prioritising features through a team-based exercise called ’35’, designing an infrastructure and delivery process, release planning, and planning, conducting and reviewing a series of four eleven minute sprints in which to deliver the city itself.  Here’s what we ended up with.

It’s more complicated than it looks!  Each element of the city is packed with specific features to match the required criteria of the product owner.  Establishing those is just one example of the process improvements we made after the first sprint review ended up in a mass rejection of work, due to feature requirements we were not aware of, but had done nothing to seek out and agree.

Each iteration we sought further refinements that could benefit the team and the project; introduction of and clarity on roles, better planning and specification, increasingly smooth and more focused production.

All in all it was a superb two days of training.  The challenge now is how to best apply this to current projects, and engage the team in becoming a constantly evolving high-achieving and successful team.

Posted in: Agile, Management, Process