Tag: process improvement

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

Slack, Flow, and Continuous Improvement

One of the key ways to keep work moving forward is to avoid working on too many things at the same time. Ideally, a person should finish what they’re working on before starting anything else. Similarly, a team should complete the work item or ticket or story (or whatever they call it) they’re working on before picking up the next one. At a larger scale, a software delivery organization should limit the number of projects in flight concurrently, and strive to “stop starting and start finishing,” as David Anderson put it. That’s what portfolio management is for (among other things).

Continue reading Slack, Flow, and Continuous Improvement

Posted on by

Choosing an Agile Scaling Framework

Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.

I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.

Posted on by

Julio Cortázar and software development methods

Nadie habrá dejado de observar que con frecuencia marcos del proceso se aplican mecánicamente.

Maybe Julio Cortázar, whose 100th birthday we celebrate this year, would have begun a set of instructions for implementing a process framework with similar words. No one will have failed to observe that many individuals, teams, and organizations are quite befuddled by the process framework they are trying to use. They struggle mightily to follow every “rule” the framework “requires,” even when their goals are ill served by those rules.

Indeed, it is typical for such individuals, teams, and organizations to lose sight of their original goals altogether in their attempts to satisfy the real or perceived “rules” of the process framework. No matter how haphazard their previous mode of work may have been, many conclude that the framework “doesn’t work,” and revert to their former methods.

Continue reading Julio Cortázar and software development methods

Posted on by — 4 Comments

Where are all the Agile success stories?

Daniel Mezick confronts the elephant in the “agile” room in his post, Deviation from the Norm: “If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility. Clearly, that is not the case.”

Pondering the question, several possible reasons for this result (or lack of) occurred to me. These are speculative and based on my own experience and observations.

Continue reading Where are all the Agile success stories?

Posted on by — 6 Comments

How does collaboration begin?

The question was posed in a discussion on LinkedIn. It received the following response:

Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.

Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.

Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin. Continue reading How does collaboration begin?

Posted on by — 1 Comment

Don’t do anything stupid on purpose

It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.

Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose

Posted on by

The Shimmering

In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.

Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering

Posted on by

Short-term planning: A continuum of effective practice

There’s been an ongoing discussion in IT circles about estimation. The discussion dates back as far as I can remember in my career. As far as I know, it began much earlier than that; possibly around the time people began to apply software to serious matters, which would have been a few minutes after the first digital computer was powered up.

People have focused on estimation for such a long time that I sometimes wonder if they have lost sight of the purpose of software. The practical value of software is not realized through an estimate. An estimate is not a product. Customers don’t buy estimates. Even when a client pays a consultant to provide an estimate for a project, the estimate itself is not the thing that ultimately interests the client. It is only a step toward making a decision about whether and how to go about a proposed initiative. An estimate is a means to an end, not an end in itself. Continue reading Short-term planning: A continuum of effective practice