We are just a few days after the amazing experience that was ALE 2013. I enjoyed being for three days in a large family of European Agile and Lean practitioners, and I learned a lot from the conference. I’ve seen many enthusiastic blog posts after the event, and I’m glad that it was so much learning happened.
But this blog post will not be another one praising the experience. Instead, it will be about this: we’ve done it, it was great, how can we make it awesome?
I haven’t yet gathered all my thoughts after the conference, but there is one that keeps following me. A few speakers presented models to the audience; Jurgen talked about the learning model, Vasco talked about a model without estimates and I talked about a model for incremental design. There were many others which I didn’t mention because I don’t remember them now.
Having models is excellent. It shows that agile and lean thinking is evolving and maturing. It’s the same thing that happened with our understanding of the Solar System and then of the Universe, or of the way the matter is structured. But I couldn’t shake the feeling that all these models (yes, including my own) lacked something. And that something is boundaries.
I propose that from now on, in the ALE community, when defining a model we follow a structure:
- What the model is
- Why is it helpful
- Examples of application
- When it doesn’t apply (examples or description)
I’ve seen that often models presented in the agile and lean community fall short of the last three points, although they are all equally important.
Having real examples is important for showing that the model was used before and it worked. First hand examples are better, but documented examples from serious books can also be used.
Documenting the assumptions will help everyone understand what works and what doesn’t. For example, “No Estimates” seems to assume that the stakeholders trust the team. But that’s what I assume from what I’ve heard about No Estimates, and I might be wrong.
Giving examples of when a model doesn’t apply helps define its boundaries. For example, retrospectives don’t work in an environment where people don’t trust each other, are not truthful or transparent to each other. As for incremental design, it is my hypothesis (not yet proven or disproven) that applying incremental design to a problem with a well-known solution makes no economic sense.
Being a speaker myself, I realize this is a tough requirement for speakers. After all, we speak at conferences to spread ideas. It’s easy to use rhetorical mechanisms like jokes, stories, theatrics, quotes to introduce an idea; it’s much less exciting to talk about the limits of your idea. I believe though that we should start trusting the ALE community that it’s mature enough to understand and appreciate when a speaker talks about limitations of a model and not only about the good parts of that model.
Some of the readers who are interested in science might recognize that the principles I’m advocating are far from scientific models. This is on purpose. I think we still have a lot to learn about conducting experiments in software development, and I think that this job is best left to people who have experience with it. I also believe collaborating with such people is something we need to develop for the future, if we want to advance the state of software development. But I also acknowledge that we need to take it one step at a time, and I believe this is a step we can make for the next few years.
By the way, although it might sound like I took a shot at No Estimates, I have to mention that Vasco Duarte was the only one that I saw at the conference who presented data gathered from real projects. That’s great, and I believe we should encourage other people to do the same.
In conclusion, I’m offering a model I believe we should use when we present models to the ALE community. It is up to the community to accept this model, encourage, challenge and help speakers to raise to its requirements. It won’t be easy, but we’ve already seen that ALE is a forgiving environment, so I’m sure we can do it.