Abstract
The Agile approach to project management began as a response to struggles that were being encountered in software development projects following more traditional project approaches. While traditional approaches were effective in many areas such as construction, they were less effective in software development. As Agile gains popularity, more project managers trained in the traditional approaches are starting to use Agile techniques. This paper provides some experiences of project managers that have transitioned from traditional to Agile and provides some advice to other project managers considering the use of Agile. The paper is formatted as a series of questions relating Agile and traditional project management with consolidated responses from the authors. The authors hope to show that adopting Agile is a beneficial and rewarding experience.
Introduction
Agile project management is an iterative, incremental approach originally developed for software development. The approach is based on a number of short iterations in which small portions of the overall solution are fully developed, including designing, building, and testing. During initial planning, the team determines the number of iterations necessary for delivering the solution being requested. A list of prioritized features, referred to as the product backlog in Scrum, is used to determine the work that is to be performed in each iteration. The iteration starts with a planning meeting to further define the scope for that iteration based on the specific items selected from the product backlog. In Scrum, this subset is referred to as the sprint backlog. The team also conducts daily meetings to plan the work for the day.
Scrum (Exhibit 1) is a specific approach to Agile project management, originally developed in the mid-1990s. According to the third annual survey on Agile project management, The State of Agile Development, conducted by Version One in 2008, Scrum is the most widely used form of Agile. As the name would imply to sports fans, Scrum uses the analogy of the sport of rugby, including its terminology. For example, iterations are called sprints and the daily stand up meeting is referred to as the daily scrum. Additional details on Scrum can be found in Agile Software Development with SCRUM, by Ken Schwaber and Mike Beedle.
While the authors of this paper are practitioners of Scrum, they are not official representatives of the Scrum Alliance, and all opinions expressed here are their personal opinions. The authors are active in both PMI and the Scrum Alliance to varying degrees.
Exhibit 1–Scrum Overview
Source: Adapted from Agile Software Devlopment with Scrum by ken Schwaber and Mike Beedle.
Questions and Answers
The remainder of this paper is composed of questions that the authors typically receive when discussing Agile project management, and their answers. Since each author has had different experiences, the opinions are not always in complete alignment. The intent of this paper is to share these experiences and allow the reader to determine how they can be applied to the reader's work environment.
What do you see as the key differentiators between an Agile approach and more traditional “waterfall” methodologies?
Two of the most significant differences between the PMBOK® Guide-centric approach and an Agile approach are the way in which the frameworks are approached and the attitudes people bring to them.
The PMBOK® Guide is designed to include far more than what might be necessarily applicable on any given project. With that in mind, Project Management Professionals (PMPs) are taught to look at the standard as a large set of tools from which they should pick and choose the components that will best serve them on their project and leave the rest. In short, they get to select the rules they will introduce to achieve the benefits that the approach has to offer.
When applying Agile methodologies, that approach can be a death sentence. With Scrum, for example, the process is designed to be very lightweight and economical. There are not too many rules, but if you do not exact the discipline to introduce them all, and follow them as defined, things can easily slip into a semi-Agile approach, where the benefits cannot be realized because the implementation has been less than complete. One author's earliest experiences in working on eXtreme Programming (XP) projects went very badly simply because the team was not instilled with the discipline to follow all the rules. It became an excuse to ignore a lot of what needed to be done.
Trying to implement everything in the PMBOK® Guide is as deadly to a project as only applying a portion of the Agile practices called for by a particular framework.
The second significant difference is in the culture that is created (speaking generally) by a waterfall-minded project manager as opposed to an Agile project manager. With waterfall projects, the complaint always seems to revolve around the burden of the administrative portion of the project or the ways in which applying the process can weigh down the ability to just get things done.
With Agile projects, the complaints tend to stem from a perceived lack of documentation, which leads to a perceived lack of traceability and accountability. In both cases, this most likely stems from a lack of understanding of how things are designed to work and what benefits they can provide. In either case, the guiding principal should always be, bring with you whatever it takes to drive the project forward, and no more. Unless you are working in an organization that requires you to adhere to a specific process for regulatory reasons, the focus for both needs to be on the deliverable and getting to the deadline. The process should always help, never hinder.
There is also a difference between process and principles. Traditionally, we're trained that if a standardized suite of formal processes is in place, and the team adheres to those processes, then a project will succeed. The Agile school of thought, however, is based on four key principles that can be implemented in any project environment, regardless of the methodology. Those principles are that (1) people matter more than process, (2) deliverables matter more than documentation, (3) collaboration matters more than contracts, and (4) planning matters more than any given plan. Too often we turn immediately to the controls of process, documentation, contracts, and static plans and lose sight of the true value producers, which are our people, deliverables, collaborations, and planning efforts. Although Agile preserves a project team's discretion to use those controls, it encourages a greater focus on the true value producers.
Can the two approaches be used together successfully, or does the blending corrupt the value that each provides on its own?
The blending of both can be incredibly beneficial. One of the authors has been able to use Scrum and the PMBOK® Guide together to design an approach for a number of clients that creates a protective bubble around the development team, enabling them to spend the maximum amount of time focusing on getting code done. This tailored approach takes the output of the Scrum process and converts it into a format that can be digested by the more traditional-minded senior management. In addition, while use cases are what the developers may need to get their side of the work done, it is not always the ideal way to capture requirements meant to outlast the life of the project. For this, a more PMBOK® Guide-centered approach may be appropriate. However, rather than create a full requirements document, or a full project plan, the use cases could become the start of a wiki that would be maintained by the client after the project team has departed. It meets the stated needs of a conventional requirements document, but is developed in a more organic way than the proverbial documents that sit in binders gathering dust on a shelf. It also places the responsibility of the upkeep of the requirements back in the hands of the client. The requirements are built as a deliverable of the project and handed off, just as the code, to the client, who is then responsible for keeping them current.
For a project manager learning about Agile, is there any one flavor to really focus on?
For project managers learning about the job, the best place to start is with Scrum. Although Scrum is only one of many Agile approaches, there are somewhat more training resources for it than for any of its contemporary alternatives. The Scrum Alliance offers a very popular certification program that has produced many certified trainers around the world. While there is much to learn from other Agile methods, Scrum is easily the best place to start learning about the principles that set Agile part.
How does the role that project managers play change when they move toward an Agile approach? How does the role of Stakeholders change?
The mindset more than the role is what changes for a project manager. With a traditional approach, many project managers often take on a more authoritarian approach. In contrast, an Agile approach is more centered on leading from within. You are an integral part of the process. In both cases, the role requires that you remove any and all obstacles in the path of the team, communicate with management, and try to shield the team from any outside influence that has the potential to negatively impact the team. However, on Agile projects, project managers might find that more time is spent re-selling the process to the folks on the client side if they are unfamiliar with the approach. When one is accustomed to a Gantt chart, it is not always easy to maintain focus on an unconventional approach for the time necessary to see the benefits.
In some organizations it is not uncommon to split up the role of project manager into two major project management activities: the delivery team lead and the project champion. In the case of a mid-size project with fewer complexities, the delivery team lead may be sufficient. This role is explored in great detail with the Scrum methodology's ScrumMaster role. On a larger, more complex project, the additional role of a project champion becomes critical. This role is the one of managing the stakeholders, the business requirements, and the product demonstrations. The amount of interaction with the business increases significantly, and therefore this role requires full-time dedication. The people in this role are required to understand the business value expected, and so end up doing a lot of high-level business analysis, working with business analysts, building use-cases, and negotiating with the business users and sponsors.
In either of these roles, one of the main issues we find with transforming traditional project managers to Agilists is the mind-shift required—from meeting the requirements that were scoped upfront to applying the type of discipline needed to deal with Agile project requirements that are in constant flux. They need to constantly revaluate the relative business value and work together with stakeholders to realign priorities for the next sprint.
Because of this practice, there is a greater involvement of senior-level sponsors. These sponsors will need to transition to a perspective that not everything they asked for will in fact make into the final solution. Priorities will shift, iteration after iteration, and the team is trying to implement the most valuable use cases or user stories first. For example, during the regularly occurring demonstrations, it is typical to find that many new “must-have” ideas will come up, as well as highly valuable new features, which get added to the project. In this case, the less valuable features are dropped and are no longer in the project, as they do not fit in the budget. This therefore requires a change in the attitude of the stakeholders and sponsors to trust that the delivery team will deliver, in a reasonable timeframe, the features that have been reprioritized. This is a fundamental change that we often find to be the most difficult to achieve, a change that fundamentally comes down to collaboration and trust.
The traditional approach has consisted of typing up a large requirements document, handing it off to the project team, and confidently assuming that the sponsor's job is done. An Agile approach requires that the sponsor designate a full-time liaison to the project team. The project team needs that liaison every day, to answer questions about detailed requirements, to set priorities, and to communicate risks back to the sponsor. That liaison needs to have the right kind of domain knowledge, the accessibility, and the authority to answer questions about the project's overall direction. An Agile project will simply not succeed with a sponsor who is not engaged.
As previously discussed, this shift means we have two project management roles, with neither owning the complete project. However, they must work in sync to be able to deliver a solution that makes sense.
What are some of the most common mistakes that project managers who are new to an Agile approach make, and how can these mistakes be avoided?
Probably the easiest mistake is to implement Agile simply as a new set of practices. Most traditional project managers have been trained to follow a rigid set of defined processes. The defined processes are intended to guide us toward lower risk and more successful execution. Agile however, dispenses with the assumption that present challenges are best addressed by duplicating previous success. Instead, project leaders are given a set of tools to identify risks and priorities specific to the current project. Team members are then authorized to leverage their skills to address those risks and priorities the way that seems best to them. Before, we were told to use process to avoid or work around risks, inefficiencies, or dysfunction. With Agile, we are encouraged to use process to identify, escalate, and attack those issues head on. That will in turn require a project manager's most common phrase to change from “no problem” to “we have a new problem.”
Project managers new to Agile may be surprised at the ongoing negotiation process required to deal with an ever-evolving scope. At the end of each iteration there is a demonstration session with the business stakeholders. In the first demonstrations for any project, it is normal that a lot of new features, previously not detected, surface as must-haves and need to be incorporated into the scope. This forces the project manager to negotiate what needs to come out from the scope to accommodate the new requirements. If the project manager is not accustomed to such negotiations, they may be inclined either to delay a prioritization discussion with the stakeholder, or will say “no” to everything. Another common, inadequate behavior seen in project managers coming to Agile is being reactive. It is holding on to the assumption that defining the most valuable solution is the responsibility of whoever defined the initial scope requirements. Often, a project manager chooses not to realize that the scope is evolving, they are part of the final solution, and they need to be driving toward higher value, higher adoption, and probably a smaller solution to address business issues. This is different from a project manager working on a typical waterfall project, where a business analyst is responsible for the requirements.
When is it time for experienced project managers to consider learning more about alternative approaches to their work?
One of the most important skills the project manager can bring to any environment is tailoring. No methodology fits every project. Every environment is different, and so every environment will require the application of a blend of techniques, skills, and knowledge. To navigate the issues of a specific project environment, practitioners should have a broad set of tools at their disposal. One should never think they have learned enough. The best project managers are vigilant about acquiring as many tools as possible.
What advice can you give to project managers who are dealing with budgetary concerns and trying to implement Agile? And how do you sell it to cost-conscious senior executives?
Only sell what you can sell right now. Instead of asking to bring a globally distributed project team into a single location (which would be very expensive), start by suggesting the highest priority requirements be implemented first. Instead of asking that a full-time QA resource be dedicated to the team right away, ask the team what would help them generate fewer defects, and then equip them. Meanwhile, as you're implementing the small improvements, begin measuring the added value delivery. And when you gain enough momentum and are able to show an upward trend in value delivery, executives will be much more inclined to listen to your next request.
However, this approach does have its risks. As mentioned above, implementing a partial solution may cause its own set of problems. The ideal situation would be to implement an Agile approach within a small team and prove the success without significant costs. At this point, selling the value becomes an easier task.
You are each leaders in your work environments. You have significant experience in the traditional approach, and you have opted to tread down a path that often engenders a critical response, from either side. Is life better now, or do you wish you could go back to the old way of doing things?
Learning about Agile, Lean, Six Sigma, and other modern project methods has been liberating to project managers who have taken this course. These project managers become less concerned about making projects look “on track.” They don't have to feel guilty if metrics are off. Instead, they are more confident managing a project by its highest risks and highest priorities. There is less pressure to adopt all the processes: the project manager only needs to adopt the processes, techniques, and tools that are most immediately needed. By supporting the project team's work and setting stakeholder expectations, Agile project managers are adding much more value then when they simply adhered to a process.
Having experience in both the waterfall and Agile approaches unquestionably makes any project manager stronger, and benefits clients and internal stakeholders. The landscape of information technology is in a constant state of flux today, and thus requires more than just the tools of one side or the other. By being able to apply the best tools necessary to get the work done on any given project, a versatile project manager can better serve the project. Project managers of the future are going to need access to the benefits of the discipline of the traditional approach and the flexibility of an Agile approach. It has been compared to being able to play both classical and jazz: you'll get a lot more gigs, and keep the audience happier if you can make the transition from Mozart to Coltrane when you need to.
