Wednesday 22 May 2013

Agile In A Day - Training Summary

Yesterday I was luckily enough to go on a day course on Agile, which covered a multitude of topics and gave me a nice refresher on the topic.

Experiential Learning

Although it sounds like another bad buzz word, the concept of "experiential learning" was employed throughout the day. I actually really enjoyed it and I would definitely agree that the whole "learning by doing" concept.

Do Less... And Do It Better?

One of our first lessons was around one of the core tenants of Agile: uncovering problems and adapting to change faster. Our exercise basically illustrated that doing less work all at once meant you:
  1. Had less work to throw away if it all went wrong.
  2. Could find better ways to do the rest of the work.
Obviously doing things better doesn't magically happen, the techniques for continously improving is kind of what Agile is all about. The main technique/framework we focussed on was Scrum.

Scrum



A famous diagram I recall from my university days, sadly I have never really done Scrum in anger :( The biggest take away I had was the emphasis on "knowing what 'done' looks like". All your tasks in your product backlog should have concrete acceptance criteria, which ideally should be an automated test.

Another revelation was on the actual Daily Scrum meeting. Contrary to my experience, these meetings are actually supposed to last 15 minutes max and any problems should be discussed offline. Being strict with time and strict with your processes is very important in Agile, perhaps more so than in waterfall?

Finally we were reminded that Scrum is a framework which is abstracted from Software Development. You can in fact use Scrum for any project in any discipline! How you actually "turn backlog into product" is completely up to you, Scrum is a doughnut and it is up to you to find the jam to fill it with (your own processes/methodologies, e.g. TDD).

Understanding Requirements

We were shown some really useful techniques for gathering and understanding requirements:
  • 5 Why's - This is basically trying to get to what someone really needs, going beyond what they think they want to do to get it.
  • Clarification - Focussing on quantifying requirements and trying to put metrics against them so everyone understands what needs to be done.
  • Suggestions - When you understand what the real need is, at this point we can use our expertise to figure out the most effect way to deliver that need. At this point you want to remember things like KISS and YAGNI ;)

Retrospectives

One of the greatest takeaways I had from the training was the whole concept of linking retrospectives. So in every retrospective you follow these rough steps:
  1. What did we say we would change in our last retrospective?
    • Did the change go well?
    • Are we going to keep/disregard this change?
  2. What went well this iteration?
  3. What went badly this iteration?
  4. Name a few things we can change for the next iteration.
The whole idea of actually coming up with actions, recording them and trying to measure their effects is very refreshing. Whilst my experience of retrospectives is limited, actually trying to quantify changes beyond vague pieces of advice is stupidly obvious to me now.

Conclusion

As with any lesson, it is only useful if you put it into practice. Doing Scrum/Agile in isolation just doesn't work, although I can keep being disciplined in using XP techniques. Got to do more Test Driven DESIGN like I mean it!

No comments:

Post a Comment