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 all 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 work process at a high level but also at a low level going into the specific projects and the way we work with individual clients, we considered the characteristics of the whole team and how individuals work. We looked at what works the best for us and then looked for ideas to improve bottlenecks.
Episode 2 Planning
Roadmap for changes. We had a rock-solid 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 arranged and we were sure that our plan was complete. In short, we knew what, why and how we wanted to achieve it. Unfortunately, our plan had one crucial oversight. Additionally, upon later analysis, our plan was 90% doomed to failure from the start, but more on that later.
Episode 3 Implementation in the development team
When the plan 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 on the progress. The changes were becoming gradually bigger with time, as well as their amount. Those changes ranged from preparation for the project implementation 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. This direction turned out to be an adequate approach with individual aspects showing 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 this major oversight? We didn't exactly think about it either, and we didn't know it could have such an effect on the process. However, drawing conclusions from what happened 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 members 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 things could be mentioned here.
However, supervising and controlling the changes turned out to be the most important and difficult aspect. We had to check that each team member was definitely implementing the changes. We didn't know when to do it, who should do it, or why we should do it!
So how do the long break and the return of the entire team at different times have impacted our process? Because the change was forced we started to fall back into old work habits. Our vision started to blur, we started forgetting about new elements and nobody paid attention to that. Element after element started disappearing...
Episode 5 Scrum team analysis of the whole or why it didn't work out
After swallowing the bitter pill of defeat, we started analysing the whole thing again. Lessons were learned very quickly, and we noticed two key 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 non-standard way. Very often companies make one basic mistake when implementing the Scrum process. They want to implement it all at once. Which often also brings chaos to the day-to-day work and causes the development team members to resist. 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 feedback of each team member and this time implement something that everyone wants, and thus there will be no need to control and supervise the change. At 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 entire 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 are looking for the big tools. In this case, we started in a very simple way - simply.in :)
Our board was a desk :). A desk that we divided with tape into individual elements. Then on the sticky notes, everyone wrote their ideas for improvements. In 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 researching. Start with the simplest solutions. Check if this is the right direction – inspect everything and adapt it.
Episode 6 Sprint retrospective meeting effects
We are very pleased with the results of this approach. Together with the team, we developed the next steps:
- Changes in the development process, DoD, working on goals, raised standards.
- Improvements in particular stages.
- We improved the process of our company development.
- We jointly supervise the introduced changes and analyze the effects.
- We realized that the team reflects on some elements differently.
- We implemented the full Scrum process into the projects.
- We constantly make inspections and adaptations, improving work processes.
- Faster development for our clients and much better collaboration with them.
- 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, most importantly the development 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 standpoint 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 and more effectively, but very often we forget about one 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 reach solutions that are good for everyone and achieve success.
Remember that if you want your Sprint Retrospective meetings 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]