Road to Agile — Part 3: Skip the tutorial

After a brief introduction to HelloTech and its status quo, today we will take a look at the first concrete changes in the way our teams work.

My first idea was to avoid long workshop sessions about “how to do Agile”. Instead, I used a “skip the tutorial” approach: we gather feedback, implement changes, and iterate. This seemed appropriate as the business pressure on the teams is very high, and it doesn’t cause any significant dip in productivity.

With all this in mind, it was important for me to have an initial “observational” phase. This way, I could quickly gather useful proposals for the teams, and gradually introduce them to Agile best practices.

I decided to focus on the Product Owners first. Why? If you compare software development to the flow of water through a pipe, the Product Owners will be responsible of ensuring a reliable and predictable water intake.

You cannot expect the output of a certain workflow to be good, if the input is not good as well.

Or, put more concisely:

Garbage in, garbage out.

Depending on their actions, Product Owners have largest impact on the efficiency of their teams.

The tasks they create can either enhance the “agility” and “ownership” of their teams, or drastically hinder it.

Furthermore, they can accidentally convey external pressure on to their teams, or allow tech debt to build up over time. They are often asked to compromise a lower creation cost for a higher maintenance cost of their product.

By personal experience, the “skip the tutorial” approach should not be used in the kitchen.

Over my first few weeks here, I had several talks with our Product Owners and looked at the way they were creating either tasks or user stories. We looked at the characteristics and advantages of a good user story, and tried to apply these principles to their daily work.

It often wasn’t easy to do this exercise on projects that were already born as “back-end only”. Especially in some squads, this created a rift between the front-end and back-end developers that was almost impossible to close, unless we started a new project from scratch.

It was important, however, for the Product Owners to slice their product in releasable increments, regardless of the status quo of their teams. Establishing this principle is a very important preparation step for the introduction of Agile methodologies.

The results were good. Especially for new projects, the Product Owners showed great potential. Words like “Proof of Concept” and “MVP” acquired a different meaning.

I applied the following strategy:

1. Train the Product Owners on user story writing
2. Establish a standard visual format for user stories across all teams in JIRA
3. Dig deeper into the topics of user story splitting and MVP
4. Hold user story refinement sessions with the teams.
5. Follow up as often as possible

As the teams often complained about unclear tasks, establishing a common (visual) format for all user stories was a quick win. In this way, we were able to have much more focused conversations than before.

This helped us a great deal when we brought our stories to the team. It was nice to witness how they accepted the change, and trailed behind the Product Owners.

However, I also saw how the initial thrust died quickly, and how the teams naturally “fell back” to old practices. Mindsets don’t change over time, and that’s why constant coaching is crucial during this phase.

I realised that there is one limit to this “skip the tutorial” approach: you cannot be 100% sure of how many notions are actually needed by the team, in order to root out most of their inefficiencies. I tried to pick the smallest possible pieces of “Agile knowledge” and hand them out to the teams gradually. It wasn’t perfect, but it gave us a starting point.

With hindsight, it’s easy to acknowledge what had been missing. The advantage, however, is that the teams themselves will now be able to also realise and accept it. This way, you are not imposing a new process from Day One, but make sure you gradually build up both processes and mindset at the same time.

A mindset without processes can become inefficient, and does not scale. Processes without mindset can kill both commitment and morale.

It’s an exciting challenge, though sometimes it can be an emotional rollercoaster. Things feel great, and then bad, and then great again.

It’s almost as if every day we were trading our “Agility” on the stock market: the index goes up and down, appreciated or depreciated, bought or sold.

You must expect some sort of fluctuation, and have a strategy that accounts for it. A shared strategy, that is. In HelloTech, the Product Owners are a crucial part of it. Without them, it will be very hard to take this vision to the next level.

Agile 1, over and out.

Looking for a new job opportunity? Become a part of our team! We are constantly on the lookout for great talent. Help us in our mission of delivering fresh ingredients to your door and make home cooking accessible to everyone.