Abstract
This is the second blog post of a series where we are sharing our experience in adopting Agile within a large technological company with over 300,000 employees across 5 locations.
In our last post, we introduced how we began implementing Scrum and how we focused on achieving the quick win that would have the most significant impact on the company, our sponsor, and the teams we were working with: boosting predictability.
We enabled the company to improve its forecasting abilities and to better manage risks by providing trustworthy information to inform their decision-making process, and, as we said: “The teams would see their urgencies decrease, as the organisation would be capable to organise and plan weeks in advance.”
Did we succeed in reducing the number of urgent tasks that the teams received? Keep reading to find out.
Everything is urgent
When managing backlogs and daily work, we need to understand that urgency and importance are not the same, as Dwight D. Eisenhower famously said. We can use his popular matrix to help us understand how to manage both. Urgency and importance are intrinsically related; how we prioritise tasks can define what is important to us, and in most cases defines what an “urgency” really is, and therefore, how we manage them.
As we said, we managed to increase the teams’ predictability by understanding the organisationally complex environment, crucial in large technological companies. However, we also found a new impediment – using Scrum wording: although we could forecast how much we were going to deliver, the teams had a challenge forecasting what.
This is a struggle that some organisations and teams face every day – maybe not this situation exactly and maybe not as often or critical, but the impact to organisations remains the same.
Picture this: we finished a Sprint Planning and, after improving from past experiences, we finished it with optimism: the team understood what the priorities were and, for the first time, we managed to have quite a relevant Sprint Goal – not only a list of tasks to finish.
The day next in our daily meeting, everything was going quite well: the team members were sharing news, asking for help, collaborating… And then our sponsor, the Line Manager, came to us and said:
- “I just had a conversation with upper management, and they requested us to prioritise [something] – it is really urgent.”
This [something] was not our sprint goal. How could this situation be happening? The team had planned with all the available information at that time! Then they did what they needed to do: they changed the Sprint Goal and the Backlog to adapt as soon as possible.
You may say “It is OK, being Agile is just that: being able to inspect and adapt to changing circumstances.” And you are right; however, the story doesn’t end here. On day 3 of the sprint, another Line Manager contacted a team member and asked them to prioritise [another something] because it was urgent and could negatively impact the company.
After seeking help from our Line Manager, we needed to adapt our Sprint Backlog and even our Sprint Goal once again. In just three days, we had to change our plans three times due to urgent requests.
3 days, 3 different plannings, two urgencies.
Context and impact
When facing a challenge, we usually tend to focus first on how we can manage it or on what we can do to reduce the impact or avoid it. Instead, as Simon Sinek says, we should start with WHY. Why is it urgent? Why was it not identified before?
Following what we explained in the previous post, large organisations are highly complex. At that time, the teams were developing firmware simultaneously for five new products, and the R&D area had several dependencies and encompassed 200–300 people. Understanding the ‘why’ is sometimes very hard, given the several people involved with different contexts and needs.
To start understanding why we were having urgencies, we focused on understanding the context of our stakeholders – those who were asking us for changes due to urgencies. Why was it urgent? What had changed from our last conversation? How was it impacting them?
Understanding what was behind the urgency was the first step, but we did not stop there. We explained our context and the context of our other stakeholders, and we shared with them the impact the changes they were asking for would have. Questions such as “Have you thought about how you may impact these other products/teams with your request?” are powerful and make everyone aware of everyone’s reality and context. Knowing the context and the impact that our actions would have is the first step towards trust, openness and collaboration. It also improves our decision making because we end up making decisions with more available information than before.
Who accomplished it and how did we do it? We agreed to empower our Product Owners (PO). We helped them move from the general understanding that their accountability was only to set priorities and manage the team’s backlog to a facilitation role. Their new accountabilities were to facilitate these conversations, deeply understand our context and the context of their stakeholders and the company, and then generate agreements. Their main goal was to boost trust and collaboration among stakeholders (and between POs as well!).
While the PO role is not new (it was first introduced in the Scrum framework in the early 2000s), we need to understand that each company and organisation approaches organisation and agility in its own way. Some adopt frameworks like LeSS, SAFe or Scrum, where the role is clearly a pillar, while others “cherry-pick” what they think is best for them and experiment with different techniques, frameworks, methods, etc. Both options have their pros and cons, but in our experience, success is more related to attitude (willingness, discipline, optimism, etc.) than the method or framework companies decide to use.
In this case, even though the company wanted to adopt Scrum (as we saw in the first post), the PO role was not usual and most of the teams did not have one. By acting as ‘pioneers’, we also managed to help other teams and other areas to adopt similar ways of working.