Monthly Archives: March 2008

Why Agile isn't good for shrink wrapped Product development

Preamble: Here’s a post I wrote nearly a year ago which I’ve sat on until now. I know the Agile vs. Waterfall (or whatever other development methodology) issue has been rehashed a great deal but now that I’m working as a consultant and particularly after having pushed my first project into production, I felt it was time to hit the “post”  button.

First, notice that the in the title the “P” in Product is a capital letter. When I was at CodeGear (CG), there was an effort to use $g(Agile software methodology) and I reached a point where I felt it was not good for large, complex, version 10.0 code bases sold through channel sales for profit. To me the $g(Agile Manifesto) describes what I’d refer to as a “close combat” software development that calls for the ultimate flexibility necessary to adapt quickly to a dynamic situation. But that level of flexibility comes at a high price, like close combat itself, given the unpredictable nature of a dynamic environment. It’s been my experience that that’s not retail product development and what I’ve come to realize over the years is that if you fail to evolve your development process along with your product your chances for success will likely follow.

For me, what came out of the formal Agile training I received while at CG and a year spent using the process is that it was worth learning but the team would have benefited more by not trying to completely switch lock, stock and barrel (first mistake). The first clue, which admittedly I missed, came during the training where it was made clear there would be a “transition period”, lasting potentially several iterations before each mini-team could accurately “calculate” it’s velocity. With 20-20 hind sight I believe a better approach would have been to start with a complete review of what was wrong with the existing process and an analysis of why Agile was necessary. I now believe what we did was probably typical of many teams as the “Agile mentality” washed over the shores of development engulfed us all.

We (the development teams at CG) bought into the whole thing, got training, switched project management software, started SCRUM meetings, daily stand-ups, a backlog the works. That was wrong. I think it was too much change all at once and when the product requirements changed late in the process we reconfigured the team to respond accordingly and wound up relying on an older tried and true development process that had been used for years. At that time, CG polled it’s customer base and with that knowledge decisions where made to refocus on other areas of the product. The interesting thing is that Agile more or less fell by the way-side and no one really seemed to skip a beat. We needed a complete RTM plan with priorities and requirements pitted against hard dates. And yes, dates were, and I presume still are significant as CG works towards becoming an independent company. We desired many of the principles of Agile though many of which aren’t new nor unique to Agile. I mean who doesn’t want:

  • Satisfied customers
  • Sustainable development
  • Technical excellence
  • Motivated individuals

If your team hasn’t switched to Agile or is perhaps considering switching you need to take a long hard look at your current process and at the very least get your ducks in a row before you decide that a true culture change is best for your team.

I think Agile fits particularly well in the world of contractors (of which I’m now a member), internal facing application development and IT and in those worlds makes a lot more sense. I’m now doing contracting work and I think working on small deliverable chunks over short periods of time is a great way to sustain a project. In fact, working as a contractor on a project several years ago, I didn’t focus enough on Agile principle #1:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Which directly lead to the end of the contract. Needless to say, lesson learned.

Relevant Links

Post-Agilism: Process Skepticism
Agile people still don’t get it
Accountability in a Scrum World
The start of the end for Agile software development?

CCNET based EDI Invoicing Project Goes into Production

Over the past six months I’ve been working on a system to automate invoicing using EDI. The system is built on CruiseControl.NET and a collection of custom written source control providers and CCNET tasks. Back in December, I blogged about this project which integrates with a custom ERP system built from scratch by Falafel that processes half a billion dollars worth of transactions a year so it’s nice to finally see my small part come online.

There are several Open Source projects used in the implementation including:

Here’s a diagram of the system with CCNET at the heart:

EDI Invoicing using CruiseControl.NET

One of the many benefits of using CruiseControl.NET is the visibility the system can provide to the people in Accounts Receivable. Not only can they see what’s going on via the CCNET web dashboard but they can even install $g(CCTray) and monitor from their desktop as invoices are processed throughout the day. On the web dashboard clicking through to a specific “build” log for a given EDI 810 “build” provides invoice details including invoice number, customer name, date and dollar amount.

EDI CCNET Web Dashboard
As you can see I still need to customize the dashboard to fit into the web-based ERP system’s look and feel.

CCNET’s plug-in architecture made it perfect for this situation as it has numerous features that can be leveraged to create this, perhaps unusual, usage of a Continuous Integration server. I suppose CI could just as easily stand for Continuous Invoicing. 🙂

EDI 850 Up Next

My next task will be to re-work on an existing, read old, EDI 850 Purchase Order set of processes and integrate them into CCNET. Anyway, this has been a fun project to work on and I’ve learned a lot along the way and I’d like to give a tip ‘O the hat to John Waters, Falafel’s CTO, for all his help. If you’re looking for an ERP guru, I think you’d be hard pressed to top John plus he’s got a great sense of humor. One afternoon while driving back through the farm land of Watsonville from our client’s site, one of the largest organic food companies in the world, he quipped:

Here we go driving through our business objects…

Something only another geek could really appreciate!

Lastly, I have to admit after 15 years of doing product development feels very satisfying to design and implement a system that solves a real world business problem. There’s just no substitute for hands on experience!

Related posts:

[UPDATED: March 4, 2008] Forgot SubSonic which I use for data mapping/xml creation!

ScrewTurn the perfect small business wiki

If you haven’t taken a look at ScrewTurn wiki you should. In two words, it rocks!
Why?

I think this wiki engine can easily serve as a starting point for a flexible small business web site.
I’m personally using this wiki engine on my own web site not to mention Falafel Software is using it as an internal company wiki. I’ve also installed it at a client location and it’s been well received and used daily.
If your company needs help getting this wiki or an entire web site setup feel free to contact me.