Every Tuesday night (almost), I get together with my friends Ajit and Dustin. We’re old college budies. I lived with Ajit for a while and Dustin, having introduced me to my wife, was the best man at my wedding. Ajit is an IT guru for a casino. Dustin is a developer for an IT software/services company. I used to work for that company as a Product Manager prior to GXS and pulled Dustin in. I’m gone, but he’s still there. So, most Tuesday nights, we get to talking about the old days and the new days.
One project I was involved with before I left was piloting agile software development practices with the developers. Since my formal education as a software engineer left me jaded and opinionated about the traditional waterfall module (or, spend a lot of money and time on something, hope it works, and spend a ton more if it doesn’t), I had some research and stake into proving out a new way of tackling projects. Also, the fact that I did development with Ruby on Rails lent me some completely undeserved street cred.
So, for the last few months, Dustin has been updating me on Scrum. He’s positive. Walls are going down within engineering. Literally and metaphorically. No one is dancing in the streets with trumpets blaring, but these are IT developers we’re talking about. Many of whom, after that statement, will likely leave nasty comments and never read this again. I’m hoping Dustin tells me at the every least that the following things have happened (these are not all of the potential benefits by a long shot):
- Management visibility and on-going engagement has increased on projects, such that micro-management and requirements transmission issues are reduced and the actual number of concrete decisions per day (the CDPD rate) increase. Yes, I made that term up.
- Projects are more likely to meet deadlines, or where they are not, management and developers have signed off on any particular delay as a desirous event based on requirements changes or design feedback.
- Developer awareness of projects that aren’t assigned to them increases along with the ability to adjust requirements for smarter integration, such that seams between services are smoothed.
- QA became better able to validate the accuracy and usefulness of a service, rather than being restricted mostly to cross-checking the detailed design specs against the tables in the database and doing other somewhat self-validating exercises. In other words, the same syntax validation with more semantic validation.
I can’t take credit for the company going to an agile methodology. After all, I piloted a hybrid Agile (with a capital A) program and the company settled on Scrum. I like Scrum. At a tech forum, one of the Amazon executives talked about the ups and downs and it pretty much matched up with what I was seeing in my own hybrid approach. However, I’d like to think I can take credit for breaking the ice. Going cold-turkey on a more traditional methodology makes developers suspicious, worried about their job security and afraid of not being allowed to sit down in meetings (yes, Dustin, living up to my promise to mention that). Those are generally groundless concerns, but they do have to be taken into consideration.
But this is a GXS blog. So let’s talk about GXS. Prior to my joining the company, GXS had been investigating and piloting agile practices. Part of my interview involved a discussion about my experiences with and thoughts on agile, so I could tell before taking the job that I would get to work on something that interested me even if I found EDI to be very dull. Now, those of you who work in B2B EC and SCM know that EDI is far from dull, but I came from another industry, came of age in the era of hypertext and had only heard the term slurred in a hushed voice on subway trains.
Agile methodologies have a consistent theme about doing things in context. Work in context. Develop requirements in context. Engage the customer in context. Abstraction, vagueness and high-level thinking are less likely to produce solutions that you don’t dislike using than solutions produced context. An example of an out-of-context process: heavy-handed change management processes. The goal is usually to reduce the disruption of requirements added during a development cycle. But in context–that is, the real world–change is not a bad thing and so it’s better to take change as a core principle of development and figure out how to make change less disruptive not by reducing it but by capitalizing on it.
So, I have to re-evaluate agile because agile itself must be placed in context. Consider this principle of agile development from the Agile Manifesto (http://agilemanifesto.org/):
Business people and developers must work
together daily throughout the project.
Well, that worked great at my old company where development for my product line was focused into one wing of one building. But GXS, thinking in context, is pretty global (http://www.gxs.com/gxs/worldwide.htm). You can’t have all the team members in the same room, in the same time zone, throughout the project. At any given point, some are wake, some are asleep, some wish they were asleep and some probably wish they were more awake. So, right there, is a big challenge. If we agree with that principle, how do we attain it without physical proximity from the stakeholders? That’s a context issue. If you’ve been reading my blog, you know that I have a habit of flying overseas for a while to spend a few weeks sitting on the development floor working hard on achieving a good CDPD rate and providing customer perspective during development.
For 2008, one of my goals is to propose a new release management strategy. Some GXS deployment practices still have the feel/smell/taste of distributed application roll-out. Being an outsider, maybe it’s more pronounced for me. A few colleagues of mine with more tenure might disagree. But, never the less, it’s something I’d like to investigate and tackle. GXS uses customer meetings to review and validate requirements during development as well as beta programs and other agile strategies today. Where else can we optimize?
Given that the Trading Grid is a hosted, on-demand SaaS platform, we owe it to ourselves and to our customers (hopefully including you) to capitalize wherever we can on increasing the speed and accuracy of our delivery. So I’m doing some research and some thinking on this release management question. I’m starting from core principles. What would be valuable to us and our customers, regardless of any other considerations:
- Faster turn-around on defect fixes.
- Faster time-to-market changes from customer feedback.
- More predictable time-to-availability of your defect fixes and changes from your feedback.
- Predictable recurrences of larger releases, such that you can plan business impact and manage more by exception.
When I say faster, above, I don’t necessarily mean that it takes less time to develop. I mean that rather than waiting for a big release in which to include a bunch of fixes, fixes would be pushed out closer to “as ready” than “in bundle X.” Obviously, we do this today, but we might not be doing the best that we can in context.
One interesting habit that we still have today in the Trading Grid is the idea of a release number. We assign outward-facing version numbers to Trading Grid solutions. As if you’d call in one day and say “I’m using Intelligent Web Forms version 5.23.” We don’t put version 6 in your shop and version 7 in Bob’s shop. It’s hosted, on-demand Saas. You’re all using the same version, all the time! Now, there’s value for the sales guys to know that a new release has come out and to differentiate the functionality from any previous release. But I’m not convinced that saying 5.23 is any more valuable than saying March, 2008. Certainly, it’s no easier to confuse March, 2008 with June, 2008 or with March, 2009.
Now you know why I gave up on being a presidential speech writer. This exercise does help me order my thoughts, raises new ones and gets my engines turning. I might do a blue paper on this, internally. That’s kind of like a white paper, but I’d print it on blue paper so people pay more attention to it. Sneaky, huh? If I do, I’ll try not to abuse bold as much. As always, feedback is welcomed and will be incorporated early in the process with minimized disruption.
