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.1
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.2 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.
• • •
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.
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.
"My guess is that [it] has something to do with senior managers who like getting their hands dirty." I've long harbored a fantasy of getting hired as a company's VP/Software Engineering (or Senior Director, or some C-suite title of rough equivalence) where I'd be the one member of the executive management who could -- and still did, regularly -- code. In my fantasy, I'd be talking and working routinely with front-line software developers, supporting their better instincts (e.g., true Agile, etc.), and running interference for them against "PM from the '90s"...
Sample conversation (a typical corporate project manager weenie, and me):
Me: "We're actually blessed with several senior and mid-level developers who really get the Agile approach, and we're piloting the FumDum project as our first true Agile project."
PMW: "That's great. I've heard great things about this Agile stuff. Now, where are we at with the project's requirements docs? The Gantt chart? When's the code gonna be done? ...? ...?"
<awkward silence for a few beats...>
Me: "You're fired."
As I'm actually, today, "between jobs" and available to hire, ... well, wish me luck!
Please, on the basis of this "rejected material", put me down for a beta/advanced purchase of this new book! I love the title "Simplicity", and the subtitle... It looks like you're onto something really good, Dave. Eager to see what makes it into the book! Keep us posted...