27 August 2010

Necessary Friction

Agile the Agile 2010 conference, Mark Levison commented on Twitter how he felt that the Agile community was fragile. He believes that some of the current friction between the Kanban and Scrum communities and the people for and against certifications is bad, and current scorched earth activities are hurting Agile as a whole. I certainly agree that there is friction. There are indeed egos involved, mainly because this involves people, and when you have people you have to accept the good and not so good that comes with them.

If we look back at a time 10 years ago, in the summer of 2000, there were a number of "lightweight" software development methods in use, such as (in no particular order) Extreme Programming, Scrum, Adaptive Software Development, Crystal, DSDM, Feature Driven Development. Each of those methods had people who created it and "marketed" it, for lack of a better term. Each of those methods had, even in 2000, books written about them. Those books were written by people who were experts on the topic, and were (and in many cases still are) making money by selling their books and services for their particular method.

Let's face it - to be in the position of founding a software development method, write one or more books about it and to make a living selling consulting services for that method, you need to have a pretty healthy ego. You have to be pretty convinced that your particular process is better in some way from the other processes.

So, the lightweight method community was rather fractured at the time. Fortunately, all of the "owners" of these methods that a common goal - change the status quo of dysfunction that led directly to such things as Dilbert.

It was that common goal that brought 17 of those people together at Snowbird, Utah in February 2001. The result was the Agile Manifesto whose values and principles identified what was common among all of those development methods, and set the stage for the revolution we're seeing now almost 10 years later.

Would the manifesto have been published if there were no egos involved? If everyone agreed on a single process, would it have achieved what we are seeing now? I believe that the answer to both these questions is, "No". I believe that a certain amount of discord and friction is required to be able push a group of people to achieve the best result.

After all if we lived in a frictionless world, we wouldn't be able to stop a car safely. We wouldn't be able to walk, for that matter. Frictionless worlds only exist in physics classes (along with perfect vacuums).

So, to address Mark's concerns, I believe that some friction is necessary in order to further the Agile Software Development movement. It's easy to become complacent, especially when something is reasonably successful. New processes such as Kanban help to keep us from becoming too complacent. Are there egos involved? Are there people shaking the tree? Absolutely! If there weren't, new voices likely wouldn't be heard.

If there weren't some new voices shaking the tree 10 years ago, where would we be today?

18 August 2010

A Completely Unncessary Miracle

From USA Today:
A Boeing 737 operated by Colombian carrier Aires split apart in a crash-landing on a Caribbean island just after midnight this morning. And, in what local officials are calling a "miracle," only one person died in the accident.
A miracle indeed. One that was completely unnecessary. The pilots attempted to land the aircraft during a thunderstorm, likely encountering severe wind shear or a microburst just prior to landing. These phenonena are quite common in thunderstorms and have caused a number of accidents in the past. As a result, aircraft very rarely land while there is an active storm at an airport. There is no indication from the news reports that the pilots had to land immediately due to fuel concerns or any other reason, so the logical conclusion is that they had an affliction known as "get-there-itis". In other words, the pilots' desire to get the flight in on time made them cut corners with respect to safety.

Sound familiar?

How often do teams and organizations start to cut corners - come down with "get-there-itis" - when approaching the end of the mandated time for delivering a system? Who has seen that happen before? Let's see some hands. Yes, almost everyone has.

As the pilot-in-command of an aircraft it's your responsibility and no one else's to ensure that a flight is safe. In the case above, the pilot and first officer should be held accountable for continuing the flight into dangerous circumstances.

As a team member it's your responsibility to call out situations that are the equivalent of flying your project into a storm while landing. Thunderstorms are visible for many miles, and are almost completely avoidable, and so are most of the dysfunctions on software projects. Agile processes quite often make those problems visible long before they cause damage, but they're visible even when using traditional processes.

Let's stop relying on completely unnecessary miracles, and use common sense and good risk management to bring projects to successful completion.

16 August 2010

Agile 2010 - Lack of Technical Sessions

There has been some discussion and even minor ranting about the lack of technical content at Agile 2010 in Orlando:

Uncle Bob Martin:
Programmers started the agile movement to get closer to customers not project mangers.
And again:
< 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?

I had similar conversations with Mike Hill and Joshua Kerievsky. I suppose even my session, Confessions of a Flow Junkie, could be considered non-technical since I only touched on Automated Testing as something that promoted Flow and didn't delve into the details.

So, what's different? Why does this seem to be the case? I agree completely that we could certainly use a renewed focus on technical skills, and am quite interested in the announcement about XP Universe 2011 by Corey Haines. I can also say that I attended 4 technical sessions at the conference - one by Rebecca Wirfs-Brock, one by Arlo Belshee, one by Llewellyn Falco and Jason Kerney and one by Josh Kerievsky. Those were the least well-attended of all the sessions I went to, excepting one that was listed as 'Expert'. I remember thinking more than once,
"Wow - the people who need to be here, um, aren't."
My experience as a coach is that people are learning and using the management practices of Scrum reasonably well, but they're only scratching the surface of what they can do with the technical practices. I see plenty of development teams starting to use an automated build (and incorrectly calling it Continuous Integration), and that's a good thing. However, precious few are writing Microtests, Refactoring, using Simple Design, and truly using Continuous Integration.

