16 June 2009

A New Generation, A New Perspective

At the beginning of May I attended the Cutter IT Summit in Cambridge, MA. I quite enjoyed it, since it was not just about Agile but many other aspects of the IT industry. The summit gave me the opportunity to soak in knowledge from many thought leaders from various sectors of IT.

A common theme that I encountered is that we are in the midst of a sea change in IT. The current economic circumstances are certainly a driver of this, with organizations abandoning old business relationships to save incredible amounts of money moving their operational IT work to the cloud, and its natural extension of Software as a Service (SaaS). Indeed, I'm an advisor for (and did a pile of development work with) local social media startup Favequest that is entirely run in that manner.

The other change vector we are seeing is a new generation of people both entering into the IT industry and consuming its services. I'm talking about those kids (which is now anyone more than 5 years younger than me!) who can send text messages from their smartphone while it's still in their pocket. To them, technology is a given - it's always on, always available, and these "kids" have very little brand loyalty. If your product or service no longer appeals to them you're done! Many of the traditional rules of business have been turned upside down.

This reminded me of a presentation I gave at the CUSEC conference in 2005 on Extreme Programming. After giving my talk, I fielded the usual questions. One question, though, absolutely stunned me. A student asserted more than asked that "XP seemed like a very heavyweight process". I hadn't realized that my perspective, and that of those who have been in the IT industry for any more than a few years, had skewed my view of what constituted a lightweight process. In the absence of any other perspective, XP looked very prescriptive and heavyweight to this student. Indeed, most if not all of the development processes that form Agile were reactions to what were perceived by my generation as heavyweight and prescriptive.

The lesson in this, I believe, is that our perception of something is precisely that - our own! We may share that perspective with others who have similar experiences, but we must be judicious in the use of that assumption.

So what, then, will the software development world look like when the Agile methods are indeed heavyweight and prescriptive? I think the App Store is a hint of what's to come. There was also a session accepted for Agile 2009 entitled, Agile's Too Slow: Developing a Facebook App for the Obama Campaign. Finally, at a recent Agile Ottawa gathering, Luc Levesque of TravelPod described the development process his company uses, which includes a deployment to production as soon as a developer commits to source control.

These micro-processes are all predicated on gathering usage statistics and user feedback in near real-time and executing immediately on the results. The business environment can literally change hour to hour, so everything in the process must be geared towards handling that flux. As a business, you simply can't afford to complain that things change - you have to adapt or you'll go out of business.

Essentially, in the always on, always available world even Agile circa 2009 isn't sufficently lightweight. I'm sure there will be those that say micro-processes don't apply to them.
What about life-critical software such as that in medical devices and avionics? What about control systems for nuclear power stations? There's no way we could use a micro-process for embedded software development!
Funny, I heard the same questions almost 10 years ago about XP and other Agile processes.

The sea change discussed at the Cutter IT Summit is happening whether we want it to or not. We need, therefore, to decide if we want to ride the wave, get washed away, or just get the hell out of the water altogether. For the latter two cases, there are plenty of young people ready to cast off the burden of our overly prescriptive Agile processes and get down to really delivering some value!

14 June 2009

Rounding the Corners

I was cutting the grass this afternoon and remembered back to when I was a kid. My parents had a relatively large lot, and it used to take me a good two hours to cut the lawn. The problem was, I hated cutting the lawn. Even when I was a teenager, I couldn't understand why we want to "maintain" our lawns, making them look as artificial as possible without resorting to Astroturf.

I would do whatever was possible to get out of cutting the lawn. I still do, for that matter! Raining in Sudbury? Well, it could make it to Ottawa at any time... that would be unsafe! Inevitably, though, I had to cut it.

Even then, I wasn't going to go out of my way to extend my agony any more than was necessary. The back lawn in particular was quite large, and by itself it took a full hour to cut. I guess I have the process improvement gene turned on, because I spent a good amount of that one hour trying to figure out how to make it something less than, well, one hour. Eventually I figured out what slowed me down - square corners. Each 90 degree turn meant stopping, turning the mower and starting again. If I could remove as many of those corners as possible, I would reduce the amount of time it took to cut that lawn.

This particular yard wasn't perfectly rectangular, and had several trees. I determined that there were a few places along the edge I could cut first to remove some of the variance in the shape of the yard, and that I would have to do at least one full pass to cleanly cut the outside perimeter (OK, so I did care a bit about the quality as well!). After that, I kept to cutting in one continuous strip that was curved around the corners rather than square. This didn't bother my Dad at all, so I then set about optimizing the new process.

It took a couple of tries, but I eventually reduced the cutting time from a full hour to 45 minutes. Being a rather impatient teenager at the time, having an extra 15 minutes to do what I wanted was much better than nothing!!

This relates to practices in Agile that allow a team to move faster, or at the very least sustain their current velocity. Automating anything that is repetetive, tedious and chews up time goes a long way towards reducing and even eliminating those 90 degree turns. Testing, builds, deployments, etc. are all practices that can be automated and have a tremendous amount of tool support now. These "rounded corners" will keep the team moving ahead at a steady pace.

Oh yeah, after I moved out of my parents' house, my Dad bought a riding mower. Cutting the grass is now considered fun, I'm told. I have never had the opportunity to use the riding mower myself. I'm sure there's another lesson there somewhere! :)

11 June 2009

Revert to Training

I was having a "conversation" on Twitter this morning with Esther Derby and Scott Duncan about how good engineering practices are required in addition to Scrum's project management practices.

This isn't anything new - I've blogged about it before.

We discussed how it often seems that it's easier to introduce the management practices of Scrum than the engineering practices of XP. Esther asked me why I thought this was the case, and a thought struck me - it's how the developers were trained.

(Warning - here comes yet another aviation analogy!)

During my flight training, my first instructor made a point of saying early and often that it was very important to listen closely, do what she said the way she said to do it, and to practice that way afterwards. She emphasized the importance of this, saying that "when faced with an emergency, you'll revert to your original training". That was in 2005, and even now I hear her voice in my head when I'm flying and practicing things such as forced landings.

How does this apply to software development? Well, consider the poor overworked software developer. They've had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster and have those annoying business people around all the time to pester them. On top of it, the damned "Agile Coach" is harassing all the developers to write more code that tests the code they've already written. Near the end of the sprint, this poor developer is running out of time and still has work to complete - they are facing an emergency! So what do they do? They revert to their original training.

What was that training? If they went to university or college, likely long hours working alone or in very small groups trying to get assignments done. They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? How's that going to impress the prof? In the end, the attitude is to get something - anything - done in order to get the marks.

It's this training environment that leads to the problems when the developers are "faced with an emergency" later in their careers.