My results

February 1 2009

i’m 48 hours late. friday was the “results day”, as planned during the last Italian Agile Day. i’m one of the lucky ones, working in an agile team, both as a developer and a mentor too. but please, don’t think there’s no room for improving, nor for making mistakes: you’re wrong.

so, the bad things first.

i’m still too difficult to pair program with. i grab the keyboard from the driver’s hands not jut everytime my head has a new idea, but also when i see he/she’s doing a mistake. sometimes i “just” hit ESC from the navigator side whenever something wrong is coming. that’s truly, deeply, honestly wrong. i learned a lot from my mistakes, i should give a change to try (and fail too) to my team mate, in a timed-box fashion. even worse, my peer could have a simpler idea than mine, so why stop it? lesson learned: while acting as the navigator, tell your ideas first, and eventually grab the keyboard.

fine, now the good part!

one of the biggest risk on the project for our last customer was third-party services: API not yet ready, even functionalities unclear. for the mailing service, we were given an early WSDL to play with. it took a few days to develope a facade and an adapter to the system, in order to isolate our codebase from web services. even if it was incomplete (no way to send individual messages, just collective newsletters), we found out a simple way to send individual email: programmatically create a newsletter with a single recipient. managers told the team they asked for a complete API, “soon”. i think you can see… it never came, budget was over, time rushed. so, our simple but non optimized solution is now going to go in production, and it works. lesson learned: don’t anticipate change, it could take different paths than you thought, or it could never happen, at all.

then, i recently re-joined a previous project, after almost 5 months. so, my “fresh mind” helped the team spotting out some design smells. i’ve done a few code reviews and design spikes, checking out the codebase from scratch, and tried to let a “fatter” domain emerge, grabbing code from infrascture-poisoned areas. a strong re-packaging helped a lot, too. as a result, i put some note on paper, and took a nice screenshot of the packages structure. what followed were discussions and collective study sessions, during which we incrementally applied some of the hints, but better hints came out too, thanks to the whole team! design is now clearer and communicates better (even if we all know there’s a lot more to do). all the team members, also the newest ones, can now work on new user stories in a more confident way. lesson learned: focus on design.

and now, what’s next?

something i really missed during the last year is collective study sessions. i read and code a lot studying in my spare time, but i still miss gathering feedback from others. even if during a retrospetive the team decided to improve study sessions, i’m going to focus on timed-box collective brainstorming. in my view, design and refactoring are good candidates. that’s why i’ll push for an internal “Design Pattern Study Group”, or doing exercises from Wake’s “Refactoring Workbook” book.

being a team is tremendously different from being “a group of co-workers”. shared values, shared goals, respect, “we’re all in this together” approach. my suggestion to you, start thinking: am i working in a team or in work-group? feed a team culture, starting from values. i think results will come, soon: individuals and interactions over proesses and tools!


3 Responses to “My results”

  1. Perché non usi la maiuscola dopo il ‘punto’?

  2. Luca Minudel Says:

    nice to ear how agile goes in other teams (so thanks to Tommaso for the Result Day idea!)

    > “Design Pattern Study Group”

    I’ve collected some infos from the same site you linked and from other similar sites to deepen dp understanding
    (it is here pattern by pattern:

    if you have other similar infos, I really would like to know

  3. Luca Minudel Says:

    @Jacopo G.

    mi hai fatto ricordare On the road di Kerouac e poi questo punto della sua lista Belief and Technique for Modern Prose, a list of thirty “essentials.”

    13. Remove literary, grammatical and syntactical inhibition

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: