hold on for a few hours more, then hurry up! Italian Agile Day 2012 is coming on November 24th!

I’ll be presenting a session on projects evaluation, aiming to put together my past few years personal experience. this is such a interesting topic for me, combining both organizational and technical skills.

I’ll be sharing with the audience techniques for documenting and reporting software project feasibility: coarse-grained release planning, high-level logical architecture, rough delivery effort estimation, basic domain modelling. whatever simple enough you need to get started with a project kick-off. possibly.

see you in Milan!


Remarkable quotes

May 3 2012

sort of an ipse-dixit saga starting here..

iterations are means, not an end. incremental development clocked by fixed-length iterations sure is a great achievement, when starting from a “big ball of mud”-like environment, where no process is applied at all. coding rhythm like “need this in production by tomorrow, can you do it?” isn’t sustainable, so planning one to three weeks long iterations is the way to go.

then – because there should be a “then” – next step is asking business to figure out where to bring the project to: medium-term to long-term goals, also known as releases. the opposite can’t stand: filling up iterations with something good-enough to keep development team busy. iterations are means – achieving business goals on a regular and reliable basis – not an end.

coolness isn’t cool. developers often tend to be delighted by techy/geeky stuff. “I’m working on this ultra complex semantic search algorithm which is going to improve performance by a 24.7% factor!”. “we just integrated X with Y, in a clustered Z environment, only by configuration files!”. don’t get me wrong, I’m far from demonizing this kind of focus on technological issues.

but – because there should be a “but” – we, as developers, are in charge of much more: helping stakeholders achieving their goals, managing software development projects, planning releases, architecting and designing systems. we’re not just coders, our value isn’t counted by how many lines of code we can manage to write in a single pair of curly braces. coolness – complex problems and technologies on hype as ends in themselves – isn’t cool. delivering successful projects is.

yep, philosophy was my first love..

Release the dogs

December 17 2011

I’ve been thinking about this post since a few months, and I’ve now got some more data to share about. the title stuck in my mind while listening to “Tomorrow Come Today” Boysetfire’s album, driving back home after an intense day of working with the team.

it all started in a study session on the XP practices, discussing what was stopping us from applying some of them. for example, Small Releases. the immediate objection was “well, we deploy more than once a week!”. in fact, user stories are moved to production as soon as they’re completed, validated and accepted. so, is this a non-sense question?

this week we kicked-off a new project, which is critical, because it aims to improve the company product’s core. the stakeholders asked for a technical solution that could answer the question “is this worth it? does the company receive any benefit from the new business rules”. so, we agreed on an architecture that keeps the two sets of rules in parallel for a short period, and as soon as we collect positive data, we’ll switch the product to the new system.

it took us two days to come with a Release Plan and an Iteration Plan for the first iteration. we collected themes and user stories, discussed a feasible architecture, then set rough estimates. this initial process showed we could answer stakeholders’ question in less than one month. then, it would take us another month to develop enough user stories to switch to the new system. eventually, we could then focus on the less important themes, which we didn’t even analyzed nor estimated, just tracked down on index card.

to recap, we focused on the smallest chunk of stories that could be put into production in order to bring value as a whole, and a release date has been attached to. then we iterated this process. the result is a three-releases plan, which is being adjusted and adapted whenever we found something new about estimates, technical risks, and the domain itself. we also know the first release it’s about two iteration long. then we know what’s going to be developed for the next two weeks, in much more detail, having discussed acceptance criteria and technical alternatives.

back to the initial study session, I think the problem is due to the fact we talk in Italian. the Italian for “release” and “deploy” is exactly the same: “rilascio”. we say “piano di rilascio” for “release plan”, and “rilascio in produzione” for “deploy to production”. combine this whit the continuous delivery practice gaining more and more popularity these days, and maybe the communication problem gets explained. to be fair, the project we referred to, deployed on production frequently, was more in a maintenance than a developing phase. there was no clear reasoning about planning. hence the confusion.

to recap, and to state a take-away message: don’t confuse release planning with production releases, especially if in your native language the two words sounds similar. my suggestion is to mentally translate to “milestones” for release planning, and to “deploy” for production releases. would this help you?

In my shoes

July 19 2011

back from an amazing journey in Crete: 11 days, 5 main cities, lot of beaches and towns only by public transports, hostel by hostel with a light backpack. can’t count how many buses and boats I’ve been taking. and, best of all, people I’ve met.