In one of the closing keynotes by Ron Jeffries and Chet Hendrickson, highlighted this very point:
Scrum is so simple that if you actually did it, it has to work!
Exactly. The technical practices that became part of XP aren't as simple. They take time to learn and integrate, and thus they aren't as popular. Once you have integrated them, though, they are indeed easy.

I've been told many times now by both developers and managers that microtests take too long to write, but no one has told me how long it takes them to debug a problem. I have sat with developers looking over unnecessarily complex Java/C/C++/C# code, and was told that it wasn't their fault that the code was such a mess, and that they didn't have time to clean it up. I've literally been laughed at and told that a goal of 0 defects is a pipe-dream (with that exact term used).

I call bullshit.

We know how to write code that is for all intents and purposes defect free. We know how to adjust the structure of code over time to reduce technical debt and keep it flexible and understandable. We know how to do these things, but because they are more difficult to learn than a daily standup meeting, we don't do them.

I believe that's why the 4 technical sessions I attended didn't have the same size audience as the session on Scrum Metrics that, in my opinion, was bordering on the sale of snake oil. I believe that's why only 10% of the sessions in the conference were oriented towards the technical practices - the popular topics aren't in the technical realm. Does that mean there wasn't value in the other 90%? Hell no - my head is still spinning after Jeff Patton's excellent session, "Beyond Sprint 0: Using Collaborative Product Discovery to Plan Agile Projects".

The revival of XP Universe, the ascent of the Software Craftsmanship movement and the creation of groups such as the Agile Skills Network are all indications that we're once again acknowledging the elephant in the room that is the industry's horrendously poor track record with respect to low-level technical quality.

Considering civilization's current and growing dependence on software, that revival is occurring not a moment too soon.

15 August 2010

Agile 2010 Review

I'm still in Florida as I write this, enjoying a weekend with friends near Tampa to help wind down after the conference. I must say that the humidity on the Gulf coast is much lower than in Orlando!

For me personally, the conference was one of the first opportunities to meet a number of people I've "known" online for many years - Ron Jeffries, Chet Hendrickson, Diana Larsen, Dave Nicolette... and those were just the people I sat with at Bloody Stupid Johnson! :) Bob Martin, Esther Derby, Lisa Crispin, Janet Gregory, Jon Bach, Jeff Patton, Johanna Rothman, Mary Poppendieck, Alan Shalloway, Cory Foy, chzy, Mike Hill, Kay Johansen, Corey Haines, James Shore, Arlo Belshee... as well as new faces like fellow aviation freak Bob Schatz. Of course, it was also great getting back in touch with those I have met before!

Regardless of whether I had met someone in person or virtually before, it was fantastic and quite energizing to be around so many others who share my passion for making software better.

I attended sessions on every day of the conference, and there was only one that I would say didn't live up to my expectations, and another that had the makings of a great session but didn't draw the type of people who could have made it great.

I didn't partake in much of the extracurricular activities, but that's probably how I was able to attend sessions on every day. :) That said, one of the best chats I had all conference was with Bill Hanlon of Microsoft while waiting in line for Soarin' at Epcot after the party!

Another thing I noticed at the conference was the high Canadian Content (known as CanCon in Canuck broadcasting parlance). Everything from the company running the event to the band playing the party at Epcot at the end was Canadian! [Later found out from Gil Broza that the band were Canadian wannabe poseurs - closest to being a Canuck was the Irish bass player :( ] How do you spot the Canadian in the crowd? He's the one wearing the Dale Hawerchuk Winnipeg Jets t-shirt... or the Tragically Hip t-shirt... or the Barenaked Ladies t-shirt (was she Canadian?)... or offering up maple syrup for auction to raise money for charity. Maybe The Canadian Conspiracy and Canadian Bacon were warnings after all... :)

To me the common theme that emerged from both sessions and keynotes, especially that of Ron Jeffries and Chet Hendrickson, is that we need to stop making excuses for why software is still made with terrible quality, and get to changing how we work.

I was also encouraged by Mary Poppendieck and Dave West's talks where they mentioned that the software delivery people must become part of the business units they support in order to become more effective. I wrote about this before in Embedded Collaboration and Agile, circa 1988. What was different is that Mary spoke about Handelsbanken in Sweden, where they realized that it was much more customer-effective for each branch to have its own IT group as opposed to the cost-effective approach of centralizing IT services. Essentially, being cost-effective may work against the Lean principle of optimizing the system, and centralization of services becomes a local optimization! Long-term strategies of maximizing value for customers was more important than short-term (i.e. quarterly) maximization of shareholder value. Handelsbanken did this starting in 1970, and Amazon & Google continue it today. I've had an intuitive feeling that this was true, but nothing concrete on which to base that feeling. These points comprised the gold nugget from Mary's talk that will be immensely helpful for me moving forwards from the conference.

I was a first time presenter at this conference, and was somewhat nervous. I think it helped a bit that I didn't present until Thursday since I had a chance to see how others were doing it. In the end, I had a couple of attendees of Confessions of a Flow Junkie tell me that they had learned things that they could use as soon as they returned home. That was worth more than anything on an evaluation sheet!! So, I'm quite happy with the outcome of the session, and received some excellent feedback that I'll incorporate to make the session even better if I use it again.

So, many thanks to the conference organizers and volunteers and to everyone I met. I had a blast, and am already looking forward to Salt Lake City next year!