Agile best practices applied to business problems

In the past few years, Ross Pettit, client principal at Chicago-based ThoughtWorks Inc., has seen a shift in client requests. The agile software development consulting firm’s projects are still mainly grounded in custom application development but, more often, he said, organizations want to apply agile best practices to non-IT-related projects. Pettit suggests following these initial steps when adopting an agile project approach:

Develop a release planning stage in which aspects of the project are divided into smaller, more manageable chunks. This stage involves defining the problem in business, not technical, terms, choosing and pairing up team members from different aspects of the business and assigning project facilitators who can step in to remove obstacles.

Every week there is a checkpoint to gauge progress, the understanding of the problem, what needs to be done next, and how the team is tracking against the agreed-upon solution path. By having the primary stakeholders involved, the business problem is laid out for all to see and obstacles can be removed. “Week after week, there is tremendous transparency and exposure to all the stakeholders …,” Pettit said. “This allows stakeholders to make the resources available for what needs to be done, immediately.”

Be retrospective during each checkpoint. Ask what worked well, what worked poorly, what was confusing, and what to change. “On a weekly basis, this builds in mechanisms that create continuous improvements … where you have continuous planning and tremendous visibility,” he said.

It’s OK to fail, but fail fast. “The nice thing about agile is that it is not only OK to fail, but it’s really good to fail,” he said. “The more often you try and fail, the more you learn about the problem in front of you.”

Start with the hardest nut to crack. Pettit has seen agile projects fall apart because project teams decide to go after the simpler tasks first. “Too often, I see projects fail because they were able to get two or three easy things accomplished, then they get to the more difficult ones they were putting off, and they say ‘I don’t know if we’re up to that one,’” he said.

And even though a project may be focused on a business problem, the CIO will be called on to act as an agile executive. The CIO is the one who can pay attention to all the data coming out of all the projects. “The CIO can make decisions outside of the context of the project, that others may not feel empowered to make, and will see problems that others may not by looking from the outside in,” he said.

Working on a new project and hitting a few bumps? Send me your project problems and I’ll post them on our blog — without your name, or company name, of course — to see if your peers have any advice. Email me at [email protected].