here’s a quick report:

  • day 1: plane from Milan to Hania. Agioi Apostoli and the Kalamaki beach
  • day 2: Gramvousa island and Balos beach, by boat
  • day 3: bus to Paleohora. sandy beach and pebble beach
  • day 4: Elafonisi beach and island, by boat
  • day 5: boat and taxi to Plakias, via Hora Sfakion. Plakias beach
  • day 6: hiking to Moni Preveli (Preveli monastery), then palm trees beach. way back by boat
  • day 7: bus to Rethymno. beach and old town
  • day 8: Panormo beach, by bus
  • day 9: bus to Iraklio. old town
  • day 10: Agios Nikolaos, beach and town, by bus. Kolokytha peninsula and Spinalonga island, by boat
  • day 11: Cnosso palace, by bus. historical museum and archaeological museum. plane to Milan

following is the initial plan, but of course, as any well-done plan, it has been adapted day by day:

pictures here.

sure, it’s been a tough journey: hostel owners were impressed by my willing to see as much as possible in so short time. sadly, I could not visit eastern coast, like the Vai beach. that could probably be the goal for another journey!

Vision ownership

July 5 2010

as developers, we try to find solutions where problems arise, ideas to get customer gain value from our systems. as eXtreme Programmers, we then try to do this driven by simplicity, communication and feedback. the smarter we are, to more satistied the customers become. but there’s always something strictly domain-dependent, no easy to see being a cunsultant.

that’s where a good product manager comes in.

I’ve been playing with search facilities provided by CMS platform we’re developing on, two days or so: rich fulltext search, simple search component, even custom low-level queries, but neither of them were good enough to support (not-so) complex scenarios given. so, I started focusing on getting simpler searches done, vertically splitting stories, even horizontally on technical-axes (like delaying result pagination). but this keep-on-cutting process left me with almost empty hands.

simple search delivered, asked PM for feedback: it tooks her 30 seconds to say “let’s move to (internal) search engine”. period.

of course, it does make sense, now. but no one in my team came with this idea, focused on solving problem at hand. and yes, it’s “easier” for us because we’re asking someone else, from customer’s internal staff, to work on custom search profiles, while we’re focusing on UI and search integration. what’s important, anyway, is product integrity: something hard to come with.

what’s the morale? quoting Dan North’s Perils of estimation:

The business started out by defining success as solving the problem, but now we have redefined success as delivering this list of stories.

he then goes further, with this evergreen:

Firstly the business wants accuracy and we’re giving them precision. If you tell me it will take 4.632 months and it takes 8 months, that’s worse than useless. If you tell me it takes “about six months” and it takes seven months, I should still be onto a winner.

estimation helps plan a project, stories define business goals “tokens” we gain every week: but ultimate goal still is satisfying customer needs (asking for feeback and showing working software), not collecting those tokens while on a project journey.

Killing me softly

May 7 2010

continuous task switching: that’s it.

can’t manage to work developing one project, following production setup for a second one, doing email/phone consultancy on a third one (where I’m officially no more involved), then helping colleagues in Rome spiking around with a fourth one.

I’m broken.

even more, our near past and future involvment as a team on customer-side is managing a pipeline of (initially) four projects: then (working targeting success) this is getting broader, and more projects are expected to be started on a monthly basis. this is probably the most interesting thing: a shared release plan, one team, more projects.

and a single source for budgets. expect more on this soon..

Growing agilists

November 29 2009

i know, i’m late, really really late.

6th Italian Agile Day has gone, on november 20th. as usual, it’s been a big party, when “old” friends meet and have fun, talking about Agile methods and Italian community. i was still sick, thanks to a friendly one-week flu, so i just reached at lunch time to avoid cold and rushing early in the morning. but it was enough! this year i dediced to “taste a bit of everything”, so i was able to join some open space and session, moving from one to another.

me and Davide also had a session on “Extreme Release Planning”, very funny for me: i had the pleasure to work with Davide, an ex-colleague of mine, and he had the idea of making the audience feel the problem we were talking about: loosing clear vision of priorities, due to lack of release dates. we set up a rudimental planning game: one long string with stories written on A4 sheets (with name and estimate), moving stories to another long string as soon as they were planned.

(thanks to the volunteer guys from adience for helping us with this!)

slides are available here.

here they are some good recap of the conference:

as Roberto said on extremeprogramming-it mailing list, Italian Agile movement is growing and our conference has come of age!

see you next year.