After four years of working in hardware production as an analog circuit designer, I decided to make a change and took on the role of a software validator in embedded systems. At that time, my knowledge of project management was primarily limited to what I had learned during my studies and the experiences I gained while working as a designer. In the context of projects, the scope and requirements were defined, the manager allocated the necessary resources to meet deadlines, and then tasks were distributed. Engineers reported progress in weekly meetings, and in the case of bigger problems, they escalated issues to the manager. In the background, Gantt charts and the critical path were in use — that was the magic of project management.
My first encounter with what could be called Scrum (albeit loosely) happened on the first day of my new job in software development. I learned that we were going to a “standup,” where we would have a “call” with a client engineer. Without asking any questions, I went to a brief meeting where each of my new colleagues reported on what they worked on yesterday, their plans for today, and any challenges they encountered. At one point, our team leader said the magic words: “…we’ll deal with that in the next sprint.” The question immediately popped into my head: What is a sprint? I figured I’d find out in due time. The meeting went smoothly, and I was surprised by how dynamic everything was. Afterward, everyone went back to “normal” work. When I began asking about the mysterious sprint, I learned that “we work in Scrum here.”
Today, seven years later, I know that my first experiences with Scrum weren’t entirely representative. Besides the bi-weekly meeting where tasks for the sprint were assigned and the daily short standups, there wasn’t much that I hadn’t seen before. Two months passed like this until one morning we found out that the project we were working on was suspended. As it later turned out, this was a fortunate twist of fate because the next project I joined was completely different. A new team was formed, led by my colleague, who had just completed training with Krystian Kaczor and obtained the PSM I certification. He was full of enthusiasm and determined to introduce Scrum to the new team. He suggested I attend the training as well, which I gladly accepted because, during a few coffee conversations, he had infected me with his excitement. The training left a huge impression on me. The most exciting part was that developers decide for themselves how to complete their tasks. The fact that processes implemented in daily work would also be our decision, and that we would discuss improvements during sprint retrospectives, was incredible to me. I passed the PSM I exam, and we began implementing Scrum in our team. The team leader served as the Product Owner, and I, in addition to being a developer, took on the role of Scrum Master. We worked in this configuration for about thirty sprints. We introduced many interesting practices and, most importantly, understood the concept of Scrum well. At that point, I concluded that being a Scrum Master was a piece of cake! Every developer, once you explain Scrum principles, will be thrilled. They’ll be happy to decide how to accomplish their tasks and to influence the organization of daily work with the team. They’ll discover they’re being treated as partners rather than task executors, and they’ll appreciate and engage in Scrum.
After my first team change, we reviewed the lessons learned. I changed employers and joined a validation team, where, in addition to engineering work, I was tasked with implementing Scrum and serving as the Scrum Master. When I introduced the concept to developers, I was met with lukewarm enthusiasm, and sometimes even resistance. At the time, I assumed the problem was in my explanation. I armed myself with patience and spent the next year refining my message and working with the team.
In my next organization, I was hired as a full-time Scrum Master, which significantly accelerated my growth. I worked with five teams, so my experiences were diverse. I had a prepared narrative, developed in the previous company, which gave me confidence that what I was saying made sense. However, the following months brought new examples of doubts, reluctance, and even resistance. When explaining to developers what Scrum requires of them, I heard: “Why plan? Just give us a list of things to do, and we’ll get it done,” “I’m not an analyst! I won’t break down tasks,” “Why should we decide on the development process? You’re the Scrum Master; that’s your job!” The more I listened, the more I realized my earlier conclusion was wrong. Maybe not entirely, but in a significant way: not every developer wants to decide how they perform their work and how the process functions. As in nature, here too, we have a normal distribution. There’s a small group of enthusiasts waiting for the freedom Scrum brings. There’s a large group of moderates, who carefully observe changes around them, and a small group of active resistors. They see Scrum as a radical change that increases their responsibilities. Further exploration made me realize how complex, difficult, and even painful the process of changing beliefs, views, and habits can be. The quote by Józef Ignacy Kraszewski, “People fear change, even for the better,” captures this wisdom well. As an enthusiast myself, I mistakenly thought this was a universal approach. More cautious and conservative individuals might view Scrum implementation differently.
I understood that this knowledge is key for a Scrum Master. If you’re lucky, you’ll have one or two enthusiasts on the team. There will likely be a few moderates who, with the right approach and time to adapt, will embrace the changes. You can be almost certain there will be one or two malcontents. Knowing this allows the Scrum Master to adjust their strategy. Engaging enthusiasts can set a precedent and serve as a good example for the rest of the team. You don’t need to convince the whole team to try an experiment — sometimes one volunteer is enough. If the result is positive, it can provide empirical evidence to persuade the undecided. Progress can happen gradually. Change agents are excellent catalysts for transformation, and their support is invaluable.
On the other hand, the malcontents provide valuable insights into risks and threats. Involving them in discussions to express their doubts helps address potential problems during the transition. Properly moderating these discussions supports long-term communication and trust-building within the team. Understanding the diverse personalities in a team enables appropriate communication and patience in the challenging process of implementation.
After four years of working in hardware production as an analog circuit designer, I decided to make a change and took on the role of a software validator in embedded systems. At that time, my knowledge of project management was primarily limited to what I had learned during my studies and the experiences I gained while working as a designer. In the context of projects, the scope and requirements were defined, the manager allocated the necessary resources to meet deadlines, and then tasks were distributed. Engineers reported progress in weekly meetings, and in the case of bigger problems, they escalated issues to the manager. In the background, Gantt charts and the critical path were in use — that was the magic of project management.
My first encounter with what could be called Scrum (albeit loosely) happened on the first day of my new job in software development. I learned that we were going to a “standup,” where we would have a “call” with a client engineer. Without asking any questions, I went to a brief meeting where each of my new colleagues reported on what they worked on yesterday, their plans for today, and any challenges they encountered. At one point, our team leader said the magic words: “…we’ll deal with that in the next sprint.” The question immediately popped into my head: What is a sprint? I figured I’d find out in due time. The meeting went smoothly, and I was surprised by how dynamic everything was. Afterward, everyone went back to “normal” work. When I began asking about the mysterious sprint, I learned that “we work in Scrum here.”
Today, seven years later, I know that my first experiences with Scrum weren’t entirely representative. Besides the bi-weekly meeting where tasks for the sprint were assigned and the daily short standups, there wasn’t much that I hadn’t seen before. Two months passed like this until one morning we found out that the project we were working on was suspended. As it later turned out, this was a fortunate twist of fate because the next project I joined was completely different. A new team was formed, led by my colleague, who had just completed training with Krystian Kaczor and obtained the PSM I certification. He was full of enthusiasm and determined to introduce Scrum to the new team. He suggested I attend the training as well, which I gladly accepted because, during a few coffee conversations, he had infected me with his excitement. The training left a huge impression on me. The most exciting part was that developers decide for themselves how to complete their tasks. The fact that processes implemented in daily work would also be our decision, and that we would discuss improvements during sprint retrospectives, was incredible to me. I passed the PSM I exam, and we began implementing Scrum in our team. The team leader served as the Product Owner, and I, in addition to being a developer, took on the role of Scrum Master. We worked in this configuration for about thirty sprints. We introduced many interesting practices and, most importantly, understood the concept of Scrum well. At that point, I concluded that being a Scrum Master was a piece of cake! Every developer, once you explain Scrum principles, will be thrilled. They’ll be happy to decide how to accomplish their tasks and to influence the organization of daily work with the team. They’ll discover they’re being treated as partners rather than task executors, and they’ll appreciate and engage in Scrum.
After my first team change, we reviewed the lessons learned. I changed employers and joined a validation team, where, in addition to engineering work, I was tasked with implementing Scrum and serving as the Scrum Master. When I introduced the concept to developers, I was met with lukewarm enthusiasm, and sometimes even resistance. At the time, I assumed the problem was in my explanation. I armed myself with patience and spent the next year refining my message and working with the team.
In my next organization, I was hired as a full-time Scrum Master, which significantly accelerated my growth. I worked with five teams, so my experiences were diverse. I had a prepared narrative, developed in the previous company, which gave me confidence that what I was saying made sense. However, the following months brought new examples of doubts, reluctance, and even resistance. When explaining to developers what Scrum requires of them, I heard: “Why plan? Just give us a list of things to do, and we’ll get it done,” “I’m not an analyst! I won’t break down tasks,” “Why should we decide on the development process? You’re the Scrum Master; that’s your job!” The more I listened, the more I realized my earlier conclusion was wrong. Maybe not entirely, but in a significant way: not every developer wants to decide how they perform their work and how the process functions. As in nature, here too, we have a normal distribution. There’s a small group of enthusiasts waiting for the freedom Scrum brings. There’s a large group of moderates, who carefully observe changes around them, and a small group of active resistors. They see Scrum as a radical change that increases their responsibilities. Further exploration made me realize how complex, difficult, and even painful the process of changing beliefs, views, and habits can be. The quote by Józef Ignacy Kraszewski, “People fear change, even for the better,” captures this wisdom well. As an enthusiast myself, I mistakenly thought this was a universal approach. More cautious and conservative individuals might view Scrum implementation differently.
I understood that this knowledge is key for a Scrum Master. If you’re lucky, you’ll have one or two enthusiasts on the team. There will likely be a few moderates who, with the right approach and time to adapt, will embrace the changes. You can be almost certain there will be one or two malcontents. Knowing this allows the Scrum Master to adjust their strategy. Engaging enthusiasts can set a precedent and serve as a good example for the rest of the team. You don’t need to convince the whole team to try an experiment — sometimes one volunteer is enough. If the result is positive, it can provide empirical evidence to persuade the undecided. Progress can happen gradually. Change agents are excellent catalysts for transformation, and their support is invaluable.
On the other hand, the malcontents provide valuable insights into risks and threats. Involving them in discussions to express their doubts helps address potential problems during the transition. Properly moderating these discussions supports long-term communication and trust-building within the team. Understanding the diverse personalities in a team enables appropriate communication and patience in the challenging process of implementation.
Popular Categories
Popular Tags
Archiwa