While I’m generally not fond of websites that function like a PowerPoint presentation, I am fond of the Knight News Challenge. I heard about it on the radio and thought I’d check it out. It’s a cash prize for ideas on using technology to further community interaction in specific geographic locations. The foundation behind this thinks that the Internet has created wonderful virtual communities, but it is under-utilized in strengthening existing physical communities.

So, I started thinking about what I would do. The first thought that popped in my head was: farmer’s markets. My wife gets a good chunk of our produce, meat and some other things at a local farmer’s market. We supplement that with cereal, pasta, diapers for the kids and other such consumables from the grocery store. Therefore, I have a decent view of the upsides and downsides to both services.

On the one hand, the grocery store (very much like fast food, in some ways) offers consistent availability of products, layout, easy navigation and also facilitates bulk shopping while being highly available. The farmer’s market excels at providing freshness, local connection, products whose organic or wholesome nature are easier to verify and understand, high quality seasonals and adding a little spontaneity to stocking up. I think the two complement each other well, as far as our routine goes.

A good farmer’s market, though, is more of a community event than a chain grocery store. That’s not a knock on the grocery store. McDonald’s doesn’t try to be a community social forum in the way that a local sandwich shop might book bands and other events. It’s a different model. But what I’m wondering is whether the farmer’s market can use technology to attract more people who have become somewhat reliant on the conveniences and predictability of the grocery store.

The infantile form of my plan involves developing a web service for facilitating pre-event interaction between farmer’s market organizers, vendors and shoppers. For example, if a vendor can indicate a day or two in advance what they intend to bring for sale at the market, consumers may be able to better plan their menus, shopping and other things. Provide a little bit, but not too much, predictability. They can also provide descriptions or information about their products which are too logistically complicated to display at the market. It might also be possible for vendors to lock in some revenue and for shoppers to lock in some reliability in advance by reserving up to a certain quantity of goods for pickup at the event.

For large events, a “floor plan” type display would also allow people to see what’s available, where it can be found in the market and also view things like hours, special parking (if applicable) and other things which are generally only learned by showing up the market a few times and figuring it out. The key would be to increase the convenience of the farmer’s market in a way that boosts attendance and creates more of an ongoing atmosphere beyond a single event. To get more of the community involved, but not to fundamentally change the market. Lower the barriers to entry and encourage the farmer’s market to be less of a vicarious thing–which works for some people, but probably keeps some people away. Securing advance sales and advertising products a little more would hopefully be enough incentive to get vendor participation and buy-in.

That’s not as fancy as the Google moon landing prize. But, there are clearly fewer barriers to entry. Now I start wrestling with myself over taking the time to enter. If you’re reading this and thinking it’s a secret GXS product initiative, it’s actually just a personal technology interest post. Since I should probably say something related to GXS, though, I’ll say that the Managed Services customer forum is going well. I always like a chance to suit-’n-tie up for a customer meeting and play “professional” briefly every quarter or so.

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.