Alright, so the nursery rhyme goes slightly differently. Regardless, I couldn’t resist talking more to the Agile process; since another big dogs has realized the benefit. Adobe (of all folk) has announced the success of using an iterative process in the development of CS3.

Clearly, no one process will rule all. But I still reassert that I like the idea of incremental process.

Do a little…
review…
improve…
repeat…

Most modern processes have such a concept, whether TQM, Six Sigma (DMAIC), BPI, or Lean. I couldn’t imagine going into product development anymore that would last 2 months or more without an iterative based approach. It is too easy to misinterpret, miscalculate, and misunderstand client needs and intentions.

Part of the story also speaks to “Bugalaunch” - the death march to release depriving team members of precious sleep, social lives and undoubtedly personal health. Too often it is the unceremonious end to a project to be rewarded with Bug Hell; which I think exists somewhere around the 222nd layer of the abyss.

This made me realize that it makes the job of motivating developers very difficult, since they never really get a clean, clear reward of a product delivered well and gracefully. I mean, in a traditional Waterfall approach, the chances of something going bad and erasing months of hard work is high. Why not allow for incremental “showing off?” The Agile method allows developers to demonstrate the exceptional work they do gradually. If the project does go awry (for whatever reason), the customer would now be aware of all the good work that happened before a major hurdle is reached. They will therefore be more sympathetic, appreciative and understanding of the hard work it then takes to right the project and overcome the hurdle.

Of course, my developers should beware, because I do like the 20 bug rule too.

Developers are classically referred to as prima donnas. We are a needy bunch that left unchecked can cause a number of ailments. But, is this characterization really limited to Developers? I find that everyone channels their inner “prima donna” to some degree. This means they want some level of influence, interaction, visibility into the processes that are important to them. We dislike inconvenience and treasure being free to express our ingenuity and cleverness!

This isn’t really an unrealistic expectation, is it? I mean… clients pay us a lot of money to develop systems for them. If it is my pocket book shelling out dough, you’re damned-straight I want to be involved, and know how my money is being utilized… sooner, rather than later. The system designers, whether BA, IA, PM, QA (or other acronym), want to feel pride that they are significant to the success of a project. Quite frankly, the effects of group collaboration on idea generation is extremely effective.

However, the point is that this process operates most efficiently when it is completely transparent. Transparency - a simple word. But a powerful concept that applies to everything from Sarbanes-Oxley to my physician’s visit. It boils down to trust and honesty; because you MUST give visibility to everyone involve.

Enter stage left, Agile processes. Agile shares a lot with the somewhat illusive web 2.0 moniker. The point of both is to make the processes more transparent, collaborative, and organic. We employ a variety of Agile called Scrum. I really hate cheesy processes and the silly names they use. Scrum is no exception. I has its own names, including ScrumMaster, Sprints and Retrospective; generally based on the English Rugby sport. It elicits smirks and giggles nonetheless. Lot’s of humor on the web:

YouTube: High Moon Studios: A Portrait - Scrum

YouTube: Scrum Masters 2

It’s all funny and insightful in its own right, but I take it seriously from the conceptual level. How I look at it, most fail to realize that Agile isn’t about providing good solutions faster as much as it is about engaging the customer to provide the correct solution for their needs. The point is “customer engagement and satisfaction”. The most efficient way to achieve this goal is to involve the customer as much as possible throughout the development lifecycle. It is integral that they are available to clarify, elaborate, and prioritize the features and designs they want from the feedback we give them.

As a manager of “prima donnas”, I want to empower my developers to deliver the best product they can currently conceive that meets the customer’s expectations. To me, this means that I need to put the developer as close to the customer as possible. Agile development processes and tools generally answer this need.

The basic premise is to start with “what you know” develop with “refactorable” techniques in “small iterations” and “solicit customer feedback” often. There are a lot of concepts in that small sentence. “What you know” implies that we don’t belabor the requirements since it’s hard for the customer to truly visualize what they want in its entirety. “Refactorable” implies that we are going to develop in such a way that change isn’t hard. “Small iterations” and “solicit customer feedback” imply that we want the customer to be an active participant in the software we develop. Plain and simple, we know software is expensive and we want to bet on the best system to ensure that your money buys what you need now, and can easily grow to what you need tomorrow.

We utilize tools like XPlanner, Basecamp, and MediaWiki to engage our customers, while enabling our developers to use the best tools to deliver the best product to our clients.