Agile Open '13 - Toronto

The most exciting thing about attending an Agile conference is that the planning of the conference is Agile as well! This was my first time attending an Agile Open conference where there is no agenda set for the day. The idea was pretty odd to me at the beginning, but when I saw it getting it to work; I realized the power of creating an environment where people can self-organize based on topics of their own interest.

The conference started off with a 1 hour exercise to create an agenda for the day. Our team decided to organize a session on a “New Approach for Product Development”. We wanted to share with everyone the recent experience we had in delivering a product using agile methods in a waterfall environment. When we pitched this idea to the participants, we found out that this topic resonated with other people as well. So we decided to collaborate with another participant who had a very similar experience in this field.

  

We started the session by presenting our stories to the audience and reflecting on the challenge of integrating an agile team within a waterfall organization. Our approach for delivering the product closely followed the methods discussed in the Lean Startup book by Eric Reis. The project started off by creating an MVP in two weeks and re-iterating on this MVP to incrementally build the product. We noticed that some stakeholders had concerns with regards to the quality/ compliance of the MVP to the company’s product standards. It might seem like a negative experience, but in fact that was good news for us. Using this approach we were able to help the stakeholders in clearly articulating their thoughts and ideas to describe what they want to see in the product J

Those thoughts were presented to the audience and then we all brainstormed on how to best integrate the Lean Startup methodology in a waterfall environment. After an in depth consultation about this topic, the team came up with the idea of creating a buffer zone between the delivery team and the process controllers to shelter the agile team from the “usual” waterfall process requirements. This buffer should act like a medium to deliver the minimal requirements that are essential to comply with the waterfall process without affecting the performance of the delivery team. Taking this approach will also require an iterative approach to meeting those requirements as the product will likely evolve over the course of the project.

Another idea that we explored is “How to define the size of an MVP?”. Eric Reis describes an MVP as “the fastest way to get through the Build-Measure-Learn feedback loop with the minimal amount of effort”. Well, we are discovering that in some cases this smallest effort might take several iterations before getting the first MVP out to the market. Especially when delivering an end-user product for a well-established organization that takes pride in the quality of their products. We identified two factors that should be considered when deciding the size of an MVP:

1. Complexity of the business process associated with the product. The more complex the business process the larger the MVP needs to be to be able to validate the end-to-end business value
2. The number of stakeholders within the organization. The larger the number of stakeholders, the larger the MVP will be required and the more frequent releases will be required to test the product

Although the conference seemed chaotic at the begging, I thought it was the best learning experience for our team as we had the opportunity to learn something that we can share with our clients. The organizers ended the conference with having the participants stand in a large circle and asked everyone to share what they learnt during this event. Everyone was totally surprised by the fact that all this learning was for $25 only!