Retiring this blog, moving to a new one

After many years I’m retiring this blog (brainscrum) and moving over to

Remember to update your bookmarks if you are one of the millions of people following it… ;-)

Leave a Comment

Italian Agile Day 2008: a conference funded by donations

The 2008 edition of the Italian Agile Day is gone. It’s a one-day free conference about everything Agile. The conference has organically grown going from 100 attendees in 2004 to nearly 400 this year. It was a great success but the most interesting thing to me is that for the third year in a row I managed to fund it through donations and real ones as in no minimum amount required and more importantly people don’t have to donate in order to participate.

Now that I’ve got 3 data points – 2006, 2007, 2008 – I’m doing an analysis of what it means to rely on donations and scaling and I’m disclosing all the numbers for the sake of transparency: people but also costs, money collected, trends (posivite and negative) and hopefully much more.

If you are interested in the analysis and the numbers here are the first 2 posts in the series:

How to fund a conference with donations – part 1 with a bit of history and some numbers to start addressing the question: Do donations scale?

How to fund a conference with donations – part 2 with all the numbers: how many donators? what’s the average donation? what’s the trend over the last 3 years?

Enjoy! :-)

Leave a Comment

Italian Agile Day 2007

The fourth edition of the Italian Agile Day is over! It’s a free, one day conference I organise every year and for the second year in a row I managed to fund it using donations via PayPal instead of looking for commercial sponsors.

The remarkable thing about this edition is that we went from 180 attendees last year to over 260 this year!!

Some facts:

– for the first time we moved from Milan to Bologna (part of my plan to conquer the whole country…)
– 3 rooms for 3 parallel tracks
– more than half the people had never been to an Agile Day before
– Tim Mackinnon kindly agreed to be our (great) keynote speaker

– 4 sessions for newbies
– 5 experience reports
– 1 three-hour long workshop on User Story writing

– many OpenSpace sessions

– a Futurespective on the Italian Agile Day 2010 (and 2009, and 2008)

A group of people then went for the usual post-Agile Day dinner and this is how the starters table looked like :-)


I know I say this every year but indeed it was the best edition ever even though, looking at the ideas for 2008, it’s gonna lose this position in 12 months :-)

Leave a Comment

The Anti-IF Campaign

I just got back from the fourth Italian Agile Day and I’ll write more on this in the next few days but I want to share with everyone an interesting Italian campaign my friend Francesco Cirillo – the oldest (not as in age :-D) and greatest Italian eXtreme Programmer – has launched:

It’s called The Anti-IF Campaign (the page is in Italian)

It reads: “anti-if campaign, you can quit if you want to!”


Francesco talk at the Agile Day (about, among other things, proper Object Orientation) was funny, entertaining and full of meat as usual. Imagine a great public speaker addressing the crowd wearing an Anti-IF t-shirt and saying, while showing snippets of real code with a McCabe’s Cyclomatic Index > 110, “be honest guys: you like this code, don’t you!”

I believe the campaign should have international visibility and that’s why I’m writing this post. Go Francesco, go!! :-)

Comments (4)

Why Business Acumen

Lots of people (including me) keep saying you need to understand the fundamentals of Agile before tinkering with it. We keep saying working in iterations, doing stand-ups, doing TDD, sitting altogether in a room is not enough to claim you are “doing Agile”.

This is true for any approach, Agile or not: you have to understand how, when and why it works before starting to customise it.

IMHO this is the main reason why you are supposed to apply an approach sort of “by the book” before starting to change it (through retrospectives, of course! ;-)). This is also why people talk about Shu Ha Ri as a way to approach Agile.

A common advice is to always change things once you got the core values behind them. Even better once you got the principles who fill the gap between values and practices. The real problem, as usual, is the complexity surrounding these aspects and the far-from-the-books reality of the day to day troubles.

To help organising ideas and possibly cut through this complexity many interesting and useful perspectives have been proposed both on the Agile side of the pond and the other. For example, David J. Anderson’s Recipe for Success:

“Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize”

Nonetheless people keep having problems with the complexity that often prevents us from seeing the bigger picture. We have problems in cutting through this complexity and go back to the building blocks.Most of the people I meet though don’t even consider these building block, their focus is on the process/approach/method/methodology itself.

