Posted on 2 Comments

Komm süße Todesmarsch

People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.

Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”

But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.
Continue reading Komm süße Todesmarsch

Posted on

What skills does a technical coach need to have?

What skills does a technical coach need?

One of the goals of my present coaching engagement is sustainability, defined as the ability to continue with the improvements after the coaches are gone. To that end, we’ve been identifying internal people who have the potential to become effective technical coaches. One manager asked us for a short list of key skills that a technical coach ought to have. Answering that question has been quite a challenge. It occurs to me that other people may be asking the same question, so it might be useful to discuss it publicly.
Continue reading What skills does a technical coach need to have?

Posted on

(!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

Posted on

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 9 Comments

Is a spike a type of story?

Many teams that take an “agile” approach to software development define requirements in the form of “user stories.” Not all the work a team performs lends itself to this form. It seems that people have come up with definitions of various “types” of stories other than “user” stories so that they can deal with work items that do not represent vertical slices of functionality that can be demonstrated to a business stakeholder. That’s fine as long as it’s practical and helps teams deliver effectively.

One of these non-story stories is the so-called “spike story.” I keep running into this in my team coaching work, so I did a quick Google search and found the term “spike story” is used pretty consistently. Definitions published by the ScrumAlliance, Agile Learning Labs, Scaled Agile Framework (SAFe), SolutionsIQ and others all refer to spikes as a type of “story.”

Answers to a question about spikes on Stack Overflow are more encouraging, as they mention spikes are time-limited and at least two of the respondents refrain from calling them “stories.” Even so, the notion that a spike is a kind of story seems to have become a widespread infection.

Continue reading Is a spike a type of story?

Posted on 1 Comment

A modest proposal for restructuring enterprise IT

Submitted for your consideration: The simplest way to solve a problem is not to solve it at all, but to define it out of existence. Many of the challenges we face in corporate IT may be caused by traditional organizational structure. If it is true that structure begets function, then we may be able to define some of these challenges out of existence by changing the organizational structure.

Continue reading A modest proposal for restructuring enterprise IT

Posted on

Using Mob Programming to jump-start development teams

With 7 technical coaches working with some 160 development teams, we find ourselves moving from team to team with little time for in-depth collaboration. I decided to try a different approach to introduce an effective work flow, encourage collaboration within and across roles, and provide direct experience with recommended technical practices in a short time. We have been running two-day intensive working sessions with one team at a time. We have done this with four teams so far. The experiences have been different, but the general results have been positive in all four cases.

Continue reading Using Mob Programming to jump-start development teams