VersionOne Turns it Up to 10: Three Things You Never Knew About Agile in ‘02
It all started on July 1, 2002 in a shady hotel room with two people – myself and our CEO Robert Holler. Don’t worry; this is NOT going where you think it’s going!
We were VersionOne. One of the first agile project management tools on the market… People thought we were insane! The world of software development was much different back then, and breaking into agile (much less the agile project management tools market) was exhausting. But we did it. This month as we celebrate our 10th anniversary, I want to talk about some of the ways we’ve “turned it up to 10” (to borrow an XP term)… Not just VersionOne as an organization, but our product and the industry’s adoption of agile in general.
I’m still burning code at VersionOne today, and I can tell you that agile in 2012 is nothing like agile in ‘02. Three main differences stand out in my mind over the years.
In 2002, agile development was…
1. More XP centric. Okay, and some Scrum. The term “agile” didn’t really catch on until later when other engineering methods picked up speed. We still have a long way to go, but it’s cool how many different agile methodologies are being embraced in enterprise environments. Some are practicing pure agile, but also hybrid agile methodologies which we never imagined 10 years ago.
2. Only the little guys. Agile, by its very terminology (telling “stories” and treating planning as a “game”), was too “extreme” for larger organizations, whose modus operandi was plan-driven development. We were still coming out of the dot-com era; only the smaller guys were open to trying agile development because of a tremendous pressure to deliver product fast. For fledgling companies trying to break into the market, a one- or two-year plan didn’t make any sense; believe me, we knew. Agile helped these guys get shippable, billable products out the door fast. Ten years later, that’s just how software organizations do it – today people at huge companies are successfully practicing agile on a much larger scale.
3. Done mostly with Microsoft Project (ouch), tactile cards and whiteboards. What’s wrong with these? Nothing… until projects become complex and more people get involved. Cards and other starter tools were good, but they couldn’t scale then (and they can’t scale today) to support geographically disperse or multiple teams, products and stakeholders. They didn’t for us, and they don’t for many other teams out there growing their agile initiatives.
It has been cool to watch agile grow and continue to have such a huge impact on the way software gets delivered. VersionOne as a company has matured and evolved, and so has our product, as well as the adoption of agile in general.
Initially our product had roots in XP and Scrum. We started with a planning game and story cards (a flow that XP and Scrum laid out). In fact, I still have our original VersionOne story cards from when we first started developing the product! As a dev team, we started out practicing XP by the book. Things matured and progressed, and we developed a set of techniques on our own that incorporated aspects from those methodologies as well as others – not just pure XP or Scrum. Today we have a mature hybrid process that we use as a team and as a company.
The VersionOne product has gone through a similar evolution. Game/story/iteration planning roots incorporated practices which have advanced to sophisticated product functionality like kanban storyboards and the ability to accommodate iteration-less teams (i.e., having the flexibility to practice one- or two-day iterations).
Finally, the adoption of agile within the industry has evolved in the same parallel. Teams out there in the wild have adopted and adapted “by the book” processes to meet their needs and cultures – incorporating ideas and best practices. Innovation Games, kanban and “pulling” stories (versus pushing) are good examples. You can get a much tighter feedback loop when you have pull-based dev practices. In these situations, every day… every hour is like an iteration. You can get more work into the build and deploy with every commit, for maximum efficiency in your product delivery.
In my follow-up post next week I’ll wrap up how we ‘Turned it up to 10’. I’ll also share some things you probably didn’t know about VersionOne, including raw video footage of the hotel “office” and a funny story from Mike Cottmeyer, who was one of our early hires.
Read Part 2