Agile has inexorably changed the project management landscape. That's largely due to its adaptability: Iterative development allows teams to deliver functional pieces of a project quickly and adjust on the fly.
Now project managers are taking adaptability to the next level, blending methodologies to make new agile hybrids.
“I don't believe that agile or Scrum is always the right choice,” says Børge Haugset, research scientist at SINTEF ICT, a research organization in Trondheim, Norway. “Quite the opposite: When highly skilled teams can pick and choose the tools and rules that work for them, they can hit gold.”
To break out of the typical agile framework, teams can use workflow boards from lean manufacturing process Kanban or task backlogs borrowed from Scrum. And more often than not, that combination includes traditional practices such as those in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), says Mike Cottmeyer, founder and president of LeadingAgile, an agile consultancy in Atlanta, Georgia, USA.
Even though an agile hybrid model may not have the fine-grained project plans of a traditional waterfall environment, teams still need to meet schedule, budget and ROI expectations.
“That's where the PMBOK® Guide comes in,” Mr. Cottmeyer says, drawing parallels between rolling-wave planning and project roadmaps. “You don't know what you need until you need it. But the further out you plan, the more abstract you have to be. It's thinking about traditional project portfolio management in smaller increments.”
Raya, an IT company in Cairo, Egypt, is a hybrid convert. The company realized its waterfall approach wasn't allowing its teams to consistently deliver projects with the expected quality and timeliness. So it implemented agile, and the transition went well—at first, says Ali Zewail, general manager of software development and technology services at Raya. His team launched two major software development projects as agile pilots. Both met budget goals, one came in ahead of the deadline, and customers were pleased with the results.
But the next projects didn't deliver the same stellar results, and the novelty of the new approach started to wear off.
“There was a real learning curve that we had to accept,” Mr. Zewail admits. “We had to change our mindset and our corporate culture if we were going to really be agile for the long term.”
If you're looking for a way to showcase your agile knowledge, earn the new PMI Agile Certified Practitioner (PMI-ACP)SM certification. Find out more at PMI.org/agile.
Of 4,770 respondents from 91 countries, 90 percent said they use some form of agile.
Only 27 percent of respondents solely use one type of agile, while 35 percent mix agile with waterfall, and 39 percent mix agile with Scrum.
Source: Analysis.Net and VersionOne
Project leaders opted for a hybrid approach, applying strategies from the PMBOK® Guide to the company's agile formula. Teams began using audits and lessons learned, and established measures of project success to create accountability and ensure that teams were adopting the same techniques across the enterprise.
NO LONGER BURIED IN PAPERWORK
One of agile's basic tenets is to require less documentation and fewer defined specifications at the front end of the project, instead of relying upon constant tweaking throughout the life cycle. The goal is to free project team members from the need to document everything so they can focus on quickly producing high-quality deliverables.
“Too much focus on documentation can be difficult to maintain, especially if documentation is seen as an ‘extra chore’ by many agile developers,” Mr. Haugset says. “On the other hand, too little documentation makes the project more difficult to understand, especially if key components are undocumented.”
Adopting an agile hybrid lets teams adapt the documentation processes as the project progresses. At the outset, when ideas are broadly defined and changes anticipated, less documentation is required. But as iterations are completed and reviewed with the client, the scope narrows and the need for documentation is more evident.
Mr. Haugset uses traditional quality-assurance tests to help shape the documentation process to ensure problems don't go unnoticed and that the project remains strategically aligned to organizational goals. These tests are conducted during reviews to evaluate the inputs, functionality and expected outputs of each iteration.
Show off your agile expertise: Join the conversation at the PMI Agile Community of Practice at agile.vc.pmi.org.
TRANSITION TIPS
My project team is in the planning stages of transitioning to an agile environment from a more traditional, waterfall-style environment. Recognizing that becoming agile is more of a paradigm shift than a simple implementation of a collection of processes, we are developing a strategy document that lays out the progression from current state to desired future state.
Accordingly, I'm curious as to whether anyone has experience driving the transformation to agile, and if any light can be shed on the timing and sequence of applicable implementation activities. Additionally, any insight into change management frameworks that have helped to facilitate this change would be very much appreciated!
—Matt Lee
I'D suggest taking an agile approach to the transition. You should expect your desired future state definition to change as you gain experience and use retrospectives to figure out what works for your workplace. Keep your strategy document simple, with a focus on what you want to achieve by transitioning to agile.
Our reason to experiment with agile was to resolve ongoing issues with our projects. After the first pilot projects, it was easy to say that an agile approach was addressing these issues and therefore providing real value. When the value is visible and tangible, it is easy to get buy-in to continue the rollout.
For timing, I suggest getting just enough training to get a pilot project team going as soon as you can. That team will give you feedback as to how to proceed.
We've always treated our waterfall-ish project framework with a “do what makes sense for your project” attitude. We are doing the same with agile. I'm on our agile core team. We developed and present our in-house agile training and are assigned as agile coaches as needed. We facilitate sharing knowledge, experience and lessons learned across the project teams. The practice of frequent feedback through retrospectives is a valuable benefit of agile. Use it to tune your processes.
—Rebecca Jahelka
What do you suggest?
Weigh in at the PMI Agile Community of Practice: agile.vc.pmi.org.
“The tests act as mediators to enhance communication between the client and the team, and to help us jointly define when something is done, meaning the team has made something that runs in a way that the customer understands and agrees upon.”
Every time the team completes a sprint, a test is conducted, and the results are added to a database. “It acts as a safety harness to ensure the code is correct,” Mr. Haugset says.
WINNING MINDS
Whatever combination of techniques a project team uses, one constant remains when any element of agile is introduced: Team members must be self-directed, focused, strong communicators and able to make quick decisions.
“The core of the agile philosophy is that people need to talk to each other and work together,” Mr. Haugset says. “That requires a lot of trust among the team and an unbelievable amount of customer cooperation.”
It also requires more talent and experience than might be necessary in a waterfall environment, where higher-level designers can leave the actual coding to those with less experience. “If you have a detailed spec with clear requirements defined at the beginning of a project, it is simple for any developer to create,” he says. “But when you incorporate agile techniques, you shift a lot more responsibility to the team members, so you need them to be able to make the right choices. To do that, they need to be skilled.”
Adopting agile in any form also often takes a radical change in attitude—and not just among team members.
“Sometimes the biggest hurdles are political,” warns Richard Banfield, CEO of Fresh Tilled Soil, a user experience and interface design firm in Boston, Massachusetts, USA.
Project leaders must devote time to change management, including educating stakeholders. If they don't understand the rapid pace of iterative deliverables, and when and how they will be required to deliver feedback, stakeholders can logjam the process.
Mr. Banfield's team learned that lesson last year when it started to rebuild the foundation application for Communispace, a social marketing and research platform, using a purely agile process.
The project team delivered frequent iterations that required a steady stream of stakeholder feedback. But the client required more time to respond because of the number of stakeholders.
The project team adapted, slowing its sprints from two weeks to four to get the client's leadership team accustomed to the process.
“As they got more comfortable, we were able to speed things back up,” Mr. Banfield says.
To avoid such delays, he now begins many projects with an educational phase for leadership teams. “We have to be sensitive to the client structure and customer satisfaction,” Mr. Ban-field says.
It takes time to adapt—and a hybrid approach can work as a stepping stone.
“Project managers and developers need to understand that agile isn't a set of unbreakable laws,” Mr. Banfield says. “It's about using what works and recognizing that there will always be exceptions.”
Because in the end, being able to adapt is the essence of any agile process. PM
TOO MUCH FOCUS ON DOCUMENTATION CAN BE DIFFICULT TO MAINTAIN, ESPECIALLY IF DOCUMENTATION IS SEEN AS AN ‘EXTRA CHORE’ BY MANY AGILE DEVELOPERS.
— Børge Haugset, SINTEF ICT, Trondheim, Norway
