13 October 2011

Agile is a Cop-Out?

In a blog entry entitled "Agile Software Is A Cop-Out, Here’s What’s Next", Forrester's Mike Gualtieri makes some bold statements about what he sees as hype and a lack of empirical evidence of success from the Agile community.

Now, Mike's post is bound to raise the hackles of many people in the Agile community, but I do agree he has some good points.

He doesn't specifically use the term "hype", but certainly the promise of hyperproductivity coming from Agile thought leaders like Jeff Sutherland doesn't help.  I have witnessed trainers routinely telling their students to expect incredible gains in productivity once they drink the Scrum kool-aid.  It's a great sales pitch - others are doing this and if you aren't achieving those sorts of increases then you must need more training or coaching!  The amount of Bad Agile or Bad Scrum that has resulted is a testament to both the hype that has pulled people into trying Agile and the difficulty in actually doing it well.

I will defend the authors of the Agile Manifesto, though, in that they were making a statement about the world of software development as it was in the late 90's and into early 2001.  Mike cites Steve Jobs using "insanely great" to describe products, but in February 2001 the world still hadn't seen it's first iPod.  OSX was a month away from going GA.  The aluminum-cased MacBook Pro and MacBook Air were 5 and 7 years away respectively.  The iPhone was a pipe-dream.  Tablets had come and gone several times at that point, long before the iPad was developed.  So, most of that insanely great design was still well ahead of us when the Manifesto was written.

Also, as an industry we sucked at building software, and the dot-com boom hadn't helped much to fix that.  You had either code and fix or some hard-ass waterfall process to follow, and precious little in between.  It's no wonder that the Manifesto's authors focused on that problem.  "Working Software" wasn't narcissistic, as Mike states, it was something that was sorely lacking in early 2001 (and arguably still is today).

Mike mentions that he first wrote about his approach, Parallel Immersive Software Studio (he acknowledges the acronym that creates!), in 2008 and has refined the ideas since then.  Well, the software development world is a little different today than it was in 2001.  The success of the products from Apple are mainly due to the total user experience, which is something that has grown and been refined over the ensuing decade.

I see a lot of good ideas in Mike's approach.  I certainly agree fully with the ISS parts of his approach, but I do have issues with Parallel.  Any time that groups go off in isolation to work in parallel, you incur multiple risks:
  • One or more groups go in the wrong direction;
  • You have to integrate the work at some point, and the longer you wait the more difficult the integration will be;
  • Based on Mike's description of parallel work, you are isolating experts in different areas thereby decreasing your Truck Number
Another point Mike makes is, "Parallel work streams can reduce uncertainty and the number of costly iterations."  Could I please see some empirical data to support that?  If he's going to criticize the Agile community for not providing empirical data, then I believe it behooves him to do the same.

Mike concludes the post with 5 key points about his process:
  1. Software is not code. It creates experience.
  2. Development teams are not coders. They are experience creators.
  3. Technical talent is “table stakes”. Great developers must be design and domain experts.
  4. Process is bankrupt without design. You get what you design so you better get the design right.
  5. Software is a creative endeavor, not an industrial process like building automobiles. The methodology is structured to support the creative talent.
I agree with all of these, although #4 concerns me.  What is Mike's definition of design?  What does it mean for a design to be 'right'?  How do you know when a design is right?  Is design ever done?  How much design is enough?

This segue's nicely into my growing interest in the Lean Startup community.  Lean Startup assumes you're going to use good engineering practices (many from the XP world) to build the software because they enable you to obtain the kind of rapid feedback required to refine a total product design into something for which people will actually pay money.  What I don't see in Mike's post is anything about that sort of validation - his process may ensure that you build some kick-ass, well-designed systems, but if you don't sell the product because you didn't realize that no one wanted it, have you really succeeded?

Mike has some very good ideas in his post.  I also saw some good ideas in a similar "post-agile" blog entry by Michael Dubakov.  While I don't agree with all of the points the respective authors make, I do think this sort of "what's next" thinking is healthy and will help make the second decade after the creation of the Agile Manifesto even better.

After all, reflection and continuous improvement are core concepts in Agile and the ideas put forth by Mike, Michael and Eric Ries of Lean Startup provide exactly that.

10 October 2011

Great New Scrum Extensions!

This past week, Jeff Sutherland and Ken Schwaber annouced via Scrum.org that Scrum is now open for modification and extension.  This is good, and an issue that has been simmering in the Scrum community for some time now.

Fortunately, there have been some forward-thinking folks who got a jump on the rest of us, and had their extensions ready to go at the time of the announcement:

