Tag Archives: agile

Some Practical Advice on Agile Project Contingency

In a perfect world…

…the life of a Scrum Master is bliss. We don’t pretend we know everything in advance, we don’t pretend we are in the head of the Product Owner and we are always honest about the real state of the product/development lifecycle through open demos, retrospectives and openly-publicized metrics.

We constantly dedicate our time to improving performance and delivery of value through best practices, continuous improvement, and collaboration with all the relevant stakeholders.

Until one magical day, after a lot of iterations, we reach Agile Nirvana and can predict accurately the amount of work we can deliver in the… next sprint! (That’d be 2 to 4 weeks – hardly something to write home about….)

But organisations don’t operate in sprints – they operate in quarters or years and more often than not, senior management is interested in knowing what you can deliver in the next X number of months.

confession

That’s the point when all Scrum Masters start pulling their hair out, screaming that “this is not how Agile works” and curse about the travesty that is “agile waterfall-isation”. We keep kicking and screaming up until the point we realise that the managerial demand won’t go away and we start Googling advice from Agile Gurus on how to perform Project Planning on an Agile Environment.

Now, the purpose of this post is not to explain how to estimate and plan an Agile Project – there are a lot of people out there who can explain this a lot better than me and have done so already. The purpose of this post is to showcase my personal, straight-to-the-point advice on Agile Project Contingency and its role/importance in said environment.

So let’s get some facts straight…

Continue reading

Tagged , ,

Reporting End-of-Sprint Stats on an A4

Let me kick-off this post by quickly stating the following facts:

Compiling Reports Sucks…

…and the closer you are to the ground, the more it sucks. Having to look back while your “To Do” list is getting longer and longer seems to be a counter-productive concept (it’s not). After all, reports are just another way for “The Man” to keep an eye on you and constantly evaluate who the next flogging victim is going to be (not true either – I hope).

On top of that, reports usually require supporting stats and digging out that data can be tricky and/or time-consuming. Finally, in most cases, the objective of those reports is to explain why things have gone wrong/the production environment has exploded/the live database has disappeared (delete as required). 

As a result, I have yet to meet a report compilation enthusiast – I, for sure, am not one!

Lengthy Reports Cost Money

The longer it takes you to compile a report, the higher the direct cost (“time is money blah blah…”). Indirectly, the cost of having a Scrum Master compiling reports as opposed to running the Scrum or removing impediments can be even higher.

And the story does not end here. The longer the report, the longer it’ll take for the reader to find the information he/she needs and time is money… you get the idea.

Reports are actually needed…

…for many different reasons. Either as an article for convincing your team sponsor to keep paying your wages or (more importantly) to enable you as a team to “inspect and adapt” and become a better unit.

When it comes to Scrum and end-of-sprint reporting, I have seen and written many different types of reports; trying to explain how the sprint went, what we delivered, what the problems were etc. Some of those reports were long or pointless or full of unnecessary clutter (and in some cases, all of the above). But ultimately, what I have found is that the traditional Scrum artifacts are enough to give you the whole picture: Continue reading

Tagged