"So in war, the way is to avoid what is strong and to
strike at what is weak." - Sun Tzu
A couple months ago, I eagerly made my annual pilgrimage to SIGGRAPH. If you've worked in the computer industry within the last quarter century, you might have heard about it by now. It's the Association for Computing Machinery's Special Interest Group on GRAPHics and Interactive Techniques. Basically, it's the technical conference of the year where anyone and everyone that has anything to do with making computers display pretty pictures all get together for a week. It's an invigorating paradise of information, collaboration, inspiration, and fun. Included amongst the tens of thousands in attendance are folks from the movie industry, gaming industry, academia, commercial industry, government researchers, student volunteers, and more. For most computer geeks, you spend the week drinking from a fire hose, exhausted, and loving it.
For me, I'm very methodical in my attendance, making sure to soak up as much information as possible, find the latest and greatest I can apply to BRL-CAD, renew connections with fellow researchers, take notes to share with others when I get back, and generally try to get the best value for the people that thankfully send me there year after year. Naturally, every SIGGRAPH has it's own particular flavor of surprises and delightful discoveries that make for a memorable and productive experience. This year, however, the surprise came during a small Birds of a Feather (BoF) session -- curiously unrelated to graphics -- that was tucked away in a far corner of the convention center at the end of the last day. The session was entitled Agile in Production.
The BoF session certainly piqued an interest given the pervasive nature of agile techniques within many open source communities and businesses alike. I was curious to hear what others in industry were doing in their production environments. Subconsciously, I was hoping to find a golden goose laying project management best-practice eggs that I could carry home with me.
The session was informal and informative with dozens of topics being covered over the two hour timeframe. For the most part, though, the talks were surprisingly unsurprising. There were the usual questions from people who have never heard about agile software development and the usual answers from others on what the optimal sprint length is (there isn't one). Various agile project management techniques were compared and contrasted with numerous people (including yours truly) sharing anecdotal accounts on things that worked and didn't work for their teams. The trend, however, was clearly reinforcing. Namely, there is no "one size fits all" solution and there are plenty of misconceptions to go around.
If you're one of those that hasn't been following the industry buzz, the short story on using agile methods for project management is that it's another lean or lightweight process. You collaborate, communicate, and iterate with a relatively high frequency so that you can respond to changes quickly. Nothing is fixed in stone, at least not for very long.
There's a lot of the core principles spelled out in the Agile Manifesto, but most new implementors will still find themselves facing lots of ridiculous terminology such as pigs and chickens, scrums, burn downs, and sprints. That gets to the heart of where this particular SIGGRAPH BoF made an impression on me. I learned a new silly word to add to my repertoire: Kanban.
You see, most every summary of agile "best practices" you'll find on the net has one thing in common: you have to select and tailor agile methods to fit your needs. How you do that depends on numerous factors such as your team size, personality dynamics, work environment, technical proficiencies, production requirements, customer needs, and so forth. Unlike how eXtreme Programming (XP) made the need for process adaptation explicit, it's assumed to be a given with agile methods because you'll invariably find something you don't like! That notwithstanding, another best practice that usually follows is to start very small with some aspect of an agile method that you DO like and see how things go from there.
One of the most frequently adapted agile methods is the rugby-inspired idea of a "Scrum". Without obsessing on how the game inspired the concept or pedantic roles, at the heart of the process is the idea of breaking your development work down into relatively small tasks, prioritizing them, working on a subset of the most important ones for a very short period of time, and then wrapping things up before starting the cycle over again. At every iteration, then, priorities are re-evaluated and new tasks are assigned -- except, not necessarily with Kanban and not with our development team. If you want more information, there's a ton of great websites and books on the subject including Poppendieck's Lean Software Development and Cohn's Succeeding with Agile: Software Development Using Scrum.
Instead of assigning tasks, our development team self-assign their tasks. With my open source heritage, I found it particularly unnatural and unrealistic to have tasks assigned to developers because you generally can't make open source developers do anything unless they are paid to work for you. Even if they do work for you, some developers mysteriously perceive such marching orders as an assault on their professional discretion. Moreover, many people really just don't like being told what to do.
If you want your open source project to encourage and expand an international community of contributors, you might provide incentives, encourage, plead, or even beg but you usually can't realistically assign tasks. You especially cannot reasonably do so repeatedly and while expecting they meet deadlines with any sort of accountability! Kanban proponents sometimes describe this reverse selection as pulling instead of pushing.
Tasks are pulled forward by developers, not pushed onto developers. As a development method, Kanban is considerably more complicated, but that particular detail resonated with me during the SIGGRAPH BoF session. I discovered that our various scrum process modifications – which include taping up index cards into prioritized categories on a wall – not only already had a name but had an entire production mantra behind it. Kanban literally refers to visual cards in Japanese. Who would have guessed?
So what's the point? Well SIGGRAPH is, of course. As I excitedly reminisce about all the awesome research, agilities, kanbanging, and more from this year's SIGGRAPH, I'm reminded that next year will be the first time ever that the main conference will be held outside of the United States. SIGGRAPH is heading a little farther North in 2011 to make Vancouver home through the second week of August. That's right, Canada. SIGGRAPH will be in your neighborhood, so start writing those travel requests, justifications, and registrations to drink from the information fire hose. If you need help with directions, send me a line.
Here are some brief exemplar videos to enjoy from SIGGRAPH 2010:
Posts
No comments:
Post a Comment