Our organisation is constantly changing — we manage this with Scrum
Part 4: Successes and set-backs
Part 4: Successes and set-backs
This article is part of the following series:
Our organisation is constantly changing — we manage this with Scrum
Introductionmedium.com
Our organisation works in a complex environment. We have to adapt constantly to remain technology leaders. Sometimes we have pivotal events that come across as drastic changes (like forming a new organisation structure), but in reality the changes occur organically with pivotal moments that define the current direction.
Our organisation is constantly seeking to improve and therefore is constantly changing.
Work on the items deemed important by our stakeholders
In part 2 I brought forward that we got feedback that we were detached from the people that we worked for. This is serious. So we made an effort to show our faces at the events where our stakeholders were.
We also decided to work on the items that were specifically brought forward by the stakeholders. We started to work on things that were seen as important by them. The results of this were great. Not only did we manage to take away impediments and hurdles, we also showed that we weren’t detached from reality. As a result our Sprint Reviews became even more positively received and interactive.
Fast results by creating transparency
Our work started to get noticed. And the main thing we did was to add transparency.
Below are two examples.
Example 1 — Transparency on SLAs
We deliver software so we have to deal with production incidents. And the teams believed that they did a good job in resolving the incidents. Still we had departments and managers telling us a totally different story. We had this situation for years, involving many discussions and efforts to have it improved while the people that worked on the incidents weren’t convinced we had too. It all fell flat because there was no conviction that we needed to change.
Then we got a request to make our Service Level Agreements transparent. So we decided to add an item about it to our Sprint Backlog. The activities entailed nothing more than asking the right person about what our SLAs were and then present it to our stakeholders. People were shocked: they said that the SLAs we unreachable in the current situation. Which was indeed true. The transparency that we provided spawned many new topics on our backlog, like:
We needed to separate real incidents from requests that didn’t categorise as incidents, ruining our SLAs;
We needed to find out if and how we were penalised for not meeting the SLA’s;
We needed to check if the SLAs could be altered.
Example 2 — The mythical PCI regulations monster
One of the things that was considered to be a major pain was that we — as financial institution — needed to adhere to PCI regulations while we also wished to move to full CI/CD. Also here many meetings were held. We visited other companies, ahead of the game. But we didn’t find an answer how to beat this mythical PCI regulations monster.
We decided to address this too. We wished to clarify what the PCI regulations are and what steps would be required to adhere to it. It turned out we only needed to do minor fixes in the process when moving to full CI/CD. The easiest thing in the world. Again we provided a little bit of transparency and with that we removed a huge apparent blocker.
So we managed to have many quick wins by making things transparent for all that were only known to few. We could do this because we decided to focus on it and deliver an answer to our stakeholders by the time we have our Sprint Review.
No time for this!
But the work of the Scrum teams was only done by about 50% of the people in the teams. The others had a hard time to commit and some didn’t participate at all. Most of them couldn’t find the time to do their daily work and then also participate in the Scrum Team.
The strange thing was that these mostly were the managers with the primary job to enable their teams. Which exactly was what the Scrum teams did. So somehow these people were either doing other things than their primary job OR it now became painfully clear — with the introduction of the Scrum Teams — that they had too many things on their plate.
We decided to take drastic measures and discussed with the people that couldn’t commit that they would move away from the team so that they could focus on their daily work again. They were replaced by volunteers. Which helped a lot. Both teams profited from the new energy that came with these motivated newbies.
Conclusion
We started to pick up items that were brought forward by our colleagues — our stakeholders — and got awesome positive feedback in return. And we started making seemingly big obstacles transparent. This transparency allowed all of us to see what the items really were about and with that major issues were reduced to simple topics or resulted in clear follow-up actions. The magic of transparency in full glory. The participation issue was tackled by just swapping those that couldn’t commit with volunteers. Which had an immediate positive effect too.
My next article will be about how we got into a flow after around 7 Sprints.