Let’s Run An Experiment

Just how do you start a transition to Agile?
In the words of a wise Agile coach,

“Let’s run an experiment!”

The most important thing we realized was not to get it perfect through analysis paralysis before we started but rather… JUST START and course correct along the way!

In hindsight, makes a lot of sense to me – an agile approach to an agile transition.

We decided to run an experiment on a very visible project. It involved developing a product that would provide our customers with reports and analytics on how well their job postings did. Great for customers because they could show return on their investment and great for us because we could use it to up-sell customers on features that would improve the performance of their postings. Real business
value all round!

Problem was, previous attempts at developing the product took over 2 years with many false starts. When it was finally deemed ready for launch, it failed due to architectural complexity and oversights.

With such a legacy, we figured it was an ideal candidate to pilot Agile.

So we started.

We assembled a cross-functional team of 11 members composed of .NET
developers, UI/UX designer/developers, QA analysts, a product manager, a project manager, a business analyst, an analytics specialist and a sysadmin.

With the team assembled, we needed a space to co-locate them. This was a top priority given the importance of face-to-face conversation as a key Agile principle.
The ideal would have been a dedicated room with a door but this was a far from an ideal situation. Here’s what we had to work with:

Grabbing some lunch-room tables, here’s the low-tech, low-cost solution we came up with:

With the team co-located, we figured the magic of face-to-face conversation and collaboration would just take over and the team would hum merrily along.

How wrong we were.

• Half the team had so many other commitments on their plates that they couldn’t even sit with the team. The result was part-time remote team members.
• For the ones that did sit together, it took them a while to get use to staring directly across at their team-mates without the benefit of partitions.
• Interaction with the business owner was few and far between resulting in a lack of direction and clarity.
• Expertise with a key technology was lacking.
• With no standard Agile methodology adopted, the team used what they each knew best leading to inevitable conflicts.

But then something special happened. A few of the members took it upon themselves to push forward through the noise and lead the rest of the team and the business towards something of value.

• They stepped outside their traditional ‘waterfall’ roles to help others.
• They proposed decisions that normally would’ve been the domain of others.
• They lobbied for and succeeded in getting just-in-time training for that key technology.
• Out of the myriad of suggested practices, they settled on leveraging a user stories task board and burn-down chart as their primary means of gauging progress through each sprint.
• They ran into three show-stopper issues within weeks of each other that in the ‘waterfall’ world would’ve allowed for weeks or even months to get resolved. They had days to get each resolved. A great example of the benefit of ‘fast failures’ in the Agile world.

In a nutshell, they suddenly had PURPOSE!

The result was delivery of Product v1.0 within 2 months! Not only did we finally deliver on a promise over 2 years old but it was a resounding endorsement for the potential of Agile.

We were on our way and nobody wanted to look back.