Scrum Gathering inspiration

I had a great Scrum Gathering this year.  In particular I’m really happy that we did lightning talks as the two biggest things that sparked my learning were from Cara on setting achievable goals for retros and Carlo about reviews – both of
which were lightning talks.

Setting achievable goals
Retros rock.   But sometimes they do become stagnant. Sometimes that is because the same stuff comes up all the time.  But also often it is because nothing actually is getting done.  Cara gave a really great demonstration of how to make SMART actions and make them meaningful and actionable – and even to raise up the impediments to getting the action done so that they can be apparent up front as well.  Take a look at the video at .  If your retros aren’t getting results, really do consider giving this a try.  It is obvious – but most of us aren’t doing it.

Your sprint review sux
Reviews have troubled me in the past.  We’re better at them now.  But for a long while they weren’t very effective.  So I’m interested in practical ideas around reviews.  I sat in on a Scrum Clinic topic about making reviews more interesting and got a couple of ideas to try – but Carlo’s lightning talk on reviews was yet another way to look at reviews.  I really like the concept of looking at the product with your product owner as a team looking for ways to make improvements rather than just looking at what we just did in the last sprint.  We’ve almost been doing this in our last couple of reviews and I’m looking forward to making it more and more relevant.  Thanks Carlo for the eye opener.  And of course the concept that maybe the CEO in the review should be something else – like a demo every 2 or more sprints – separate from the reviews. The sprint review should be a safe place for the team to agree and discuss about on what to do next.  Check out the video at

Other thoughts…
There are two other things that have been bugging me for a while – from opposite spectrums of agile challenges.  What are agile software development practices and what is an agile company really.  Unfortunately I got some tastes of these topics at the gathering, but nothing really meaty to chew on.

I sat in on a couple of the software dev talks looking for insight and inspiration and held a couple of discussions that gave me some ideas.  But for me this is one of the harder aspects of agility.  Scrum just organises the way you work.  Agile software dev practices like XP and using DDD, real OO design and architecture to achieve agility in code actually change the way you write code and even think about how you do your job.  And developers are a lot pricklier about changing that than simply the organisational style around it.

The other end of the spectrum is what makes a company agile.  And what are the things that make your company not agile.  Boris’s management by constraints hit a chord for me.  I sat in a couple of other talks but didn’t get struck by new big insights.  Since then I’ve been reading some of Ester Derby’s blog and some ideas are formulating – both from a real problem statement and a hypothesis as to how to solve the problem.  I’ll write more on this at another time as my mind ticks over it.

Overall this was the best Gathering in Cape Town that I’ve attended.  I’ve been to all three – and I’m not at all biased due to the fact that I was involved in the organisation of this one.  Really! :).  I got a lot out of it.  So thanks to all those who helped make it an awesome success.



Lightning Talk retro – Fixed Price Scrum

I did a 10 minute lightning talk at the Cape Town 2011 Scrum Gathering on Fixed Price Scrum.  It went down reasonably well – but if I did it again, I’d do it a bit differently.

The point of the presentation was to point out it was possible and effective to use Scrum to manage a project that traditionally is waterfall and would generally be a rather fast march to and past the end date of the project while blindly hoping you’d still make it.  Scrum allowed us to know early that the date wasn’t possible – which let us manage the client early and hence to come to a compromise and tweak the iron triange of fixed date, time and scope so that we could actually tweak the scope and deliver to the date – and then complete the rest of the scope.  I believe it has been the most successful fixed price project that we have embarked on by far.  So it was successful.  The client did get what they wanted.  (Luckily they did sort of know what they wanted as it was replacing an existing system.)

After the talk I realised that I had given some hope to some people that you could succeed in doing Scrum in their environment.  That was the point.

However I did start to feel guilty afterwards.  I did a talk on waterfall with Scrum helping out.  Yes, the Scrum was pull (mostly) and we inspected and adapted, we tested continously and we did reviews.  These were awesome and effective.  But we took a BRS, chopped it up and turned it on its side and called it a backlog and off we went.  It wasn’t agile.  I did a very non-agile talk at what was in theory an Agile conference…

The project wasn’t Agile in the sense of removing waste or in delivering value at all times.

The BRS generation wasn’t agile.  It was waste.  But the client needed it as a proxy for trust – and a requirement for public tendering.

The review process wasn’t agile.  It was prescriptive – did we meet the BRS.  Value was limited to the BRS and the scope management around that.

But the project was successful.  The delivery was of good quality.  The client is now a long term fixed team client.  We built up trust and a working relationship.

So does it really matter that it wasn’t agile?

If I did it again – I’d point out that we were doing Wagile.  And that there are still perks to using Scrum – even in waterfall.  And doing Scrum in any environment allows you to start learning and growing your understanding so when the opportunity comes to not being in the prescriptive contracting relationship, then you are already primed to embrace more agility as you may have started to figure out what that actually means.  And maybe while they are there – they can work out how to be as agile as they can – around the fixed constraint of the contract – and eliminate waste where they responsibly can.

Will fixed price projects go away in the future?  Unlikely.  Should any company contract in a fixed price arrangment?  Not if they can afford to do otherwise.  But would it be better to go bust and be agile or better to make a profit and be wagile?

Hopefully the next time I present it will be on something more relevantly agile and I’ll feel less exposed to agile frowns.  Or at least remember to point out that I know it is waterfall in agile clothing as I go along.