On methodologies and practices
Last year I finished the 400+ page 2nd ed’n of my book http://bit.ly/PxMrK. Today I’m overwhelmed at writing my first blog post.
Those weren’t supposed to be the first two lines of my first blog post - it was a Tweet, whining about my writer’s block. That would have been the end of it, except that Neil Raden (http://www.twitter.com/neilraden, “Nell” to his readers in Russia) tweeted back “you just wrote the 1st two sentences. Keep going.” That made for a good opening, so I took his advice and kept at it. (By the way, I’m at http://www.twitter.com/alecsharp.) Evidently, I kept at it for too long - this post has become an article, so I promise I’ll keep things shorter in future.
Other than being born with a dominant procrastination gene, the reason I had trouble starting wasn’t that I didn’t have anything to say, it was the opposite. I guess a consequence of getting into blogging years later than everyone else is a backlog (a “backblog?”) of topics to write about. Choosing the topic to start with was hard until I asked myself “what have you heard lately that really interested you?” An easy choice was some observations that Ivar Jacobsen made at a recent conference:
- Methodologies (OOAD, RAD, RUP, XP, Agile, …) inevitably grow until they collapse under their own weight.
- We should get past “branded” methodologies and instead focus on “practices.”
Of course, Ivar had much more to say than that, and more eloquently too, but he nailed some ideas that I had been trying to articulate.
First, the background. In March, I spoke at Software Education’s “Software Development Conference” (http://www.softed.com/sdc) in Australia and New Zealand, which was a whole bunch of fun. The event was held in Melbourne on Monday and Tuesday, Wednesday was set aside for getting across the Tasman Sea, and then the programme was repeated in Wellington. Great locations. A bonus was the small number of speakers, five in total - Ellen Gottesdiener, Phil Abernathy, Meilir Page-Jones, Ivar Jacobsen, and yours truly. That meant we all got lots of “air time” (good for our healthy egos) and had time to listen to and get to know each other. I learned from everyone, but this is about Ivar’s session “Be Smart! or What they don’t teach you about software at school.”
Ivar began by pointing out a central, recurring obstacle in software development - it’s a fashion industry. Fifteen years ago the fashion was all about OO, and today it’s all about Agile and Scrum. Along the way we’ve encountered RUP, CMMI, XP, and so on. In the search for a silver bullet, each gets adopted with a near-religious zeal that I’m sure makes the originators shudder. The problem is that there is no silver bullet that will slay all the development werewolves, but every methodology wants to be complete. So, in a doomed quest for completeness, each fashion trend (methodology) piles on bits and pieces borrowed from other fashion trends. Because it becomes a “soup of ideas,” the methodology loses its original uniqueness (except in name!), and nobody except gen-u-wine rocket scientists can figure out which bits to use in any given situation. (The cynic in me is compelled to add that we’ll need a “BOK” to catalogue all these bits and pieces, and some costly certification to demonstrate knowledge of what those bits and pieces are, if not which ones to use when.) Eventually the name ceases to be useful because it doesn’t really stand for anything distinct, and the methodology collapses under its own weight. Time for a new silver bullet!
I’ll add two points:
- This isn’t a new problem. When OO first became a really big deal in the early 1990s, I was stunned at how easily some vocal proponents dismissed the sum total of earlier methodologies like Structured Systems Analysis or Information Engineering. Around then I had the distinctly unpleasant (but educational) experience of being on a flight with 20 or 30 people returning from an OOPSLA conference, freshly dipped in the sheep dip of a new religion. They were so smug (and loud!) in their pronouncements about the one, true way that I swore I’d never let myself get so caught up in any particular methodology.
- The problem isn’t restricted to software development. I work mainly in the business process field, where there’s plenty of evidence of the phenomenon. Lean and Six Sigma started out as (relatively) clearly defined and useful approaches, but of course, neither was “complete.” So, bits and pieces were pulled together, yielding Lean Six Sigma. However, the roots of both methods being in manufacturing, things didn’t always work so well in non-manufacturing environments. No worries! - we now have Lean Six Sigma for the Office and Lean Six Sigma for Services (a bad idea, in my experience, but we’ll leave that for a later post.) I’m expecting that any day we’ll see Lean Six Sigma Office Services for the Left-Handed. A quick survey of Six Sigma conference and educational topics reveal that, like a fashion industry, bits and pieces are being added from far and wide, including corporate social responsibility, organizational development, and… wait for it… Agile. Of course, in the other direction, Agile has discovered Lean, and the discussions about what kanban really means in an Agile environment can be a muda of time. And don’t get me started on the latest, Green Six Sigma…
The solution Ivar suggests - part of “being smart” - is to recognize that all methodologies involve a collection of specific techniques or “practices.” There are hundreds of them, many of which are good or even best practices, but virtually none are unique to a particular methodology. He listed several, including:
- User stories
- Pair programming
- Scrum
- Co-location
- Iterative development
- Test-driven development
- Aspect-orientation
The key is to develop skills in specific practices, backed up by training and mentoring, so these practices can be brought to bear as needed. When your “existing way of working” (current methodology) isn’t working so well, don’t throw out the baby with the bathwater by abandoning it entirely. Instead (and I quote):
1. start from your existing way of working
2. find your pain points
3. change one practice at a time
Looking back, that was an element of many successful projects I’ve been on. Way back in 1979, when I was working on one of my first projects, we were having trouble arranging meetings with our busy clients in the Treasury Department. Our new project manager announced one day that the two primary developers were moving, and would be sitting in the middle of the Treasury Department. There, they would work together on developing the core functions on a new development platform. Co-location! Pair programming! I was dubious, but of course it worked brilliantly. A couple of years later, on my first consulting assignment, the PM told me we would be developing and delivering the system in ten (10!) releases. I thought it was nuts, and protested that the overhead of carving out all these releases would kill us. He ignored my protests, and gave me my assignment - developing the test cases that would be used to scope and sequence the iterations. You guessed it - iterative, test-driven development worked brilliantly, and the client was thrilled at the ease with which each release could be absorbed.
Now, does that mean that we were Agile before our time? No, just that good project managers added a few good practices to an existing way of working. That’s being smart!
One reason Ivar’s talk resonated with me is that I teach modeling and analysis techniques, or “practices” as I think I’ll start calling them. Wherever in the world I am, whether it’s Brussels, Boston, or Bangalore, a conversation that occurs all-too-frequently begins when a participant says “These techniques you’ve shown us are great, but I don’t think we’ll be able to use them.” I ask “Why not?” and the answer is some variation on “We’re a <<RUP/Scrum/Agile/whatever>> shop.” Of course, the originators of these methods would shudder to hear this - I don’t think they ever intended such a dogmatic adherence, but that’s what happens. The ultimate irony in this is that on one hand, methodologies expand by incorporating more and more practices from other methodologies, while on the other hand is the tendency to treat a method as an all or nothing proposition.
It’s worth remembering that Agile began as a limited collection of practices that had previously been successful. And giving it a name served a real purpose as a way of organizing conversations and sharing knowledge. Inevitably, though, the term will become less useful. That may already be happening - Ivar observed that “Agile” is increasingly used as an umbrella term for all that is good in software development. I hope that whatever comes next will focus less on a branded methodology - No Labels! - and more on leveraging our knowledge, skills, and experience with specific practices.
Check http://www.ivarblog.com for Ivar’s blogs on the topic, and some good discussion.
I help organizations improve their business processes, determine requirements for the systems that support them, and teach their business analysts to do the same.
