Last week Assembla posted a bunch of “agile” words on our home page. I resisted doing this for years, because the word “agile” doesn’t necessarily have a good feel to it. It’s a refuge for a lot of organizations and people that aren’t very agile. The original idea is great. It stands for releasing software frequently, with short lags for the implementation of valuable new features and ideas. The productivity of software development increases every year, and in theory you could use the word "agile" to describe many of the things that are light and bright, great and good, fast and fun about our new world. But, if we want to use the word “agile” for this, we have to burn off the stink of stagnation that surrounds the old “agile.” So, here are seven things I hate about “agile.”
Old people: Agile has the smell of death on it. If you go to an “agile” event you will see few people under the age of 40 and many over 50. These attendees are on average much older than the average age of programmers, and often older than the people running today’s hot software companies. Why aren’t more younger people grasping at agile straws?
Stagnation: "My development guys don't think 'agile' is interesting," reported the president of a major software tools vendor, sitting among cubes covered with agile task cards. The modern agile movement is chained to an aging orthodoxy based around Scrum. What's new in Scrum this decade? Most organizations which use the word "agile" are using the word precisely because they are NOT agile, and want to be more agile. This has created a demand for a whole industry of people who try to push "agile" further into non-agile organizations amplifying the link between "agile" and really not agile. Making matters worse, they are seen as management stooges attempting "process change," which is a boondoggle that nobody wants applied to his real-world job. Most victims would rather go to the dentist.
Imposing values: Read the agile manifesto here and think about whether this is a good tool to get a diverse group of people to work together. We value this. We value that. I don’t think values have anything to do with productivity or collaboration. The Americans and the Russians didn’t share many values, but they teamed up into a mighty fighting force during WWII because they shared a goal. The people that make an iPhone make a beautiful product efficiently. They live in the US, Japan, China, and many other countries. They live in mansions, boats, and dormitories. Do they share values? I doubt it. They don’t have to. They share a supply chain. Productivity is comes from shared GOALS, not shared values, and from a process that is structured to allow people to do their separate jobs, and work together. As long as they share a goal and have room to work, they can ignore each other’s values. Team productivity research shows that a shared end goal is the best predictor of high performance teams. If you are going to insist on shared values, you are going to have a very short supply chain – probably just 5 or 10 people sitting around a campfire singing Kumbaya. That sounds like a Scrum team! I’m going global. Get the hell out of my values. And while you are at it, let me cram what I value down your throat - code that we can release.
Scrum Master roles: Some scrum coaches rank among the nicest and most thoughtful people that I ever met. However, the general concept is very suspicious. A scrum master is not supposed to lead the team, code, or take responsibility for deliverables. What do they do? Massage? Get a real job. We use tech leads, who can understand the code that flies around a distributed team, and take responsibility for deliverables. I shed more light on this back in Novemeber with a popular post - Tech Leads will Rule the World.
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary:
Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views:
- Estimates of software tasks are inherently unreliable.
- The benefits of estimates are outweighed by the time required to make them.
- Most developers won’t take the time to enter actual hours.
- Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating.
- Measuring people based on estimates causes them to game the system.
Pair programming: Great for vendors, bad for customers. Pair programming is like those girls that go to the restaurant bathroom together. What are they doing? If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects. If you are customer, you pay twice as much and you get churn. I recommend a more efficient alternative – review pairs. Person A and person B use a code review system to review each other’s code before release. You get the same benefit without the neck cramp and the BS.
Scrum reality warp: Let’s look at a few of the fantastical things that scrum advocates believe should be true about a Scrum team.
- According to the Scrum manuals, development teams should be co-located (everyone in the same place for daily discussion). Where are the foosball tables that these guys are crowding around for their daily standup? I haven’t seen a fully co-located team in years. Even if they are co-located in theory, there is always someone who stayed home or moved to Vermont.
- Self-contained, cross functional teams. In this world, you have a full-time person on your team for every function – design, database, etc. I love the idea that a team can deliver a complete feature end to end. However, reserving talent for one team isn’t a practical way to do it.
- Teams with the same capacity every week. People don’t move to new projects, get hired and trained, or even move over to help other teams that are further behind. Apparently that would be idiotic, because you would get work done, but you would screw up your precious velocity calculation.
- No bugs. You plan your next iteration, and then you don’t get any extra work because your last release has no bugs.
I was at an event where Alex Brown, COO of Scrum, Inc. was talking about his work, and when someone said “that doesn’t sound like Scrum,” he said “We’re a Scrum company, so we call everything Scrum.” We can all recognize reality and lighten up.We're going to be calling our stuff "Scalable Agile". If you are interested in new solutions to some of the issues listed above, please follow this blog over the next few weeks.