In every organization, as it grows and the number of employees increases, there is a desire to make improvements on various levels. The same was true for us. More and more projects, more employees, dispersed teams, etc. During casual conversations every now and then we would come up with ideas and suggestions for improvement, but that’s where it ended. Finally, we decided to make big changes....
Episode 1 Change
We planned a series of meetings to create a big change plan. We thoroughly analyzed the whole thing at a high level as an organization, at a low level going into the work process in specific projects, we analyzed how we work with individual clients, we considered the characteristics of the whole team and how individuals work. We looked at what works at each level and then looked for ideas to improve bottlenecks.
Episode 2 Planning
Roadmap for changes. We had a perfect plan, or at least we thought we did. Everything we wanted to improve we had laid out in Trello as a Product roadmap. We felt that we wouldn't be able to implement everything at once, so we split everything into smaller quarterly implementations. At this stage we had everything laid out, planned and we were sure that our plan was complete. In short, we knew what we wanted to achieve, why we wanted to achieve it and how we wanted to achieve it. Unfortunately, our plan at this stage did not include one important thing that was crucial to the whole. Additionally, upon later analysis of the whole, our plan was 90% doomed to failure from the start, but more on that later.
Episode 3 Implementation
When the whole thing was ready, we started implementing smaller elements. In the first phase the process went very smoothly without any major problems. Of course, there were delays and corrections, but they did not have a major impact. There were more and more changes, and they were bigger and bigger. The range was really wide, as it ranged from preparation for the implementation of projects to the development process. What is also important, some modifications were divided into several versions because we knew from the top down that they are too big to be implemented at one time. Such a direction turned out to be a very good approach because individual aspects showed us if we were going in the right direction.
Episode 4 FAILURE
Everything was going well, but one element (at first quite trivial) showed us how wrong we were. Everyone is now surely wondering what was left out that had such a big impact? We didn't exactly think about it either, but we didn't know it could have such an effect on the process. However, taking what happened as a whole helped us a lot later on.
Now what had such a big impact on the whole process that the changes didn't work out for us? Christmas, new year and a longer break :) Yes, this very period of the year showed us that what we were doing was:
- Forced change – what we wanted to alter was not equivalent to what our people wanted.
- We had to persuade the team to come to a new way of thinking.
- The team didn't always know why we were doing it. So, they didn’t see the value.
- Tasks were delegated, not distributed.
- Of course, a few other more things could be mentioned here.
However, the most important and difficult thing was that by the way we made the change, there was an aspect of control and supervision of the things we modified. We had to check that the team was definitely implementing the changes. We didn't know when to do it, who should do it, or why we should do it!
What did the longer break and the return of the team at different times do? Because the change was forced and not worked out, we started to fall back into old work habits. Our vision started to blur, because if you forgot about a new element once and nobody paid attention to it, why do it? And so element after element disappeared...
Episode 5 Analysis of the whole or why it didn't work out
After swallowing the bitter pill of defeat, we took to analysing the whole thing again. Lessons were learned very quickly, and we knew two things.
We knew we needed changes and improvements.
We needed to find an additional tool, technique, or something else that would help us.
We knew precisely what we needed and felt exactly what would make it happen. We decided to introduce Scrum framework to the organization, but we started the implementation in a bit non-standard way. Very often companies make one basic mistake when implementing Scrum. They want to implement it all at once. Which often also brings chaos to the daily work and causes resistance of the team. We went through this during our implementation, so we knew that we had to approach the whole thing differently.
We started the implementation of Scrum from the very end, that is from Sprint Retrospective.
Probably most of you know what Sprint Retrospective is, but let me quote the Scrum Guide to make it clear for everyone.
"The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."
Why did we start with this? It’s really simple. We wanted to listen to the voice of the team and this time implement what everyone wants, and thus there will be no need to control and supervise the change. On the meeting we also proposed our solutions, discovered how people see it and how we need to redefine individual elements to achieve consensus. After collecting everything, it turned out that the team wants and needs a transformation, but they need changes that were worked out together, not imposed.
How did we conduct the first retro?
Lots of people, after reading the Scrum Guide and wanting to do a sprint retrospective, look for the big tools. In this case we started very simply.in a very simple way. :)
Our board was a desk :). A desk that we divided with a tape into individual elements. Then on the post-its everyone wrote their ideas for improvements. At the end, during a joint discussion, we chose the improvements that we wanted to introduce. We taped the selected elements to the wall. :)
This is very important if you want to introduce Scrum in your organization. Start calmly without any big tools, for which you will have to spend several days analyzing and research. Start with the simplest solutions. Check if this is the right direction – inspect everything and adapt it.
Episode 6 Effects
We are very pleased with the results of this approach. Together with the team we developed:
- Changes in the development process, DoD, working on goals, raised standards.
- Improvements on particular stages.
- We began to develop more strongly as a company.
- We jointly supervise the introduced changes and analyze the effects.
- We realized that the team looks at some elements differently.
- We implemented full Scrum into the projects.
- We constantly make inspections and adaptations to improve our work process.
- Faster development for our clients and much better collaboration with clients.
- A very big change was the move from Jira to Clickup. One of the main reasons for this move is the ability to adapt very quickly.
However, the most important thing was that the team felt that they have a real impact on our projects, that it's no longer just the implementation of tasks but a full work on the product.
Currently, many of our improvements concern raising the standards from the technical side and improving the product that we make for clients.
Currently, the hottest words are agile, Scrum, change, transformation, agility, etc. Everyone wants to work agilely, faster, more effectively, but very often we forget about one really essential aspect. We talk about values, but we want to impose ready-made solutions on the team. Work as a group and develop as a team because this is the only way to arrive at solutions that are good for everyone.
Remember that if you want your Sprint Retrospective meeting to be valuable, everyone should be well prepared. The team needs to know what value the meeting will bring. The whole meeting must also be properly facilitated; otherwise, the team will shut down and the whole thing will not bring the right value.
If you’d like to talk in details about Scrum implementation, let me know ->[email protected]