The Showcase – time to celebrate

I was recently asked to contribute to this editions “showcase” and when I read the email my heart jumped and I thought – FARK we don’t have anything to talk about.

A quick chat to one of my product owners to check if they wanted to showcase our tech spike from the previous sprint…….”nope I, um no I don’t want to show that yet”. I thought why you schmuck it’s awesome what we just learnt and the possibilities…….yea yeah ┬ánah!

Then I thought of my other team – the Drupies. They are a BAU support team who also manage to release feature updates and enhancements across 6 sites! And again i thought….nope nothing interesting there either you guys are just BAU. A showcase should be about SHOWING off to your investors, stakeholders, business owners et. al. your progress.

A quick jump back to JIRA, a glance at your visible wall and TADAH!!!!! We just smashed SEO out of the park for the last Sprint. Heck we even titled/themed it so. We have now achieved #1 and #2 rankings consistently for mobile searches whereas previously to this sprint we were in the late single and early double figures for many of our key search terms.

And now some 4-5 slides later, I remembered 1 very important key component to my role as the Scrum Master is not just manage their day-to-day, plan, groom, keep stakeholder/owner happy. I also need to be communicating our progress, hits-n-misses, learnings and championing our teams delivery at all levels to keep securing that buy-in else one day you might just turn up to work and it be gone.

So remember folks a good scrum master just does but a GREAT scrum masters does that and more. Don’t forget your team are exactly that….your team. Not some service provider – they have bills to pay just like you and I. And a happy worker is an effective worker. Heap praise and success where deserved – you’ll be surprised what you might get back in return.


Agile myths and selection criteria

I work for IAG (Insurance Australia Group) and we have a I would suggest a small but mature Agile community of Scrum Masters, Iteration Managers projects and teams all delivering in an Agile framework largely built on Scrum.

We also have many teams and projects using more traditional forms of management such as Waterfall. As part of our Agile community we meet each week to discuss Agile @ IAG and have series of story cards we a re tracking to either deliver training, socialize and champion the cause throughout the organisation and I had a story card to produce a slide deck that talked about Agile Selection Criteria.

It was one of those tasks that wasn’t clearly defined, not elaborated very well and certainly no definition of done. As good Agilista’s we did this in the sprint and I came up with the following attached.


It’s a really pragmatic and simple look at how, why and when you should choose Agile as the software development methodology to apply that ‘change’ in your organisation. I tried to point out that;

  1. It’s not s silver bullet and won’t kill vampires, werewolves or Waterfall project managers
  2. You shouldn’t have an excel sheet with formulas calculating your projects readiness to be Agile, and
  3. Be pragmatic and simplify your own processes to achieve your goals and deliver you projects

Take a look and please share your comments below as I would love to hear your feedback.

Agile myths and selection criteria