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:
- 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
- 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!
