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.