Developers Must Understand That It Isn’t Just About Coding

Developers Must Understand That It Isn’t Just About Coding

The Scrum events may appear to be major disruptors for Scrum teams. But they serve a purpose. The events exist to grapple with complexity.

Every once in a while, I have an interesting conversation with a software developer of a Scrum Team struggling with interruptions. Here’s a striking example:

“I kind of liked the old times better, when we were able to simply do our work and code. Nowadays I have to go to all these Scrum meetings. They are disastrous for my flow. Just let me code.”
“You mean when we used to work in projects with detailed long-term plans?”
“Yes. There were months with hardly any meetings. I would sink my teeth in a topic and code along. I could tap into all of my creativity. Now we tend to forget software development is knowledge work.”
“But I remember these times were far from ideal.”
“Sure, we had our struggles. Crunch time at the end of the project wasn’t fun. But once we finished a project, we had a sense of accomplishment.”
“How often did we finish a project in those days?”
“You got me there. Not often, I guess. We finished a couple each year?”
“Indeed, we were hardly delivering anything. But what was worse, we didn’t deliver what the user wanted.”
“Here I have to disagree. The user had clearly stated what they wanted us to build. And then, when we deliver it according to specs it wasn’t what they wanted. Yeah, right. I see this as a lack of professionalism of those users.”
“Are you ok to discuss this a bit more? I believe it is getting interesting.”
“Sure. It’s lunchtime anyway.”

We then talked about it for another hour. The main conclusions are listed below.

The real cost of task switching

I understand the dissatisfaction of developers who believe Scrum is interfering with their workflow. They’ve made a good point. Context flipping is a true phenomenon. When you transition from one task to another, your brain needs to adjust. Even if the disruption is little, this holds.

When a developer working on a piece of code is interrupted for a Daily Scrum, she will suffer from context switching. Even if it is only 15 minutes. Context switching between two jobs can cost you as much as 20% of your productivity.

So this is a serious problem. It is a problem that the developer and her team must deal with. It begs the question: why do agile methodologies such as Scrum and Extreme Programming entail daily meetings? Let’s get a little more into this.

The purpose of developing software

This brings us to the aim of software development. Scrum Teams never create something just to create it. They strive to produce something that benefits the consumer, the user, and/or the business. Everything a Scrum Team does is to create a value increment.

Every Sprint, the team focuses on the aspect of the project that is thought to offer the most value. The team and its stakeholders check in after each Sprint to see if they accomplished this and what they could focus on next.

This rhythm causes problems for several developers I know. They believe that sprints are insufficiently long to produce something truly beneficial. They might wish to investigate what they can do about it. They could, for example, aim to make their Product Backlog Items smaller so that they can fit them within a Sprint.

If this fails, they might consider having longer Sprints. However, this comes at the cost of fewer opportunities to double-check that you’re building the appropriate item.

This is something that the vast majority of the devs I know are fine with. Sprint Planning, Sprint Review, and Sprint Retrospective are all scheduled for the beginning and end of each Sprint. It does not affect their productivity. Daily Scrums and refinement meetings are more problematic for them.

Complexity and creating software

The shortest Scrum event is frequently a source of annoyance. Many don’t appear to do it well, and it can be a huge stumbling block. The Daily Scrum, on the other hand, is an essential component of the Scrum framework.

Scrum deals with complexity, which is why this is the case. A Scrum Team assumes that knowledge is gained by experience, and they make decisions based on what they see (from the Scrum Guide 2020). They must take a step, confirm what they have done, and then decide what to do next based on their findings.

One of the reasons why teams operate in Sprints is to gain quick feedback. At the Sprint Review, they construct one or more Increments of their product and confirm this with their stakeholders. Then they decide what the next move should be. This method must be followed by Scrum Teams to achieve their purpose.

This functions in a similar way at the Sprint level. During Sprint Planning, the team determines the Sprint’s goal. They also figure out how they plan to achieve that aim. They are aware, though, that things may change. After all, their product is complicated.

The Daily Scrum comes into play here. The team uses this time to see if they are on track to meet their Sprint Goal. If this is not the case, they will alter their plans to maximize their chances of achieving this aim. To stay on track during the Sprint, the Daily Scrum is essential.

Scrum, complexity, and teamwork

In Scrum, you work as a team. As a team, you set goals and take steps to achieve your goal. This is a joint effort. This does not comply with the phrase “Just let me code.” There’s no “Tell me what to code and leave me be for a month.”

When members work on different tasks individually, it indicates a broken Scrum team.

It’s not about the number of lines of code or the most creative technique to construct your software. It’s all about discovering and collaborating to create a product that grows in value. It’s about making sure you’re going in the proper direction.

Coding is a necessary element of the work. The job is to create value. This is true, at least, for Scrum Teams.

Plan your events carefully as a team

I talked about the relevance of Scrum events and the effects of context shift. Both are important considerations. This is why a team must meticulously arrange its events.

The Daily Scrum could be scheduled at the start or conclusion of the working day to avoid disturbances. It could also be scheduled just before or after lunch. The event would be less disrupted as a result of this.

Then there’s the polishing. This is not an official Scrum event because each team can develop their work in their own way. Some will require it during Sprint Planning, while others may not require it at all. The majority of teams, though, will hold refining sessions. They should be held either before or after the Daily Scrum.

Common ground

The developer and I discovered common ground at the end of the lunch. She understood exactly what she needed to do. She would suggest to the team that the Daily Scrum be moved to the beginning of the day. She’d be able to concentrate on her coding for the remainder of the morning. She would also emphasize the importance of the Sprint Goal to the squad.

Wrap-Up

I understand the frustration of folks who have lost concentration as a result of switching from code to Daily code. Context flipping is a true phenomenon. When planning events, a Scrum team can avoid this by being aware of context flipping.

Scrum events may appear to be significant stumbling blocks for Scrum teams. They do, however, serve a purpose. The purpose of the events is to wrestle with complexity. The product settings of today are highly dynamic. What was true yesterday may no longer be true today. Teams must constantly inspect and adapt.

Traditional project management procedures aren’t always as meeting-intensive as they appear to be. This is ideal for developers who enjoy immersing themselves in a topic for an extended period of time. These methods, on the other hand, are designed for predictable contexts. They will not provide the value that complicated product teams and organizations want.

Scrum isn’t the only one who does this. These frequent feedback loops are also found in other systems that cater to complexity. In today’s world, it has become a reality of life. Our environment has shifted. Our approach to creating amazing products has changed as well.

Related Article:

https://medium.com/serious-scrum/developers-need-to-understand-its-not-about-coding-b4a18269d426