Three Agile Methodologies — and How to Use Them in Non-IT Projects

Many project managers working in software development are well acquainted with rapid-fire deliverables and constant iteration of agile. But now, agile is gaining ground in other industries.

“If you look at the principles—collaboration, daily face-to-face communication—they are all good practices for any team trying to deliver a product or a service,” says Michele Sliger, an agile consultant and owner of Sliger Consulting, Denver, Colorado, USA. Ms. Sliger also served as a member of the PMI Agile Certified Practitioner (PMI-ACP)^® Steering Committee.

Here’s a look at three popular agile methodologies, and how they can work outside of software development.

1. Scrum
Scrum has found its way into a variety of projectized organizations, including law firms and universities.

Here’s how it works, according to the non-profit Scrum Alliance:

• A prioritized wish list called a product backlog is created.
• During the planning phase, the team selects a small chunk from the top of that wish list, called a sprint backlog, and decides how to implement those pieces.
• The team is given a certain amount of time, called a sprint, to complete its work and meets each day to assess its progress.
• At the end of the sprint—usually two to four weeks—the work should be ready to hand to a customer.
• The sprint ends with a sprint review and a retrospective.
• The next sprint then begins.

For Scrum to cross over into other industries, you would have to: “break down the requirements into a discrete set of items that could be worked across a set of iterations,” says Bob Tarne, PMP,engagement manager for IBM Software Group in Lenexa, Kansas, USA.

He used the example of working with an editor and illustrator on a publishing project.

“We break the book into chapters and start iteration one with chapter one,” he says. “We do the writing, get the illustrations done and do editing all within a [sprint]. We review at the end of the [sprint] and then plan out iteration two with chapter two.”

2. Kanban
With roots in the automobile industry, Kanban is adaptable to non-software development projects—especially human resources and legal—because its principles are not associated with any specific practice, says Abdiel Ledesma, PMP, owner of the Equation Group in Panama and president of PMI Panama Chapter.

Those principles are:

• Visualize the workflow.
  This can be done by using a card wall, with the columns on the wall representing the states or steps in the workflow and the cards representing the work items.
• Limit the works in progress.
  “If your team was working on five items at a time and not making progress, reduce that number to two or three,” Ms. Sliger says. “Select the most important, most valuable work items. Always be working on the next most important thing.”
• Manage flow.
  The flow of work through each state or step should be actively monitored, measured and reported in order to evaluate positive or negative effects of incremental and evolutionary changes.
• Make process policies explicit.
  Ensure an explicit understanding of the mechanism of a process to achieve a rational, objective discussion of issues—and facilitate consensus around improvement suggestions.
• Improve collaboratively.
  To truly leverage Kanban, teams must collaborate. “Kanban is like any other agile method in that the team can meet as a team to plan, meet daily for a stand-up, and can choose to do retrospectives to inspect and adapt their process,” Ms. Sliger says. “All these items and more involve collaboration and continuous improvement.”

To adapt to a human resources project, for example, visualize the hiring process through a Kanban board. Categories on the board would include a column for the candidates who submitted résumés, a column for candidates who are qualified for the position and a column for candidates who have moved past the phone interview process. Support that workflow with a document that outlines who is responsible for these different roles and kickoff the process with a short meeting attended by all stakeholders.

3. Extreme Programming (XP)
The name alone may turn off many project teams working on projects outside of software—and they may be right. XP focuses on test-driven development, small releases and a team structure that includes the customer, whereas traditional project management approaches generally do not, Mr. Tarne says.

Many of the rules for this agile methodology are designed specifically to address coding, designing and testing. Take planning, for example: A traditional project does planning up front; XP says to plan the release at a high level, but plan each iteration at its start (or every two weeks).

But XP does offer some lessons learned for non-IT projects.

“The most powerful of agile practices is the recognition of the people as the most valuable project asset and leadership as the catalyst,” Mr. Ledesma says. “XP has five values that can be emphasized in non-software development projects: simplicity, communication, feedback, respect and courage.”

Those values can—and should—be applied to all projects in every industry, Mr. Tarne says. “Communications is a great example,” he says. “I’ve seen a number of projects get derailed because of poor communications.”

Before You Adopt an Agile Approach…

No matter what agile methodology implemented, remember that it will work more efficiently with your organization’s support. Agile is best suited for organizations that value discussion and collaboration and support employees learning from their mistakes.
If your organization is not familiar with agile, you can help increase their buy-in by de-emphasizing the technical jargon commonly referenced in agile methodologies. Devote some time to explaining agile: how projects will be planned, how team members will deal with changes and how work is prioritized so they can focus on the more important items first.

Visit PMI’s Agile Toolbox to get training in agile techniques and to access books, papers and other materials.