This is limiting, this is not why we have (and discuss) methodologies in the first place. This is what I was referring to at the end of my “From Technicality to Business Awareness: now what?”.

Everyone agrees that not all the processes should be managed the same way. Processes differs in particular depending on the four Vs:

  • volume – high volume ones can exploit economies of scale and be systematized
  • variety – high variety ones require enough built-in flexibility to cope with the wide variety of activities expected of them
  • variation – high variation ones must be able to change their output levels to cope with highly variable and/or unpredictable levels of demand
  • visibility – high visibility ones add value while the customer is present in some way and therefore must able to manage customers’ perceptions of their activities

Generally speaking high volume with low variety, variation and visibility make it simpler to have low cost processes while low volume with high variety, variation and visibility all increase process cost.

Nonetheless all these situations have common building blocks and to make them very clear and easy to understand and remember I’ll borrow some definitions from the business world:

– cash generation
– return on investment (as combination of margin and velocity)
– growth
– consumers

That’s it! Everything else emanates from these core ones. These are what any process/method/methodology/approach/whatever should ultimately enable. If they don’t they are getting in the way of the fundamental building blocks. If they don’t it doesn’t matter whether your are doing all the good Agile stuff or not: you are not doing the right thing.

These building blocks exist, with the appropriate adaptations, at every level of the supply network of any organisation. From the strategic level down to the operational level and that’s why any process MUST address them.

In the next few posts I’m going to write a bit more about these building blocks, why they are relevant and I’d like to introduce the three levels which constitute any business operations: the operation itself, the supply network and the single processes. This way I hope that by the end it will be clear why I’m putting together all these things.

Leave a Comment

From Technicality to Business Awareness: now what?

The single most important benefit Agile approaches brought to the IT industry is neither technical, nor process related, nor organizational. Let me explain.

From what I can remember, before the Agile movement emerged, the software engineering crowd rarely moved away from the technical argumentation. I think the only time it moved a little was at the beginning of the pattern movement which, by the way, was blamed by many to contain a romantic element like the research of the “quality without a name” clearly at odds with the mainstream technical soul.

Issues like what values and principles stand behind an approach and what beliefs are considered true were almost always lacking while others like in what contexts those values, principles and beliefs are meaningful were usually present in a latent form (aka: you needed to look hard to find them scattered as they were among all the technicalities).

Agile approaches, on the other hand, start from the values and the principles. The beliefs are a little more explicit than before even though still not fully uncovered or better, not everyone yet is ready to accept even the possibility that there might be beliefs behind them which might not be true for every single reality.

Yet again this is not what I consider the single most important benefit brought by the Agile movement to the industry: the single most important benefit is a sort of Business Awareness.

I finally see and hear people, regardless of their official role, talking about business value and how they can help delivering it. Not just theoretical discussions about it but actual actions, contributions, body of knowledge, experience sharing. I see technical people interested in return on investment, opportunity cost, GDP and sometimes cash flow.

I’ll go so far as to say that nowadays if a team is doing all the good Agile/XP stuff like TDD, refactoring, continuous integration, etc, etc but I don’t hear people talking about delivery of business value I’m usually worried because more often than not it means some fundamentals are missing and people are in a sort of “agile Assimilation mode”.

As the title of this post says: now what? Well, this is the first step! The second actually. Often business value is repeated so many times it becomes an empty mantra and even I cannot stand it anymore. To make a parallel is like repeating ad nauseam OOP or TDD or pick_up_the_thing_you_prefer: it’s not gonna make it happen! Now we are aware of it but we still don’t know how to affect it, what it exactly means, why it works the way it works and what we can do about it.

For the same reason we keep saying that we need to understand values, principles and beliefs behind Agile in order to fully understand it and be able to adopt it and adapt it to our reality we need to understand the fundamental building blocks of any business in order to understand why we do what we do, regardless of the chosen approach.

The next step is developing Business Acumen and I hope to find the time to write more about it in the near future.

Comments (6)

Get Lean. Get Innovative.

From an interesting article published on IndustryWeek: “Companies that consistently innovate are ones that invest in working conditions that enable workers to be creative. Simply ordering people to work harder and innovate probably isn’t a great strategy.”

Update: just realised the article is discussed in a post on one of the best blogs out there (IMHO):

Among other things it discusses “where to find the time needed”

Comments (1)

Older Posts »

Get every new post delivered to your Inbox.