This extension, known by the rather provocative name Extreme Programming, was created by Kent Beck and is apparently targeted towards smaller teams and organizations.  It adds to Scrum by providing several engineering practices that many have indicated were missing.

If you are targeting a larger group or organization, then this extension known as Industrial XP may be a better fit:

This process was created by Joshua Kerievsky and adds business facing practices to Extreme Programming (and hence to Scrum) such as Project Chartering and Test-Driven Management.

My congratulations to these gentlemen for possessing the foresight to have extensions to Scrum ready the minute the announcement was made.


5 October 2011

Goodbye Steve Jobs

It was about this time of year in 1981 that I dropped into my high school's Computer Science and Data Processing classroom to talk to a buddy of mine.  At the time I thought I was on a track that would lead me through high school to an aeronautical engineering or commercial pilot program somewhere, and I would become a professional aviator.  That would have surprised exactly no one, since I had been engrossed in aviation since... well, as long as I can remember.

I asked my friend what he was doing, and he showed me some little BASIC program he was writing that did some silly thing with the low-res graphics on the Apple ][ computer he was working on.  Hmmm... that's kinda cool, I thought.

It wasn't long after that I saw another buddy who had taken the same Data Processing class writing some more code.  I asked what he was doing, and this time he explained the program to me.  I don't remember what it was, but I remember how I could understand what the code meant... although he did have to explain why some of his variables had a "$" at the end.

Coincidentally, the Grade 11 Physics class I was taking was studying rectilinear motion, and we had learned several equations.  While I didn't have any problem doing the equations by hand, I wondered if I would be able to use this computer thing to do the calculations for me.  So, I asked one of my friends what material they had on BASIC, and was shown a shelf containing a raft of Apple manuals.  I politely asked the teacher if I would be able to use one of the 4 computers to write some programs during lunch and after school, and he happily agreed.

After some initial fumbling and stumbling and asking a lot of questions of the guys who seemed to know what they were doing, I figured out the mechanics of writing and executing a program.  I was then able to run calculations for one of the equations, cross-checking the result with my hand-calculated version (an early acceptance test!).  If I recall correctly, the next thing I did was purchase my first 5.25" floppy disk for, I believe, $8 from the teacher so I could save the program.  When I wanted to move the next equation, I created my first UI that allowed me to select which equation I wanted to run.

After a week or so, including some time with one of the math teachers to explain how to solve quadratic equations - which we hadn't learned yet - I had a fully functional program that some of the other students were interested in using.

And, I was hooked.

Next came explorations into graphics, both the clunky low-resolution and the much more interesting high-resolution modes available on the Apple.  I played with shape tables, learning how to move shapes smoothly around the screen.  When BASIC code became too slow for what I wanted to do, I had one of my more advanced fellow geeks show me this "assembler" thing I had heard was pretty fast.  That led to my first computer book purchase so I could dig even deeper.  I had gone over to the dark side... I could now lock up the computer faster than anyone had imagined!

I also started reading magazines such as Byte at the local library, and learned about the Apple founders, Steve Jobs and Steve Wozniak, and their vision for computers everywhere.  It was now early 1982, and my  choice of future vocations had completely changed.

I remember the 1984 announcement of the Mac, and seeing one first-hand at my Uncle's place a little while later.  I still remember how easy it was to use, and how the floppy disks were so tiny!  The future had arrived, or so I thought.

When I went off to university, now to become a professional software developer, I was struck by how primitive the mainframes I now had to used seemed compared to the desktop Apple ][ I had.  These so-called "powerful" computers couldn't do anything remotely like the graphics I was able to write on the Apple and, dammit, I couldn't even directly access specific memory locations!

A couple of years later I was back on Macs while working summers at Bell-Northern Research, and back to that familiar, easy to use feeling.  It all just made sense, and it all just seemed to work (for the most part).

It wasn't to last, though.  At some point I had to work with PC's, and I was appalled at how primitive, how clunky and how... un-fun they were.  Over time I became used to the PC, although UAE's in Windows 3.0 constantly made me want to go back to Macs.  Unfortunately, all of the clients I served were PC shops.

It wasn't until 2006 that I was able to work with a Mac again, this time a MacBook Pro.  What a fantastic machine, although I had to leave it behind when I moved on from that company.  In the ensuing years it became more and more clear that not only were all the cool kids using Macs, but the people who I respected and did serious programming work used them.

I resisted the iPhone, initially, kind of as a matter of principle about Apple's closed model for the App Store.  Once the iPad came out, though, I was once again hooked and picked one up.  I haven't looked back.  I'm typing this from a MacBook Air, whose Bluetooth mouse has about as much computing power as the Apple ][ that started this 30-year journey.

Steve Jobs' vision made computers approachable to everyone.  Yes, there are more PC's Windows out there, but Windows wouldn't exist if not for the original Mac.  Steve Jobs' vision also focused squarely on making the total user experience a primary driver in what they created and how it worked.  He will certainly be missed, but he does make St. Augustine's words ring true:
If you want to be immortal, live a life worth remembering.
I could have been that voice from the pointy end of the airliner you're strapped into, telling you how we're number 14 in line for takeoff at O'Hare and it'll "only" be another 30 or 40 minutes until we're ready to roll.  Because of Steve Jobs, I'm here writing about software development and helping others to improve how they do it.

Thanks, Steve.  My heartfelt condolences to your family, and may you rest in peace.

3 October 2011


Some recent events came together in one of those "The Universe is trying to tell you something, Dave" sort of ways.  It could all just be a coincidence, of course, but that wouldn't make much of a story, would it?

First, I've been reading Carl HonorĂ©'s book "In Praise of Slow", which discusses the rather negative effects that closely watching time has had on our society.  In the book Carl looks back at how we have become more and more accelerated as we've been able to keep better and more precise time.  Carl wrote about the Curator of Time at the Science Museum in London, who oversees a collection of some 500 timepieces from ancient sundials to atomic clocks

This curator has what Carl described as a "claustrophobic relationship with time", including a wristwatch that had a radio receiver that read broadcast time signals in order to set itself to maintain accurate time.  Carl spoke of how the curator would experience anxiety when the day's signal was missed and the watch could be 'off' my a millisecond or two.  Essentially the curator was obsessed with precise, accurate time.

The curator's name is David Rooney.  There's nothing quite like seeing your own name in a bestselling book about slowing down to catch your attention!!

The second event was actually a conglomeration of a few things, including watching the rain run down my home office window, that made me thing of a quote I saw years ago from Kent Beck.  I recalled that it went something like, "when you have water and a mountain in conflict, bet on the water".  Off to Google I went to find the exact quote and the very first hit was a short blog post I wrote about it in 2006... evidently it wasn't the first time I've found that quote interesting.

The post referred back to a message in the XP Yahoo Group, in which Kent said:
Bruno pointed out the effects of water. If you have a mountain and water in conflict, bet on the water. The water knows where it is going--downhill. It actively works at getting there. If it gets blocked, though, it doesn't hammer away at the mountain, it flows around. Eventually, the water gets where it is going. When I keep in mind where I am going, when I respond to resistance with listening instead of belligerence, when I keep doing my work as best I can, then I have influence. Sometimes I miss the lack of drama and spotlight, but I appreciate the results.
These events on their own were amusing and informative, but then a third thing happened.  At a client this past week, a manager asked to talk to me.  I was asked for advice on how they could implement several things that I had been pushing them to do for about 18 months.

My frustration at the perceived lack of action had been growing, and I have wondered about my skills as a coach.  I suppose the skill I should have been wondering about the most was Patience.  I expected people to change immediately and listen to and implement every suggestion I made.  After all, I've been at this Agile thing for over 10 years... I'm a bloody expert!!  It seemed as if no one was listening, but in reality they were.  The people just either weren't ready to change, or had other forces in play that were preventing them from changing.  I simply needed the patience to act like water does - just flow around the rocks in order to get where you need to go.

Flowing water also has a funny way of eroding through rock in order to make it easier to get where it's going.  It just doesn't do it very quickly on a human time-scale.

The lesson to take from this is that we can make huge changes, but there are few circumstances where that can occur quickly.  The Badlands in Alberta and Montana in western Canada and the U.S. were formed by sudden, catastrophic outflows from huge lakes at the end of the melting ice sheets that covered North America about 10,000 years ago.  The Grand Canyon, however, took millions of years to create and occurred as the result of several other long-term geological processes that increased the speed of the Colorado River and thus it's ability to erode the rock.

Both processes created roughly the same spectacular results, but there just aren't that many ice dams available holding back vast quantities of glacial meltwater that can quickly carve out new Badlands.  Similarly, there just aren't that many opportunities for Agile Coaches to quickly change the direction of an organization, and when there are it's surely to have similarly catastrophic side effects to the floods that created the Badlands.

The much more prevalent type of organization requires changes that occur over a geological time scale, not a human one.  That requires us to have patience.  It requires us to go slow.

It would seem that, like the people on whom I was pushing my views, I wasn't ready to hear or act upon the message.

Hey Universe... I get it now, OK?!