This is a story that will show how an Agile framework, although very popular and heavily employed, is not a panacea, cannot cure all diseases nor can be a good fit for any development team.

Though it is “in” nowadays to speak ill of Scrum and to point out, even exaggerate its weaknesses, this is not such an article. Whatmore, my opinion of Scrum is highly positive. The fact that people mistake it for a checklist, a methodology, or a prescription of how to succeed in business, software development, and life in general, is not the problem of Scrum. It doesn’t claim that it can solve all the problems in all the companies for all the people. Furthermore, it never claimed that regardless of how you implement it you will be successful, yet I hear people expressing exactly such an expectation.

So, in this case study we investigate reasons why the Scrum didn’t fit well with the team, what problems it caused to them, and how Kanban came into the game.

We will also see how the team switched to a new framework and what they learned.

Meet Our Client

Our client was an IT company creating an app & web portal and a podcast dedicated to sports news and events. The company had between 100 and 300 employees, mainly engineers, but also product and project managers. All employees were located in different geographical regions, most of them working remotely.

The team that is in focus of this case study was working on an Android app and a back-end platform (the content management system). At the beginning of their work, they adopted Scrum as a framework of their choice and it was working for them before the platform was launched. However, after the launch, with an increasing number of users, and also with increasing appetite for monetization of the portal’s advertisement real estate the team started to stumble.

The Challenge

Speaking with the stakeholders we found out that the team was incapable of achieving Sprint goals, the tasks kept sliding from one Sprint to another, and things simply hadn’t been done. Consequently, the roadmap was under serious threat of not being fulfilled, and with it the goals set in front of the whole organization.

What the team revealed is that they were under constant pressure from key users to perform emergency tasks that were not planned at all, but were extremely important to be done asap, as they bore huge business value. This rhetoric put a lot of stress between the team and the Product Owner, the latter being accused of not understanding the value of the product, is not capable of prioritizing, and not having proper relations with the clients. At the same time Product Owner claimed that clients didn’t know of the changes until they received requests from the advertisers which was always too late.

The fact that the Scrum framework worked well for the team was still very fresh as the launch date was not so far in the past.

In addition, the users felt that the whole feature development was wrong and ambiguous and that their requests were taken into account only after escalations toward senior management.

What was the problem?

For the sake of a better understanding of the problem, I will explain in a few sentences the basics of the Scrum framework as they are necessary for comprehension of the problem the team was facing. So, if you are experienced in Scrum you can skip the next paragraph and continue reading after it.

Scrum is an Agile framework that provides teams with guidelines for efficient delivery of value by defining a set of roles (Product Owner, Scrum Master, and developers), events (the Sprint, Sprint planning, Daily meetings, Sprint review, and retrospective), and artifacts (the backlog, Sprint backlog, and increment). The development of value creation happens in time-boxed periods called Sprints. During this time the team should work only on those items (increments) that were prioritized for that Sprint and that have entered the Sprint backlog. Anything that emerges after the sprint has started has to wait for the next sprint. In other words, no working item should be added to developers after the Sprint has started. As Sprints shouldn’t last more than 4 weeks, and in practice, most teams have 2-weeks Sprints, this means that anything that emerges after the Sprint has started has to wait for 2 to 4 weeks to be taken into the working process. This way of working provides focus on items in the Sprint backlog, transparency of what the team is working on, and predictability as we know when the things will be finished (at the end of the Sprint the Sprint goal should be achieved). This works fine if there’s discipline in the system. However, if any part of the system starts failing, the whole system is jeopardized.

After this needed digression, let’s turn back to our case study. Our team has practiced Scrum for some time. They started practicing it while there was no product on the market, stakeholders were internal and there was no client (or at least no real client) to make demands. In such an environment they managed to be productive and to be Scrum oriented. However, when the product appeared on the market, and real customers started using the portal, things got complicated. On one side the team had a roadmap with new features they wanted to create for the platform. Although packed with items it was controllable. They created a time plan in a similar way to how they did it earlier, and then they tried to execute this plan through Sprints.

In addition, there were bugs that needed to be taken care of. The bugs were numerous but still controllable. The team prioritized them and always took a few of the highest priorities into a Sprint. The difficulty was new bugs that occurred during development. This caused prolonged development time, but this is the story for some other case studies.

What really made things complicated were new requests by the users. They were totally without control. The editors and journalists of the sports news were coming with immediate requests for new developments. Usually, those were requests for new features that should support a marketing campaign by some of the advertisers. Despite the attempts of the team to introduce some predictability and controllability into request creation by the client, due to political reasons all of them failed.

In this situation Sprints were useless. Planning was done knowing that it would stand for a couple of days, and then it would be changed. Sprint goals, consequently became just a formality to be done at the beginning of the sprint because everybody knew they wouldn’t be achieved. With this the morale of the whole team was low, they lost their purpose and felt that they were just being thrown some random tasks to finish as soon as possible. They all felt as if they were not creating any value at all.

How did we help?

With this setup at stake, it was proposed that the team switch from Scrum to Kanban, another Agile framework, but less strict when it comes to time-boxing, but more strict when it comes to doing several things at the same time. This was a meaningful decision considering the context in which the team was working. However, the team was inexperienced in working in this framework, so they looked for help on how to increase the team’s knowledge quickly.

The solution was Kanban Fundamentals training that was tailored exactly for this situation – putting teams up to speed with one of the most used Agile frameworks in no time. Over the course of one day, the whole team got acquainted with the framework.

They understood its main concepts; differences, similarities, and potentials to be combined with Scrum; the importance of work in progress, and why it has to be limited. As this is not a purely theoretical course but encompasses practical exercises as well, the team felt confident in actually trying the framework after it.

However, once the course was over Kanban should be established as a new way of work. This meant, not only setting up the Kanban board but also performing proper change management in the organization.
Here we helped in three ways:

1. Creating a communication strategy for Kanban introduction. This encompassed an explanation of the framework, examples of use and good practices, dynamics and channels for internal communication, and the plan of implementation that was transparent and clearly communicated throughout the company, including the clients.
2. One-and-a-half-hour workshop with the clients on the new working process that takes into recognition their needs.
3. Setting up a new Kanban project in the tool the team was using for tracking their work.

With this, the team was ready to go. Of course, the introduction of new things never goes without hiccups and the team was only at the first part of their learning curve, but they were ready to start and ready to improve both their work and the overall sense of purpose.

Learnings

The benefits that this endeavor had were threefold:

For myself:

• Validation of Kanban’s Effectiveness: This experience reinforced the effectiveness of Kanban in dynamic environments with unpredictable workloads.

In a journey similar to what is shown in this case study, supporting the team with an experienced mentor is always beneficial, especially when change management is needed, and when things are being set up in a new way.

If you are facing similar hurdles in your journey, contact us, and let’s chat about how we can help and supercharge your team’s performance.