Tag: scrum

Posted on by

What’s our focus for improvement?

Here’s a story.

A development team was thrashing as they attempted to use Scrum to help them build a new application. They had numerous defects, some of which escaped to production and others that were caught within each Sprint. Many defects they thought they had fixed popped up again in production.

Their stakeholders had high expectations, as the team’s velocity was high. After several Sprints, it became clear they were not going to deliver all the planned features by the defined deadline. The news came as a surprise to stakeholders.

Continue reading What’s our focus for improvement?

Posted on by

Scrum pain in large organizations

Although “agile” has been around a long time, and Scrum even longer, many large organizations are only now undertaking “agile transformation” initiatives. People in those organizations who have not had experiences elsewhere with “agile” or Scrum are on the learning curve. I’ve noticed a handful of challenges that seem to be fairly common in these organizations.

Maybe it will be helpful to mention some of the common points of confusion and try to clarify them. I hope so, anyway.

tl;dr warning
Continue reading Scrum pain in large organizations

Posted on by

Handling Unplanned Work (Webinar)

Most software development teams today are using a process based on the idea of iterative development and incremental delivery.

Exactly how long the iterations are and how big the increments are may vary. Whether the iterations are treated as time-boxes or are used to establish a cadence may vary, too. But in general, teams are no longer using an end-to-end linear process for software development and delivery.

The details of various process models and frameworks differ, but the overall shape of the process is that teams carry out planning in waves or stages, zeroing in on near-term work close to the time they will start on it. Then they plan to bite off a reasonable chunk of the planned work and deliver it within a certain time frame.

We want to get in front of risks and external dependencies so that we will not stumble over them at the last moment, but on the whole we defer detailed planning and design until close to the time we will implement the software. That way, we avoid investing a lot of time in details that are subject to change.

We all know the mantra, “Plans are useless but planning is essential.” We all know that our plans are a best guess at a point in time, and nothing more. And yet, we all feel stressed when our plans are disrupted.

We know that unexpected things happen in the normal course of work. Priorities change. Urgent requests come in. Production issues occur.

And the processes we use – Scrum, Kanban, “Scrumban”, or some customized variation of these – include mechanisms to handle unexpected work gracefully.

Despite all these things, we still tend to react to unplanned work as if it were an emergency.

Is everything really an emergency? And what should we do when the unplanned work pushes our planned work aside?

In the context of software development, what’s an emergency, really? Is every unexpected occurrence a genuine emergency? How can we tell the difference in the heat of the moment?

Is it realistic to think a development team can take on more work than their capacity, just because the new work is deemed more important than other work in progress?

Is it sensible to gloss over software engineering principles, testing, refactoring, and general attention to detail in order to push code to production in a rush?

What are the mechanisms built into processes like Scrum and Kanban to handle unexpected, urgent work that wasn’t planned?

Why do people react as if they are required to complete everything that was planned in addition to every urgent, unplanned item?

What are practical ways to respond when an unplanned item comes up, that ensure we are delivering the maximum possible business value – with emphasis on the word possible?

Join us in the next First Monday Webinar to explore these questions and to consider the unique problems you are facing in your own organiztion. Two sessions with the same content are scheduled:

There’s limited participation, so that we’ll have time and capacity to explore your real-world situation. See you online!

Posted on by

Reducing process overhead in Scrum

In a social media discussion in mid-2019, several people expressed surprise at the idea that Scrum might include “overhead.” The confusion seemed genuine. Some people asked for examples. It seemed they were unable to conceive of “overhead” in Scrum.

The popularity of Scrum has led to an interesting situation in the Agile community. Many people view Scrum as The Answer. It’s the only and best way. There is no possibility to improve beyond Scrum. Everything in Scrum is valuable by definition.

In reality, every process includes overhead. We do things for customers/users, and we also do things to position ourselves to do things for customers/users. When we don’t distinguish between the two, we can fall into the trap of trying to perfect our overhead activities, rather than minimize them.

Continue reading Reducing process overhead in Scrum

Posted on by

Doing Scrum Perfectly

Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.

Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.

Continue reading Doing Scrum Perfectly

Posted on by

Scrum as a belief system

I came across a post by Damian Synadinos, dating from August 2017, entitled Thinking about Beliefs. He explores the idea of belief systems; how they come to be, how people interpret them, how adopters implement them, various things that can go right or wrong when people apply them, and what can happen when we question our belief systems.

After presenting a general model of belief systems, Damian goes on to illustrate his ideas by describing how he set out to question his beliefs regarding software testing; that is, his belief system around his work. He discovered that some of his previously-held beliefs about software testing seemed sound while others had room for improvement, once he began to question them systematically.

Continue reading Scrum as a belief system

Posted on by

The power of words

The “agile” world seems to have devolved into a cloud of buzzwords and catch phrases. People repeat them without giving much thought to what the words might actually mean. They say things like passion and commit and fail, and they threaten to hold you accountable.

When agilists say these things, they understand one another perfectly well. They have internalized the deeper meaning of these “standard” agile buzzwords and catch phrases.

But it is not plain English. It is jargon.

What does a normal person hear, when the agilists speak their magical incantations?

Continue reading The power of words

Posted on by — 2 Comments

What’s the problem with “What’s the problem with Scrum?”

I’m not a salesman for, or even much of an enthusiast for Scrum, and yet I keep finding myself in the position of defending it (or appearing to do so). A survey was posted a few weeks ago entitled “What’s the Problem with Scrum, and How can we Fix it?” (capitalization theirs). They’ve published the results, and so here I am again, appearing to defend Scrum.

What I’m actually defending is the idea that if we want to criticize a thing, that at least let’s criticize what the thing really is, and not a strawman version of it.

Continue reading What’s the problem with “What’s the problem with Scrum?”

Posted on by

(!Scrum) != Scrum

This post by Thomas Schranz caught my attention: Why SCRUM Backlogs lead to bad Product Decisions. One finds numerous articles against Scrum on Thomas’ site. I think he misunderstands Scrum fundamentally.

Is my purpose here to defend Scrum? Friends and colleagues will know that I’m not a Scrum salesperson. I see Scrum as a tool, and not as the answer to the ultimate question of life, the universe, and everything. So, why defend it? My purpose in this post is to caution against blaming one’s tools for one’s results, and to suggest that we try to understand a thing before we criticize it. (I don’t claim to be a flawless practitioner of my own advice.)
Continue reading (!Scrum) != Scrum