Not an Extract From My New Book

In which I think about ways individuals and teams can regain some control of their environment, and stop the current compulsion to make things complex.

A big (for me) announcement: I've almost finished a book. It's all about reclaiming software development by focusing not on process and procedures, but on people.

The book started out as a way of recapturing the values of agility, but it gradually morphed into something I feel is more powerful, at least down at the personal and team level.

The current working title is Simplicity. We’ll be putting it up in beta on pragprog.com in a couple of months.

As with all writing projects, I ended up with a bunch of material that I like but that doesn't fit into the flow of what the book became. Rather than consign it to the hidden depths of some Git repo, I thought I'd post some of it here.

The section that follows was intended to come right after a chapter where I complain about the current parlous state of software development, and outline what I think it should be instead...

---

Making It Happen

The previous chapter outlined what I hope software development will become:

• enabling

• inspirational

• transparent

• outcome-oriented

• flexibly-priced

• enjoyable and stress-free

Fine. So what's the plan, Dave? How're you going to pull off all this sweetness and light?

I'm not. All y'all are.

Current "Agile" practices all assume that the entire world has drunk the agile Koolaid: customers and managers are all playing the same game that we are, using the same rules. But they aren't and they don't. One of the reasons that "Agile" ended up in its current state is that nonAgile organizations needed a way to monitor and manage embedded "Agile" teams. This ends up making them less (or not at all) agile.

So for the idea of agility to succeed, we need to find a way to remove the all or nothing side of the practices. We need to find ways to practice agility in even the most old-fashioned of environments.

The good news is that that is exactly why we have agility. Think of the antelope. They dart back and forth, adapting to both the dynamic threat of the lion but also to the static and fixed environment they're traversing. Rocks, trees, streams; all these things are fixed, but that doesn't stop the antelope from being agile. In fact, if used properly, these static, decidedly-not-agile objects can actually be used to advantage.

The antelope manages to be agile in a fixed and unyielding environment. That gives me hope that individual developers can also chart a more agile–and simpler–path even as they work in an unyielding. traditional organization.

It Takes an Individual

Change starts with individual people. It takes energy and persistence to do things differently, and, just as in the Matrix, people are the source of that energy.¹

I've come up with practices that work at the individual level. I have three reasons for this.

First, I believe these practices improve software development. Even if only a few members of a team use just some of them, it will have a positive impact on the software the team produces.

Second, I have always believed in the motivational power of stone soup.² If you want to get your team members to adopt and adapt practices, what better way can there be than to model them in action? Individual practices are a stealth indoctrination.

Last, adapting these practices will make you happier and more fulfilled. That's my real mission.

The revolution starts with you.

Unfortunately, change can also be thwarted by an individual. We all know people who just plain don't like to do things any way other than the way they know. And because "no" always wins, these folks can be a significant drag when you are trying to adapt. That's where teams come in.

It Can Take a Team

An individual antelope is agile. Put a bunch of antelope together and introduce a threat, and that herd will look pretty damn agile, too. But there’s no plan, no process; just a group all being agile at the same time, and responding to both their environment and to each other.

In an ideal world, we'd see whole teams adapting these ideas. It might start with a couple of motivated members trying them out. Others would join in, and the practices would change to accommodate them. By the time who whole team joins in, the practices employed by the team are likely to be very different from those used by the initial two.

This raises an issue. The early adopters will (quite rightly) feel some pride in their efforts to introduce agility. But as more people join in, the practices they employed will get changed,or perhaps dropped in favor of a more team-oriented approach. The pioneers need to confidence and courage to let go: they do not own the process; they've just been thinking about it for longer.

There are individual practices that can be adopted and adapted by whole teams. But teams can also develop practices not available to individuals.

It Ideally Takes an Organization

During my research, I spoke to people who work for large companies known around the world. And, to my surprise, these companies were adopting agility across the board, from sales to support, development to deliveries.

I also talked to developers who worked for small companies whose management was still using project management techniques from the 1990s.

As far as I could tell, the leaders of most businesses like the idea of being able to react quickly and reliably to change. But the managers occupying the next layer down are less keen: they are used to managing by the numbers: annual budgets, quarterly offsites, monthly reports, weekly status meetings, and so on. This is the way they progressed up through the levels, and they are (quite reasonably) concerned that by apparently giving up control they run the risk of failing. (Of course, the reality is that all the reporting and meetings never actually corresponded to an iota of actual control.)

As I said, this problem isn't universal. I've talked with team leads in Fortune 500s who regularly interact up a significant portion of the management chain; who regularly take customers to see the latest results at some developer's desk; who deliver value when it becomes available.

How do you make this happen? If I knew, I'd own an island somewhere. My guess is that is has something to do with senior managers who like getting their hands dirty.

• • •

---

1. I never understood that premise: people must be about the least efficient source of energy you can have. Apparently the studio executives forced the script writers to use it.

2. A European folk story about a traveler who use villagers' curiosity to get them to prepare a meal and feed both the traveler and themselves.. Andy and I used this parable in The Pragmatic Programmer.