The Slideshare version of my "Possiamo fare di meglio" (we can do better than this) presentation, is now available (in Italian) here.
I did my best to add comments to the many pictures, sooner or later also the video version will be available.
Thursday, November 26, 2009
Wednesday, November 25, 2009
Article on DDD Context Mapping is out on InfoQ
Monday, November 23, 2009
A crowdsourcing experiment
Like one year ago, I decided to give my talk at Italian Agile Day as an open session with roughly the same schema: 15-20 minutes of impact talk, and 30 minutes of open discussion. I like this type of sessions because it’s not a “I know the truth” approach (I don't), but rather a way to make a small portion of a possible truth emerge from anyone in the room. So, even if I had some answers in mind, I preferred to focus on the questions, leaving the answers eventually open. I’ve seen some open sessions, but it’s not the kind of things that you practice every week (unless you’re leading a talk show), so please forgive me if it anything went wrong. Personally, I think it went a lot better than the year before: the discussion flew naturally and touched many of the topics I wanted to touch.
See it in another way
Ok, now think of me like Dr.Evil, with a “masterplan”: I’ve managed to hire about 200 among the best IT professionals I know as consultants for one hour. Basically for free. That’s my crowdsourcing experiment. And I had the feeling of so many little things emerged. Maybe not so clearly, maybe not so well formed or well expressed, but enough to make me think a lot in the following days.
On the way home, and later in the weekend some thoughts were a little clearer. I guess my personal follow up is worth sharing: at least ...I owe it to the participants. :-)
We’re making products, not software
Software is what we know, what we like to write, what we learned to produce. Some of us are really good in writing software, or in making their team write good software. That’s only half of the story: from the user perspective we see a product, not code. In the discussion, many mentioned user interface or the user experience. Which is right. But it’s still trees, not the forest. If we start thinking about the overall product we might realize that we need to see the whole a lot better than we usually do. Scrum has a good shoot on this by emphasizing the role of the Product Owner, meaning that we have a single responsible person (which is a gift from the gods in many organizations) for the whole product. There’s a problem up there, because so many times the whole idea of product is flawed, and we’re just writing software. Guess what... with a high probability of being completely useless.
I’ve seen so many projects missing their goals or their potential, just because the responsible organization didn’t have a clear idea of the whole product not to see a pattern here.
Non technical integration is not so easy
Ok, so we should try to have an all-round view to our product. Including also non developers roles within our project scope. Interesting but tricky. Especially if the team boundaries do not match with the company boundaries, which might happen quite often in a cross-functional team. But software-only teams can control continuous integration to a very high degree of efficiency using TDD, Continuous Integration and SCM tools. But this is only a portion of the product. Other professional might follow a different approach, that has nothing to do with TDD (or maybe it has... only on a different time scale), and the perfection we strived to achieve becomes frustratingly fragile. I guess there’s no easy recipe here, we’ve got to fall back on mantras like “inspect and adapt”: solutions might be a lot different from team to team. After all we’re humans. But it’s funny to realize that we sometimes we want to “integrate early and often” but “only software artifacts, please”. Postponing integration with non-software components of your project is even riskier.
This is definitely a hot topic, especially if you approach it from an enterprise management perspective: enterprise 2.0 folks are talking about more flexible approaches to collaboration, and this might be at odds with the benefit of a jelled team.
See it in another way
Ok, now think of me like Dr.Evil, with a “masterplan”: I’ve managed to hire about 200 among the best IT professionals I know as consultants for one hour. Basically for free. That’s my crowdsourcing experiment. And I had the feeling of so many little things emerged. Maybe not so clearly, maybe not so well formed or well expressed, but enough to make me think a lot in the following days.
On the way home, and later in the weekend some thoughts were a little clearer. I guess my personal follow up is worth sharing: at least ...I owe it to the participants. :-)
We’re making products, not software
Software is what we know, what we like to write, what we learned to produce. Some of us are really good in writing software, or in making their team write good software. That’s only half of the story: from the user perspective we see a product, not code. In the discussion, many mentioned user interface or the user experience. Which is right. But it’s still trees, not the forest. If we start thinking about the overall product we might realize that we need to see the whole a lot better than we usually do. Scrum has a good shoot on this by emphasizing the role of the Product Owner, meaning that we have a single responsible person (which is a gift from the gods in many organizations) for the whole product. There’s a problem up there, because so many times the whole idea of product is flawed, and we’re just writing software. Guess what... with a high probability of being completely useless.
I’ve seen so many projects missing their goals or their potential, just because the responsible organization didn’t have a clear idea of the whole product not to see a pattern here.
Non technical integration is not so easy
Ok, so we should try to have an all-round view to our product. Including also non developers roles within our project scope. Interesting but tricky. Especially if the team boundaries do not match with the company boundaries, which might happen quite often in a cross-functional team. But software-only teams can control continuous integration to a very high degree of efficiency using TDD, Continuous Integration and SCM tools. But this is only a portion of the product. Other professional might follow a different approach, that has nothing to do with TDD (or maybe it has... only on a different time scale), and the perfection we strived to achieve becomes frustratingly fragile. I guess there’s no easy recipe here, we’ve got to fall back on mantras like “inspect and adapt”: solutions might be a lot different from team to team. After all we’re humans. But it’s funny to realize that we sometimes we want to “integrate early and often” but “only software artifacts, please”. Postponing integration with non-software components of your project is even riskier.
This is definitely a hot topic, especially if you approach it from an enterprise management perspective: enterprise 2.0 folks are talking about more flexible approaches to collaboration, and this might be at odds with the benefit of a jelled team.
Reading suggestions after IAD2009
I’ve found myself talking about many different books with many different persons during IAD2009, here’s a summary of the books I more or less explicitly suggested:
- Pragmatic Thinking and Learning - Andy Hunt: some things happen by chance, some don’t some others you could make it happen.
- Agile Software Development, the cooperative game - Alistair Cockburn: an eye-opener on what’s around the code.
- Agile Retrospectives - Esther Derby, Diana Larsen: so little small details can make the difference between a good retrospective and a useless bloodbath.
- Collaboration Explained - Jean Tabaka: sometimes there’s so much about the people that we don’t really know.
- Agile Project Management with Scrum - Ken Schwaber: it’s not software development, it’s product development.
- Don’t Make Me Think - Steve Krug: how many times are we willing to transform a service into a pain?
- The design of everyday things - Donald A. Norman: guys, I hate bad design.
- Domain Driven Design - Eric Evans: there’s much more to this book than it looks (and looks like there’s plenty of stuff already).
- Patterns of Enterprise Application Architecture - Martin Fowler: the reference book for current architectural patterns.
- Agile Project Management - Jim Highsmith: it’s not all about the software,but it works.
- Slack - Tom de Marco: oops seems like so many things your organization is doing are wrong.
- Peopleware - Tom de Marco, Timothy Lister: still incredibly useful, if you haven’t read it you’re just pretending to manage software projects.
- Getting Things Done - David Allen: everybody’s talking about GTD, maybe because there’s something true in that.
- Clean Code - Robert C.Martin: you won’t go anywhere if you don’t agree on this.
Back from the Italian Agile Day 2009
I’ve seen skilled and curious colleagues. I’ve seen nice ideas emerge from different perspectives (more on this soon). I’ve met old friends and nice persons which I didn’t know and that I am now honored to know.
All this doesn’t happen everyday and everywhere.
Thanks to Marco Abis that every year make this magic happen. Thanks to everybody in the staff and to all friends from the Bologna XP Users Group, once more fantastic. Thanks to all the speakers, able to tell real stories without hype or fluff. Thanks to all the participants to my “talk show” sharing interesting ideas and thoughts. Thanks to the heroes that risked asphyxia to follow my Domain Driven Design mini-workshop.
Thanks also to Roberto Bettazzoni that reminded me what it means to be “Romagnolo”.
It has been a great day.
Thanks to everybody made it possible.
All this doesn’t happen everyday and everywhere.
Thanks to Marco Abis that every year make this magic happen. Thanks to everybody in the staff and to all friends from the Bologna XP Users Group, once more fantastic. Thanks to all the speakers, able to tell real stories without hype or fluff. Thanks to all the participants to my “talk show” sharing interesting ideas and thoughts. Thanks to the heroes that risked asphyxia to follow my Domain Driven Design mini-workshop.
Thanks also to Roberto Bettazzoni that reminded me what it means to be “Romagnolo”.
It has been a great day.
Thanks to everybody made it possible.
Monday, November 02, 2009
Scrum Introduction with Peter Stevens
As a satellite event to the 2009 Italian Agile Day in Bologna, I'll be helping Peter Stevens in the one day Introduction to Scrum that'll take place in Bologna on November 19th, right before the IAD.
Peter is a seasoned Scrum trainer based in Switzerland, and helping companies in different countries. More info could be found on his blog Scrum Breakfast.
Peter speaks quite a good Italian, we thought that the best combination would be to keep the teaching part in English, and question time in Italian. But ...I guess this would be an emerging behaviour as well.
By the way, Agile Day participants will get a 20% discount on the full price.