The Story of How Not True Scrum Changed Teams Performance

My experience with Agile methodologies may not align perfectly with specific frameworks. It’s important to note that their creators formulate the fundamental principles of an ideal Scrum or Kanban in their guidelines. They emphasize that deviating from these principles creates a process that is not true ‘Scrum’ or ‘Kanban’.

Сollaborating with real-world teams shows that certain guideline principles may not be universally suitable. I believe true agility is the ability to adjust any methodology to specific needs, addressing particular challenges. So, my approach involves leveraging the principles and tools of Agile methodology, achieving results with minimal disruption.

In this article, I want to remind the fundamental principles of Scrum and delve into examples of its implementation within engineering and design teams. I enclose ‘Scrum’ in quotation marks because, by strict guidelines, it may not fully adhere to the prescribed framework.

What is Scrum?

Scrum is a framework for developing and sustaining complex products. It consists of self-managing cross-functional teams → groups of people with different expertise areas who work for one outcome. They work in iterations that allow businesses to change their requirements.

Scrum is based on empirical process control theory. It consists of 3 principles

1. Transparency: Done means done
2. Inspection: Check on progress
3. Adaptation: Change the product based on perfection

As a general reminder of the framework not to take more time, I attach the schema, the Scrum skeleton that shows the workflow and brings up Scrum Events and Scrum Artifacts.

Scrum Skeleton, Events and Artifacts

Now let’s go to my illustrations of goals that were achieved with some of the instruments that are used in ‘Scrum’.

‘Scrum’ Implementation Results

Engineering Team

When I first started working on the project, there was absolute chaos. The tasks were not planned, the requirements were changing every day, and engineers did not finish anything on time. It was impossible to finish any new feature without fundamental changes in the workflow. Recognizing the need for a change, we decided to introduce and test some Scrum components.

The development team consisted of 7 people and a dedicated product manager who worked 12 hours a day, doing the work of a Scrum Master and a Product Owner. P.S. In the traditional Scrum, these are necessarily two different people.

1. Scrum Events — First Iteration
   Initially, we implemented Sprint Planning and Daily Scrum Meetings, with the Kanban board as a supplementary task monitoring tool. The scope of tasks became firmly established and remained unchanged throughout the sprint. This adjustment reduced the number of meetings that distracted developers from their work, fostering increased concentration on tasks and enhancing the overall quality of performance.
2. Scrum Artifacts
   We already had a Product Backlog with all the initiatives, so we introduced a Sprint Backlog and the term ‘Increment’. This allowed us to systematically break down our final goal into manageable steps so that we could release gradually and consistently.
   This approach enabled us to constantly demonstrate the product’s value to business stakeholders and incrementally develop functionality without major releases that might impact the application’s operation.
3. Scrum Events — Second Iteration
   When the work on tasks became more predictable, we added a Retrospective Meeting.
   This addition allowed us to gather feedback from each team member, facilitating regular implementation of changes that improved the overall quality of our workflow and communications. Consequently, our documentation, preparation, presentation of new functionality, and creation of technical specifications encountered fewer issues and questions.

Incorporating these principles and tools into the team was an almost seamless process, as we wanted to transition toward a more comfortable and efficient workflow for our product. The real challenge lies in maintaining consistency and quality in preparing each event or document, and ensuring that our effectiveness continues to evolve positively.

Our results in numbers
We were working in 2-week sprints and using story points (SPs) where 1 SP equaled one working day for one engineer.

• Before the changes, our team of 7 people closed approximately 40 SPs
• After them, in 3 sprints our total performance increased and became 65 SPs (with a conditional maximum of 70)

The satisfaction of business stakeholders has increased as well and resulted in a reduction in questions related to organization and development speed. This positive shift also improved the general working atmosphere.

So, here is the Scrum Sceleton with highlighted parts that were implemented (almost everything).

Green highlights are what was implemented into the Engineering team process

Design Team

In small projects lacking specific rules, designers can get lost in terms of organizational support from product or project management. This can lead to a chaotic and opaque work process, with solution updates occurring inconsistently and sometimes not at all.

I worked in a team of 3 designers who strongly disliked task trackers and the idea of task control. After facing challenges and missing the other deadline, we decided to reorganize the process with minimal intervention in their workflows.

We introduced

1. A Daily Scrum meeting where we updated each other on every task,
2. A Kanban board with tasks, descriptions, and attached documents for better visibility and collaboration.

In short, this process resembled Kanban with deadlines, aligning with developer sprints to ensure everything was ready before engineers took on the work. After the Daily Scrum meeting, if necessary or if questions arose, we stayed to discuss solutions together.

With these minimal changes, we successfully met task deadlines, improved the quality of work through regular discussions, and enhanced task transparency and understanding for all team members.

Here I also attach the Scrum skeleton to see what was implemented (almost nothing).

Green highlights are what was implemented into the Design team process

In conclusion, I’d like to emphasize that improving process efficiency doesn’t always require the integration of every described parameter, role, event, or artifact. It’s crucial to be adaptive and selectively incorporate elements based on the specific needs of a given team, addressing and eliminating particular challenges.

I firmly believe that each team and company possesses its own unique identity. Therefore, the key lies not in conforming to a methodology or framework but in adapting it to fit your team and its distinct needs. This approach is essential to effectively communicate the value of change and encourage individuals to step out of their familiar but chaotic comfort zone.