Agile Day - Result Day

During the fifth Italian Agile Day, held last November, I missed the Retrospective for the Italian Agile Community, but I read everything about it in the following days. The community proposed a "result day" in which we would share our experiences and verify our progresses since the agile day, to check whether we're really improving or are in a "one step up and two step back" situation. Gladly accepting the invitation, these are my comments.

A small foreword is due for better to grasp what's behind the result: some of our customers belong in a very politicized niche, and (also) for this reason they say they absolutely need to know in advance exactly what they will get, when they will get it and how much it will cost. Ok, this is almost true for non political organizations too. Anyway, except for small projects, this normally forces us to rate the analysis and give a guesstimate for the software, which will be specified and formalized at the end of the analysis phase.

In the last few months I have been involved, amongst other things, in an assessment project for one of our customers: they need a software and they need it quickly, and we offered them a solution.

Our proposal has a paragraph that explains how we will build the software. It expressely says that the system will be realized in an iterative and incremental way. It says that the estimates are based on user stories (which we verified with their IT manager - our Product Owner, I daresay - who in turn has checked them with his colleagues). It says that the customer will prioritize stories. It says that the project will be divided in 30 days iterations called sprints, and that it will be monitored using a product backlog, many sprint backlogs, burndown charts and running tested features charts. Most of all, it says that the system will be validated by automated acceptance tests.

Well, this is my result: it may be small, but I am really proud of it because it might be a turning point from just being "agile inside" to spreading the agile way of thinking amongst customers and their managers.

I must admit that the fact our customers cannot afford the time requested by a traditional waterfall process made my task easier, but that does not touch me particularly; on the contrary, just the fact that everybody agreed upon the fact that the waterfall process is a longer and more expensive one and that an agile process is needed (we never mentioned it, but you've already figured out we're talking about Scrum) is more than enough...

Many other posts for the result day can be found on the Italian Agile Movement forum page on the subject.