I recently got invited back, for the third time, by a client in the “Leisure, Travel & Tourism” industry to develop applications for their Cruise business. I play the role of an Engagement Manager and Business Demand Manager, whereby I am responsible for business idea harvesting and business idea vetting for the client

In the past two years, this client has moved from a crappy Agile implementation to doing Agile the right way to implementing a lean software development system. They have taken the concept of smaller batches, removal of waste, and continuous flow of value to heart.

A common problem in many organizations is that business often pushes projects into an IT organization faster than IT can complete projects. Some of those projects simply accumulate within the organization, become work in process, and slow down the system. To counter this problem, the business at this client ensures that they do not overfill the hopper and clog the system (IT).

It is all well and good to make sure that wasteful activities are being removed from the development process; it is another to make sure that the right projects are being worked on.

As part of the initial engagement, the Product Owners and I go through the complete wish list to determine the cost and benefit of each of the projects or enhancement requests. As an example, there were 55 line items in their 2008 Value Stream Analysis spreadsheet; most will never see the light of day as their relative ROI is poor compared to the others on the list.

Funding is asked for and approved based on the work done in this joint session. Only projects that meet a certain ROI threshold are approved. Project funding is denied if there are questions surrounding the ability to meet the targeted ROI. The benefits are evaluated 6-12 months after a project is delivered; shortfalls are analyzed in an effort to learn and to not repeat the same mistake.

The modus operandi is unlike that in most agile implementations that you see elsewhere. There are no iterations; instead, requirements in the form of stories are pulled by the team as they complete the stories that they have been working on. The Product Owners and I make sure that the backlog is always kept prioritized and that the top of the list is well thought out and defined.

The team is not collocated with the Product Owners — instead, most communication occurs via Skype and GoToMeeting. This actually works remarkably well for explaining the stories, clarifying issues, and demonstrating completed work.

Iteration planning is replaced by Skype and GoToMeeting sessions between the team and the Product Owners just prior to the start of that story. The team picks up a story or two from the top of the prioritized backlog and calls the Product Owners to discuss and ask for clarifications. The teams break up a larger story into smaller stories if necessary and begins test driven development.

Informal demos happen as the story is being worked on (and an interesting portion has been implemented) and when it is finished. There is no formal end-of-iteration demonstration. Feedback is incorporated immediately and the story re-demonstrated. Once the Product Owners are satisfied with the story, it is ready to be moved into the QA environment; promotions to Production happen every week.

The teams working for this client are significantly more productive than other comparable teams following the standard Agile way of developing in 2-week iterations. I think this increased productivity is due to the increased focus on a story or two at a time, quicker feedback and turnaround, minimization of in-iteration overhead, and continuous effort for removal of wasteful activities.

While this level of fluidity is more than what most new Agile teams can handle, they can still attempt to implement some of the practices that lead to a continuous flow of value. Story boards can provide a quick indication of and help regulate the amount of work in progress. Frequent demonstrations can speed up delivery and make the end-of-iteration demonstrations a breeze.