Posted on

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

What if people always spoke the way they do at work?

I’ve noticed in many business meetings, and especially presentations, people use highly stilted, quasi-academic language. They may have useful things to say, and a pleasant, cultured voice to say them with, but the language leads me to wonder why people think they have to sound academic at work, and whether they would speak that way normally in any other context.

I mean, if they think it makes them sound smart at work, wouldn’t they want to sound smart all the time? Who wouldn’t, right?

Continue reading What if people always spoke the way they do at work?

Posted on

How we think about recruiting

There’s an odd situation in the software industry. Employers are adamant that they can’t find suitable talent to fill the technical jobs they have. Job candidates are adamant that they can’t find suitable work. It seems strange to me that both these things are true at the same time.

Many people have opinions and observations about this. Often, they cite academic studies, industry surveys, formal management models, psychology, and various other things that are confusing for a Bear of Very Little Brain like me. I wonder if we could go a long way toward solving this problem if we ajusted, just slightly, the way we think about what we’re aiming to accomplish, on the hiring side and on the job search side.

Continue reading How we think about recruiting

Posted on

An incentive to collaborate

Recently, I tweeted that I had presented a virtual training class in which we used remote mob programming for the lab exercises, and at the end the participants said their main take-away was not the technical content, but rather the value of direct collaboration. Colleagues who already understand and appreciate the power of collaboration were excited to hear the story.

But what about people who do not already understand and appreciate the power of collaboration? What was unique about the situation that brought collaboration to the fore, above and beyond the technical skills that were ostensibly the subject of the class? How closely does that situation align with more-typical software development realities?

Continue reading An incentive to collaborate

Posted on

Discipline

Premise 1: Self-discipline is the only meaningful form of discipline.

Premise 2: Simpler solutions are usually preferable to more-complicated solutions to the same problem.

Premise 3: Without self-discipline on the part of those using it, no process model or method or framework or tool of any kind provides the value its proponents believe it can provide.

Premise 4: A formal process that imposes strict rules tends to teach people to follow rules rather than to cultivate self-discipline.

Premise 5: The longer and more deeply a person invests in a given idea or habit, the more difficult it becomes for that person to let go of the idea or habit, or even to question it.

Premise 6: In the diffusion of any innovation, the main reason Innovators and Early Adopters achieve better results than Late Adopters and Laggards is the former are predisposed to try unfamiliar things and take risks, and not primarily because the particular innovation is intrinsically better than whatever it replaces (even if it happens to be a little better on the merits).

Premise 7: The factor that makes an innovation useful is that it comes at a time when it is needed, in a context where it is needed, and to people who are in a position to make use of it; not necessarily that the innovation itself is “best” in a general or permanent sense.

Continue reading Discipline

Posted on

En casa del herrero, cuchillo de madera

I was reminded of that old saying when I was struggling to use one of the internal software tools we’re required to use at my current client. In this case, it was one of several time-tracking systems.

It led me to think about the difference in quality between the software the client creates to support customers, and the software they create for internal use. It seems to be a consistent pattern at many companies. They pay a great deal of attention to quality for customer-facing information systems, but when it comes to systems for internal use, they just throw something together quickly, and often carelessly.

The old saying, “In the blacksmith’s house, a wooden knife,” applies to our line of work. The question then becomes, Why?

Continue reading En casa del herrero, cuchillo de madera

Posted on

The best agile environments I’ve seen

Looking back over who-knows-how-many “agile transformation” and “agile coaching” engagements, it occurs to me that five experiences stand out as especially positive.

When I ask myself why, two elements present themselves: First, (in three cases) the development team was physically collocated with the end users and collaborated directly with them daily; and second, (in the other two cases) the team and the organization did not “lock in” any rigid definition of “agile,” and actively explored ways to move beyond the usual Agile 101 level of practice.

Continue reading The best agile environments I’ve seen

Posted on

What’s a time-box?

What’s a time-box?

When working with people who are new to “agile” development methods, particularly Scrum, I notice there seems to be a great deal of confusion about the concept of a time-box.

Time-boxes are baked into Scrum at multiple levels. The Sprint is a time-box, and all the standard Scrum events are time-boxed. Yet, many people who adopt Scrum pay little attention to this aspect of the process. They begin their events late and they extend the time of an event if they haven’t yet met the objectives.

I don’t speak for the inventors of Scrum, but my understanding of the time-box mechanism is that it has two key functions for a team and organization. When people don’t use time-boxes in a way that enables those functions, it suggests they don’t quite understand what the time-box is for.

Continue reading What’s a time-box?

Posted on

Product-Aligned Software Teams

Product-Aligned Software Teams

For a long time now, and starting in earnest in the early 1990s, people involved with software development and delivery have been shifting various aspects of the work to the “left,” if you visualize a software delivery pipeline that runs from left to right. What’s the endgame?

Continue reading Product-Aligned Software Teams