Our ups and downs with Agile and Scrum these past 8 years

It wouldn’t be a stretch to say we were in a cargo cult, we’d seen some practices, learned some ceremonies and we tried to implement Scrum the way we understood it.

Eight years later, we’re much closer to the original concepts, with many lessons learned.

Also read: Ready. Steady. Go Scrum Methodology!

Back when Agile equaled Scrum

The two concepts were hard to separate when we first implemented Scrum. Like other teams, we believed that doing Scrum made us Agile. Which it could have, had we done it right from the beginning.

Looking back, the first thing I would change now is to have an Agile coach guide our adoption of Agile practices and the Scrum methodology. Because we chose to implement them by ourselves, it was very hard to identify mistakes, improvements, and the correct way to weave these concepts into the fabric of our day-to-day work.

We advanced at our own pace, slowly implementing practices and trying different concepts. Every team would try to see what worked for them and we would get together with the other project managers for knowledge sharing. We read, we tested and we learned from our mistakes.

Overcoming challenges

Once the results started showing, we knew we were on the right track so we focused on improving and we even assigned the role of scrum master in our teams.

One of our biggest challenges was to integrate the role of product owner, which for us, as an outsourcing company, was usually on the client’s side. We didn’t even have a business analyst role. Our main connector was the project manager, who would gain some product owner assistant responsibilities, helping to bridge the gap between the software development team and the business development team.

We continued learning about Agile and teaching our clients as well, to make sure we were all on the same page when it came to how we worked, communicated, and delivered.

With these additional responsibilities, project managers would sometimes find themselves in a conflicting role. On the one hand, they were representing the client and the business side as product owner assistants, on the other hand, they were scrum masters who were focused on improving the process and the team dynamics. For some, that’s an insurmountable conflict.

The biggest change happened when we created the role of technical team leader. As a technical lead, that person would be the scrum master, freeing the project manager from the conflicting responsibilities they had been having until then. This made a huge difference and it really helped the way we executed Scrum moving forward.

Experimenting with other frameworks / methodologies

You might have noticed we’re pretty excited to experiment with different concepts. Extreme programming and Kanban were two other frameworks/methodologies that we implemented in our teams.

The starting point for adopting a new methodology was a shortcoming we would identify in Scrum. For example, in some projects, Scrum made it difficult to act on changes in priorities in a 2-week sprint, especially in smaller teams. For us, one way of adapting was to have 1-week sprints instead of 2-week sprints.

Today, every team defines their way of working. If a client needs a clear image of the extended roadmap we adapt; if a product is going through multiple changes in a short timeframe we adapt; if a client is looking to secure an investment with an MVP and then decides to implement a critical feature to secure that investment we adapt; if we have to deliver a technical proof of concept in a week, we adapt. The goal is to deliver good software and have a satisfied client. The methodology and practices we choose are there to serve that goal.

A downside to this is that if someone switches teams, they have to be prepared to work in a different setting. Or, they could look at it as an opportunity, like we like to do.

Scrum & Kanban outside of software development teams

We believe that everyone working in a software development company should understand how software is created and delivered. This is one of the reasons why our support teams have also started planning and organizing their work using Scrum.

Our Sales&Marketing team, our People team, our Finance&Admin team, and our leadership team all work in sprints.

This makes a huge difference for quarterly and yearly company planning because we’re all aligned.

Final thoughts

If you’re just getting started with Agile, Scrum, and all the other methodologies and project management frameworks, I recommend working with a specialist. Looking back, I think it would have saved us a good couple of months. Having someone oversee the implementation of these concepts and observe behaviors and improvement points can really make a difference.

Even though there are countless stories like ours, of trial & error, of experimenting and learning, it’s a sign of maturity to see what works for you and to adjust some methodologies. I wouldn’t recommend starting with a custom version. It’s always best to start with the official way of doing things and then decide what brings value for your team and how you can improve on it.