Lean chaos

My encounter with agile

My first stint with agile was a disaster.

In hindsight, I imagine it as a scene out of one of those pre-pandemic end-of-the-world movies. A car is being driven to safety amidst surrounding havoc, trying to keep the passengers alive while the world is collapsing in the rear-view mirror. And then it finally catches up to them.

My experience was quite similar. I was joining a small team to help craft the experience of a product in the hospitality space. At that point, it was only a feature wish-list brewing in Google Docs and Spreadsheets. Stakeholders had a fair idea of the problem statement and the outcome. However, the solution was yet to be converted into a functional product.

With the timeline we had, the plan was to deliver an MVP to launch with an initial set of beta users. During the course of the project, there were many mistakes that transpired which could have been avoided. In a crusade to be accountable and learn from my mistakes.

Some of them are documented here:

Jumping right in

As the solo product designer in the team, I approached the project like any other. By jumping right into research, scheduling interviews and setting up the stage for design exploration. Understanding the product and business landscape was the goal for initial design sprints.

On the second day itself, I was hit in the face with the force of multiple dependencies. Engineering sprints had started the same week and they expected screens. Leading to half-baked product ideas being pushed to code. This lack of tactical planning made it a game of catch-up from the very first sprint on.

Having loose definitions

A few sprint in, I realized that the design, product, engineering and the business teams had a very different definition of what constituted an MVP. At no point, the team sat down to discuss, define and agree to expectations out of this MVP. And that misunderstanding brewed itself into all kinds of turmoil.

For me, even though it was an MVP — it was being launched in a real environment setting with impact on the business top line. So naturally, I wanted all bases covered. When these use-cases were surfaced, they were added to user stories without any prioritization or re-evaluation of its effect on delivery timeline.

We did start doing the same, but the unforeseen had already created roadblocks and affected project flow.

Being a bystander

Since I was new to the ways of agile, the strategy of mine was to trust the process. The assumption was that there must be a good rationale behind the decisions being made by agile practitioners. So, even if something didn’t feel right to me — I would let it slide to see how this different approach would turn out.

Providing feedback to such decisions, even from the other side of the aisle, would have definitely helped in sparking solutions leading to more favorable outcomes.

Being surprised with scope creep

When I sat down with engineering team to estimate for the project — it was a great tool to plan delivery and budget. Although, the stories were of-course incomplete.

When the same estimations were used a source of truth for sprint planning, the likelihood of scope creep increased and materialized. This led to lengthy back and forth between product and engineering teams, slowing down the delivery.

To make matters worse, we failed to properly identify certain additions to new stories vs extension of existing ones. So while the scope was bloating up, there had been no communication to business units that delivery plan might get affected. This wrong turn lead to frustrated team members, unaware stakeholders and project which was way off its initial plan.

Late Escalations

A fast moving project needs constant documentation and communication between different stakeholders. I used to see any deviation or disagreement as a sign of failure and kept it between the lines till it’s resolved internally.

I have seen now that the cost of resolution tends to raise exponentially with each passing day. And you could use the support wherever necessary. So, it’s better to escalate and communicate early and often.

Presenting progress without context

When people are asked to operate in a complete new process, but the fundamentals have not been defined and agreed to — it’s going to lead to mistakes.

We introduced Burn charts as a way of communicating estimated vs actual progress of the project. It was new to certain team members as well as the external stakeholders and required further explanation in most sprint outcome meetings.

We anticipated the confusion. But didn’t plan for the direct hit on the trust. As mentioned earlier, when we didn’t account for certain stories as scope creep — it not only affected the scope, but also the delivery plan. But on paper, we were on track as per the burn charts.

When the mistake was finally fixed, the gap was quite visible and optically deceiving to a certain extent. All because of over-trust on a singular process.

Although, the initial parts of the project were chaos, we did identify and mitigate many of the mistakes as we moved forward. We keep running new experiments to learn and explore, paving path for more successful outcomes in the future.

I hope my learnings can be helpful if you find yourself in similar situations. Thanks for reading :)

Credits:
Illustrations used are from Blush platform by Pablo Stanley