As an American, I know that we have trouble driving in certain situations. This is especially true when encountering a “roundabout.” A roundabout is elegant in its design and brilliant in its simplicity. It’s a circular junction where multiple roads converge. It is simple in that you only need to yield to the traffic to your left (or right in the UK) and you can connect to any of the adjoining roadways. It keeps traffic flowing, reduces stops, and even saves on fuel. Unfortunately, it is almost totally alien to Americans and for that brief moment when one is encountered, completely baffling. I once sat on a patio at a Gloria’s restaurant that overlooked a roundabout in the middle of an outdoor mall in Garland, Texas for almost 2 hours watching the traffic. It was possibly the most hilarious study of traffic patterns ever devised (of course the sangria didn’t hurt). I watched cars stop before entering, which backed-up traffic for blocks. Time and time again, I saw cars that refused to yield, almost causing a pileup. I even caught a few cars that went the wrong way in the roundabout! If you can think of a wrong way to use a roundabout, I’m sure there was a car using it on that day.Why does all of this roundabout stuff matter? Well, because many times business leaders and IT managers have grand visions for how they will run their software product teams. They have great maps about how much ground they will cover and how fast they will get their product / enhancement / customization to market. Unfortunately, these lengthy, tightly-designed road maps often overlook the simplest details, and the development teams fail to reach their destination because they get stuck in a roundabout somewhere along the way. They spin round-and-round on the path instead of focusing on the destination. It is important that everyone who is involved in the creation of software in these teams understand the processes and expectations (i.e. rules of the road) before a development team can truly be successful. Unfortunately, the rules of the road change in every country, and the best software development practices tend to be slightly different at each company, and within each development team.
In recent years, "agile" has become the software craze. "Go agile and everything will be better" is what development teams and software managers sell to their executives as a way to get better results in a faster timeline. To many under-experienced business folks, “agile” means “go faster”, which in turn means “more profit.” It is easy to take aim at the neophyte, “non-programmer” types in business as some type of necessary overhead, obviously unaware of the needs of the development community. But it turns out that these folks who do not contribute a line to the codebase actually care about something meaningful; winning against the competition which wants nothing more than to put you (and your company) out of business. For the business leaders, it is important to understand what agile is, and is not, so that its benefits can be realized in an organization focused on software and profit.
To some in the software development world, “agile” means “no processes.” I have interviewed hundreds of prospective employees who’s resumes assure me of their “expertise in agile.” But many of these candidates seem to think that agile means that they write no documentation and meet every day for 15 minutes. Although it is certainly possible to be a successful software company only following these two rules, I have always felt that it was important to understand why I was doing what I was doing – not to just do it.
For many software professionals who have read deeply on agile and followed its steady rise over the past decade, the agile philosophy just seems to Make Sense. Trust people over processes. Working software is the best form of documentation. Stay close to your customers and adapt. Unfortunately, many of the truisms of these agile approaches are completely lost on the decision-makers within an organization. Many times, some of the details are even lost on the teams! A battle-cry of "go agile" that yields an initial failure can have catastrophic consequences to a development team, or even an entire IT organization. In this blog, I hope to explore some of those truisms in an irreverent and whimsical way, and try to get to the underlying reality that is the processes and management of software development teams.
