Integrating Agile into a Waterfall World

Every project manager can successfully integrate agile in a waterfall environment to improve project predictability, cost effectiveness and ultimately success.

 Agile was once considered by project management professionals to be a fad. In the 10 years since the agile manifesto was written agile has matured; it has moved from being fringe to being a core methodology and from small software companies to the point where it is used, to some extent, in a majority of enterprise organizations today. Agile isn’t a silver bullet though and agile methods need to adapt to the changed context of the enterprise. The purpose of this paper is to examine how project managers can successfully apply agile to their projects in an enterprise context.

 I contend that agile is optimized for product management but can be used to effectively manage projects. There are, however, three keys that the project manager must use to successfully unlock the power of agile to improve project delivery. I discuss and dispel two myths in the common belief that a project is either agile or waterfall and review 4 models of increasing agility and how they apply to project managers and agile team lead roles specifically. Finally, a three layer mixed model is proposed for how you can use the understanding of project and product management combined with deliberate methodology selection to manage an agile project in a waterfall context. Project managers can be assured that there is a strong role for them on agile projects. Project managers are not only important but absolutely necessary for the success of large scale projects.

Introduction

This year the Agile Manifesto celebrates its 10 year anniversary. In that time agile has moved from relative obscurity in the world of project management to the main stream. In 2009 84% (Version One, 2009) of respondents to the Version One Agile Survey indicating they use agile to some degree. In 2010 that number jumped to 90% (Version One, 2010). Yet, for many enterprise executives, directors and managers agile is still confusing, obscure and not trusted.

Every project manager can successfully integrate agile values principles and practices in a waterfall environment to improve project predictability and ultimate success, by understanding and applying three key principles:

1. Agile is not made for projects as PMI defines projects
2. Sequential Planning to Agile is a continuum of steps not flipping a switch
3. Mixing agile and Waterfall methodologies

Before we go any farther let me set the context within which I base all of what you will read here. I define two types of businesses for the purposes of this section: software companies (Independent Software Vendors), and everyone else. The focus of this paper is the “everyone else” group.

Software companies are companies where software is the primary product or where it is the primary delivery method for the product. By this definition Microsoft and Adobe are software companies, but so are Amazon and eBay. Amazon and eBay are software companies because they use software as their primary vehicle to deliver their products or services. Contrast this with McDonald’s or Ikea. To be sure, McDonalds and Ikea use software but it is not their primary product or their product or service delivery. Yes they have websites but McDonalds does not sell hamburgers through the internet. And, while you may order products from Ikea’s website, their primary channel is their stores.

There is a third grey area company that we need to address as well. This is the company that has a foot in each camp. Banking and health insurance in the United States are both examples of this grey area company. Both banking and health insurance could be either a software company or a non-software company depending upon how they are structured. If the business is structured, horizontally, in a product or service based focus with lines of business and/or products driving the organizational structure, and software is the primary delivery method of that product or service, then it is a software company. If, on the other hand the company is structured vertically based on job function, for example Marketing, IT, and Product then it is not a software company. While this sounds convoluted in practice it is relatively easy to determine by simply examining some specific roles and their scope of authority. For example: if a company has a role of Product Owner, the person who is responsible for a given product or service, examine their scope of authority. Can this product owner make all decisions for the product: Marketing decisions, IT decisions, website UX decisions. If the Product owner has full control of the product and can make all decisions, from concept to customer, then it is an environment where agile will fit very naturally. If it is not then there will be some tradeoffs that will need to be made to be successful with agile. These non-software companies are the focus of this paper.

Agile Was Not Made for Projects as PMI Defines Projects

 According to The Project Management Institute:

A project is a temporary endeavor undertaken to create a unique product, service or result.

The term agile was coined at the February 2001 meeting of software developers at Snowbird Utah, USA. Prior to that it was just a collection of light weight process that were in reaction to the more common “heavyweight” (heavy handed) approaches common at the time (Hunt, 2010). This group created the Agile Manifesto (Beck, et al., 2001), which has the signpost of the start of agile as a movement. All of the men involved in the event were software developers of one sort or another. Their focus was on the creation of software products not on project management process. In my personal interviews (van Bennekum, Hunt, Cunningham, Schwaber, & Cockburn, 2010, 2011) I found that they were focused on a reaction to the failing of heavyweight processes to be adaptable for the dot.com speed of change. When developing for a software company, there is never a thought of the software being done, as in, no longer being developed. It is always being revised, refined or changed in some way, unlike a construction project or developing a new dishwasher design. Once a building is built or a dishwasher is designed and turned over to production the work on the project is done. You may do an interior improvement (TI) project or design a new version of the dishwasher. But the original one is done and the new one is a separate project.

This is in stark contrast to the ongoing nature of product management:

Product management is the discipline and business process governing a product from its inception to the market or customer delivery and service in order to generate the largest possible value to a business. (Ebert, 2009)

Product management is concerned with the life of the product; from conception, through development and eventually to discontinuation. A project is all about the creation of something but when the something is created the project is done. Projects are not concerned with the ongoing improvement or enhancement of a product over the entire lifecycle of that product. Product management is the sweet spot for agile. Take a moment and consider the language of agile. There are product owners, product backlogs, product visions, and product roadmaps, all product focused language. The agile practice of adapting to changing requirements is perfectly suited to product management as well. When you know you will have a second, third, or twentieth release it is easy to just add scope to the product backlog. You know you will get to that feature someday. Contrasted with a project where scope, schedule and budget are tightly managed because they are what define the end of the project.

Using agile for projects

This subtle difference is not widely understood. If you understand this simple difference you can apply agile to projects with success. If you do three things;

1. Know how project management and product management differ
2. Plan what you will do when you run into project/product management boundaries
3. Communicate with management at every step of the way

Projects manage the triple constraint; scope, schedule, and budget (Sometimes people throw quality and/or resources in there too). Product management is concerned about these things as well but they are more fluid concepts.

For example, budgets are a renewable resource (every year there is a new budget). Schedule is a perpetual timeline, and scope is an endless roadmap of features, releases and new products.

Exhibit 1

If we run out of money for development on a product, as long as that product is producing value to the customer and the company then it is likely that, next year there will be a new bucket of money for the product owner to spend implementing the features that didn’t get implemented last year. Not so for projects, when the money is gone it is gone. Similarly schedule for product management is more fluid than on projects. Projects are often concerned about making timelines. By this project managers mean, meeting their milestones and ending the project on time. Products are also concerned about making timelines, and about meeting their milestones but not about ending, because product development is more about enhancing the next version.

What to do

Knowing that project management and product management deal with the triple constraint differently, it is critically important that you plan what you will do when you are using agile to manage a project.

Here are some suggestions and tips from my personal experience. First, you need to determine what is really most important about your project. Is it scope that is most important? Is it schedule, or is it budget? This sounds easy but in real life it is often hard to make project sponsors commit to one thing. (A useful tool for identifying the key drivers is Rob Thomsett’s Sliders. Don’t let them tell you it is two. I worked on a federally mandated project in the USA for a health insurance company. And while the date for the project was dictated and people would stand on top of the table yelling that we cannot miss the dates, the fact is the project is only done when all of the scope is complete. If the date comes and goes and the scope is not complete, the project will be considered a failure, but it won’t be complete until the scope is completely implemented. When you know what is important you know what you need to manage. If you are, for example, doing a pure R&D project then the scope really isn’t the driving factor either the schedule or budget will be. If you are doing a project to implement a new website for upcoming holiday season, then schedule is of paramount importance. Once you know this you are more able to focus on what is really important. You should vary the amount of structure you use to manage based on importance.

You can still manage scope schedule and budget on an agile project. However, since there are these fundamental differences between how project management and product management handle these aspects, we need to plan carefully what we will do when these paradigms clash. Being prepared will make it easier to manage the objections when they come, and they will come.

Exhibit 2

Managing scope on an agile project is one of the most commonly misunderstood aspects of agile project management. Agile practitioners will tell you that in agile, scope can change at any time. And this is true. One of the four values in the agile manifesto is, “Responding to change over following a plan” (Beck, et al., 2001). Responding to the changes in requirements from customer and market demands is the number one reason organizations adopt agile (Version One, 2010). When using agile to manage a project you will want to define a project and a product backlog. Then have a discussion with your project sponsors before the project work begins, if possible, and again throughout the life of the project, about the difference between the two. The project backlog is the specific set of work that is required for the project. When that work is completed the project is completed. The product backlog is the rest of the features that someday may be part of the product, but are not considered part of the project. Be very clear with management what is in the project backlog vs. what is in the product backlog. And communicate that over and over again. When new features are identified, accept them happily; add them to the product backlog without objection. If the project leadership asks that they are included in the project, then use a change process to add them to the project. It may be as simple as an email approval but you need to get it in writing that the new feature is being added to the project and the subsequent impact that will have on the schedule and budget. This is not different than the traditional waterfall approach to managing scope, though likely it will be a leaner process.

One final word about scope management, is regarding product backlog reprioritization. It is possible that the product owner will want to reconfigure the product backlog, moving features in and/or out of the project and product backlogs. This is no different than managing new work as stated above. It is our job as project managers to make it clear the impact of the changes and to document them in as light weight of a process as possible. Note that it is NOT ok for the product owner to attempt to add or subtract work that is currently under development. This work has been selected by the product team. If a change to work in process is absolutely critical, (in Scrum) the iteration will be terminated and a new iteration planned. This encourages stability within the iteration by reducing “thrash”.

Schedule and budget are handled similarly. You need to set clear limits on what the project budget is and the ongoing product or operational budget is. What the project schedule is and the ongoing product lifecycle schedule is. Then you need to communicate these clearly and often so that before long it is clearly inscribed in the project sponsor’s minds the difference between the two and they become the champions of the project/product backlogs, schedules, and budgets.

Communicate

The third thing you need to do is to constantly communicate the boundary between the project and the product. Work closely with the product owner and make sure they clearly understand that boundary. Be very careful about your language, speak clearly about Projects vs Products. Keep a clean Product and Project backlog delineation. This really becomes where you as a project manager provide the most value. You help the company stay focused on the delivery of the project, within the context of the product.

The Agile/Waterfall Continuum

“Agile Vs. Waterfall – Which one is right?” I get notifications of new blog posts every day with this or similar titles. It is such an old worn out drum but people still beat on it. “Agile vs. waterfall” creates an either/or proposition. Placing agile and waterfall on the opposite sides of a fight, two methodologies locked in mortal combat where there can be only one winner. The vast majority of these articles intertwine the two issues at the core of the agile waterfall debate: iterative vs. linear planning and directive vs. interactive management. See (A tale of two teams, 2008) as an example.

Myth: Agile focuses on People / Traditional Project Management is Command and Control

After 6 years of working on increasingly complex consulting and system design projects I found myself managing the people doing the technical work more than actually designing networks myself. In 2000 a Cisco sales representative told me that what I was doing was actually project management. I passed my PMP exam in 2001, now an “official” project manager.

Through the following years, I managed dozens of projects large and small, always from a sequential methodology. The old adage applies, “when all you have is a hammer, everything looks like a nail.” Fortunately, the vast majority of my projects had been well suited to a sequential model. I was often responsible for the IT in new construction projects at the Fred Hutchinson Cancer Research Center in Seattle, Washington. These buildings had not only significant networking infrastructure and server requirements, they also included highly sensitive technical medical equipment that more often than not required my assistance in managing the installation. These projects were based around and driven by the construction schedule for the buildings, a very sequential process.

In 2005 the construction projects were slowing and I was starting to do more software projects. Unlike construction projects, software is largely intangible. Traditional project management has an unstated assumption that all along you can see something; The huge hole in the ground has been dug, the foundation is laid, steel girders are in place. Software is not that way. If managed sequentially there is nothing to show until the end. Then, hopefully, everything works together and you can launch. But if you have ever managed a software project that way, and I have, you know that it just doesn’t work.

After one particularly dismal project failure, I did an extensive research effort on trends in software project management I felt that a Scrum Master class would help me greatly. It just happened that Ken Schwaber (Schwaber, Scrum.org, 2010) was teaching in Seattle at that time. In the Scrum Master class I learned a radically different way of structuring software projects so that they were able to adapt to changes and so that they were able to show clear progress at all times, even with an intangible product like software. But the underlying philosophy is what I found most compelling.

Exhibit 3

I had always taken a servant leadership approach to managing projects. I am technical but I also know that people who devote themselves to the study of a particular database, network, or programming language know their business far better than I; they know what it takes to get the job done. My job as a project manager is to help them structure that knowledge in such a way that it can be managed and reported to their bosses and executives, to remove impediments and identify risks that may come up, so that they can be removed or mitigated. Always with the thought in mind that I want to do everything I can to help the technical people on the project to be free to do what they do best and not be bothered by the necessary, but obtrusive, elements of; budgets, status, and other project structures. Scrum shares this perspective. Concepts like “chickens” and “pigs” (Schwaber & Sutherland, 2010), Building projects around motivated individuals and trust them to get the job done, Self organizing teams, sustainable pace (Beck, et al., 2001), all show this relentless focus on people.

Myth: A project is either agile or waterfall. There is no middle ground.

Now that we have unwound the threads of management style and delivery methodology we can address Myth of methodology as a binary decision. Robert K. Wysocki defines five discrete models of project delivery. (Wysocki, 2009). Chris Ward and Leonardo Legorreta adapt Wysocki’s model (Legorreta, 2009).

Wysocki and Legorreta define five types of project management:

1. Waterfall
2. Iterative
3. Incremental
4. Adaptive
5. Exploratory

In my experience the Adaptive and Exploratory approaches are one in the same. Most Adaptive methodologies will allow changes in scope (adding storycards at any time to the backlog) and thus the distinction is merely academic in real life. Thus I have combined the two models, Adaptive and Exploratory, in this discussion into one called Agile.

Sequential - The sequential model is the traditional approach to small or medium project delivery. The project is defined and scoped, then planned out in in its entirety, built, tested and deployed. This model works well for: small or medium sized projects where the work can be effectively delivered all at once, where the requirements are very well known and are not subject to change, such as a government or industry regulatory requirement.

Incremental - The incremental model is simply the sequential delivery model for projects that can and / or should be delivered in phases or increments. Like the sequential model, the incremental model is scoped and planned up front and therefore best suited to projects with very well defined requirements that are not subject to change. At each increment the teams may choose to adapt how they are working to deliver the requirements but the what and why are unquestioned.

Iterative - The iterative model diverges from the upfront planning approach of the sequential and incremental models. Most iterative models are really iterative and incremental. Under the iterative model detailed planning is done iteratively as the project progresses. Very high level planning is completed for the entire project but it is superficial and subject to change. Detailed planning is only done for the work directly at hand. Often this is in short time boxes from 1 week to 1 month. The remaining scope is not planned in detail but left for a later date. By delaying planning the iterative model takes the incremental model and accelerates delivery by borrowing from the Lean concepts of: making decisions as late as possible, and working toward flow (Womak & Jones, 1996). At this level of increasing agility the team asks for input from the project sponsors and / or the customers. At each iteration the team may choose to adapt how they are working to deliver the requirements. Additionally the what may be called into question by the sponsors or customers. Work may be reprioritized based on the input from the sponsors and / or customers to deliver the more important features first. But all the features are required (due to regulatory or compliance) and will eventually be delivered.

Agile - The agile model adds the ability to add or remove scope at the beginning of each iteration. In agile projects feedback is sought to ensure the order of feature delivery so that the product being delivered is delivering the features of highest value and delivering them in a way that the customer is receiving the highest benefit. Additionally, any new ideas that the product owner or customer has come up with are able to be added to the backlog. The effect of seeing the working software is like in Heisenberg’s uncertainty principle, where the act of measuring affects the measurement (Cassidy, 2002), so too the act of seeing the working software affects the desired features and requirements, spawning new and often better ideas (Barry Boehm has an acronym: IKIWISI – stands for I don’t know what I want but “I’ll Know It When I See It”). Agile is best suited to projects where the problem is complex and may not even be fully understood At the beginning of the process, in these cases, the solutions are even less understood and thus a very nimble process is needed.

If you understand that the journey from waterfall to agile is a continuum you will be much more successful in delivering agile projects, in communicating with both your agile and waterfall peers, and in communicating the value and reason for using your approach to managing your work.

Mixing Agile and Waterfall Methodologies

In this section we will look at how you can use the understanding of Project & Product management combined with deliberate methodology selection to manage an agile project in a waterfall context.

It is not unusual to find iterative or agile projects in an Enterprise organization that must survive in a mixed environment with Waterfall. Maybe your department is moving to agile but the rest of the company is not. While it seems like the two would not mix well, in practice it really isn’t that hard to create a workable model. Understanding which management model you are actually using as your primary delivery model (Iterative or Agile) will help in developing a clear communication plan for your waterfall project team members and partners.

Exhibit 4 The Envelope Method

When interfacing with departments or divisions that are not practicing iterative or agile delivery it is important to communicate clearly about your processes and procedures and your expectations from the waterfall team as well as what they can expect from you.

In these situations I use an approach I call “The Envelope Method” (See Exhibit 3). The Envelope method is a framework for mixing agile and waterfall in the same project. This method consists of a series of successive layers or envelopes which are used to insulate the others from the other layers.

Using this approach the Project Manager is responsible for keeping the agile team protected, particularly during the iteration. Nothing should interfere with the team’s delivery of working software by the end of the iteration. The project owner may change the backlog, the platform services group may make modifications to the environments. But every effort should be taken by the project manager(s) to protect the team so they can do what they do best without interruption.

Envelope 1

The inmost Envelope is where the agile team works to execute the; software development, unit testing, component testing, integration testing and defect resolution. The Agile Team Lead (in Scrum the Scrum Master, or Iteration Manager) is the first line of issue resolution. The Agile Team Lead is responsible for intra-team communication, for coaching the development team, for helping prioritize work when the team is stuck. Generally the Agile Team Lead is responsible for the health and wellbeing of the agile team. Impediments that the Agile Team Lead cannot resolve for the team are escalated to the Project Manager. The Project Manager also acts as a protector for the team keeping the complexities of the outside organization from impeding their progress. To accomplish this delicate balance the Agile Team Lead and the Project Manager need to have a very good working relationship. If the project is relatively small the Agile Team Lead and the Project Manager may be the same person. I try to avoid this if I can because I find that the Agile Team lead is a critical role that should stand alone. It can be a part-time role with other responsibilities on the team, but ideally not the PM

On multi-team projects, the Agile Team Lead and the Project Manager work together to coordinate across the teams through a number of forums:

1. Joint Iteration planning
2. Iteration Coordination
3. Joint Iteration Demos
4. Joint Retrospectives

Joint Iteration planning – Iteration planning should be done as a unified team on the same day, in the same room if possible. As of this writing I am facilitating iteration planning sessions with over 100 participants, including sponsors and external (waterfall) members, on 4 agile teams. Every other 2 week iteration, the entire team travels (many are remote), to meet for the joint iteration planning session. The event takes 8 hours. The first 2 hours are spent as a large group. Each project team shares the selected “Theme” of their sprint and the goals associated with that theme. They also discuss any cross team dependencies they have already identified. The other teams are free to ask questions of the presenting team to identify any potential cross team dependencies including resources or people. After all the teams have shared and the cross team dependencies have been identified, the group breaks into their individual teams, still within the same room. Each team has a projector and on the odd weeks when people are off site, each team has a conference phone. The teams then proceed to break down the work they have selected for the iteration. This is a noisy and highly collaborative process with some people, who are shared across teams due to specialized skill sets, bouncing between teams. Additionally when a team comes to task out a cross team dependent piece of work, they call upon the other teams and work collaboratively to plan how they will address the work. At the end of the day the teams come back together and commit to one another for the iteration. Last but not least, a brief retrospective of the day is held to identify any areas for improvement for next time.

Iteration Coordination - Within the iteration the Agile Team Leads and the Project Manager(s) will encounter any number of issues that require cross team coordination. To facilitate this I encourage the teams to talk at the iteration planning session to determine those teams with which they have the greatest need for interaction, it may be due to shared people or resources (such as servers, shared web-services, or other technical resources). Agile Team leads are encouraged to attend the other teams key iteration team meetings (daily standup meetings, Peer reviews, etc…) additionally the Project Managers and Agile Team Leads come together daily to discuss the identified cross project dependencies and any new items that the Agile Team Leads may have heard from their attendance at the key team meetings. Project Manager(s) attend this meeting to listen to the cross team dependencies and determine if they are needed in any way to facilitate the resolution of issues.

Joint Iteration Demos - At the end of each iteration the working software is demonstrated to the project sponsors. This demo is done as a joint team. Where it makes sense the demo should follow the workflow that the customer would follow if they were using the systems in production. If elements from one team flow logically to the next team this logical progression should determine the flow of the iteration demo. It is important that the whole team attend the entire demo, because work from the teams is shared success, and besides it is just good manners. Demos should be a time to celebrate the successes of the iteration and acknowledge the work of your peers. In the iteration demo the Project Manager’s primary responsibility is to facilitate smooth flow of the event. This is a time for the Project Manager to be an example of servant leadership; if the projector isn’t working, if there is a problem with the conference phone, the Project Manager should work to resolve the issue so that the team can be focused on demonstrating their work to the sponsors.

Joint Retrospectives - After the iteration each team should review their processes and work on improvement. In this scenario the project manager and the Agile Team Lead can share responsibility for facilitation. I find that it is often helpful for the Agile Team Lead to be the lead facilitator because they will be primarily responsible for helping the team implement the improvements in the next iteration. In addition to the individual team retrospectives the whole team should participate in a joint retrospective. This may not need to be held each iteration but I recommend that it be done every other iteration at least. Joint retrospectives focus on the inter-team collaboration and improvements that the teams can make to improve the working environment, the team velocity, communication and collaboration.

Envelopes 2 and 3

Predictive elements lie at the second and third layers of the envelope framework. The second layer is where the waterfall elements of the project are planned and managed. These elements could be anything but one prime example is hardware delivery. The third envelope is where the project interfaces with the rest of the enterprise portfolio. At this layer the project manager coordinates with external projects, with the enterprise release planning and enterprise reporting.

Envelope 2 Predictive Elements

The Predictive elements envelope holds the direct project work that is not managed in agile model. A perfect example of this is the acquisition of new hardware for the project. It is not reasonable to expect that new hardware can be ordered at the beginning of an iteration and be installed during that iteration, especially if the iteration is very short, such as 1-2 weeks. Hardware lead times measured in months are not unusual. It would be unprofessional of the Project Manager to not make adequate plans for procurement and implementation of required hardware, the predicative element envelope provides a framework for managing this work. When the team is doing the high level initial planning the iterations should be laid out with expected or anticipated needs for predictive elements. Additionally enterprise testing is at this level if it is managed in a sequential model. Some organizations may be able to manage enterprise testing iteratively but if coordinated with an Enterprise Release Board for managing the entire corporate release schedule it is likely that this level of testing will be in the second envelope. However, if the team has been delivering iteratively and performing their unit/component and integration testing iteratively, demonstrating the working software to the end user, it is very likely that the enterprise testing will be executed much more rapidly. I have seen User Acceptance Testing at an enterprise level that typically was given six weeks, take 20 minutes.

Envelope 3 Enterprise Integration

The third envelope is where the project interfaces with the rest of the corporate project portfolio and with the project sponsors, steering committee, and executives. In this level of the framework the project manager is responsible for Program Management and working to resolve program and portfolio level issues. With the goal of keeping the agile team completely oblivious to any of it. For example, the project manager is accountable for working with the managers to identify and resolve portfolio and program issues. When addressing cross project dependencies, it may be necessary to work with the Agile Team Lead to define the dependency and articulate the impacts, however it is important to never let this impact the working agile team. If it becomes necessary to involve the agile team it is advisable to wait until the iteration planning so that the team can focus on execution.

This is the level at which the Project Manager will report project status to enterprise portfolio management. The Project Manager needs to act as a translator, converting the agile metrics into the accepted reporting structure of the enterprise. The focus in agile on complete and fearless transparency makes it easy for the Project Manager to obtain the ready information for whatever reporting structure is required, including Earned Value (Suliaman, 2007) (Rusk, 2009). It may happen that as agile projects continue to execute for the organization with increasing success the enterprise will begin to modify the reporting structure to include some agile elements. Whatever the case may be the Project Manager will be required to clearly report the project health to the enterprise. These same reports may be used to report to management and steering committees. It is at this level that the Project Manger works with the project sponsors to manage the project and product relationship and works to ensure that the project scope, schedule and budget are managed.

Lastly the third envelope is where the project deliverables are deployed into the enterprise production system. This is likely the trickiest part of coordinating an agile project as the goal is to limit the impact upon the working agile team. The Project Manager and the Agile Team Lead should work together to plan for the release. The ultimate goal of an agile team is to make deployment seamless so that it has little or no impact on the working team. It is likely, however, that the project team will have to devote some portion of their iteration to the planning, deployment and checkout of the release. If possible a single person should be assigned this responsibility with the remaining team allocating a small portion of reserve time (reducing their time available) for the iteration so that any defects can be resolved swiftly.

Conclusion

Agile in mixed waterfall/agile environments is complex. It is imperative that Project Managers keep a strict eye on the difference between the product requirements and the project requirements, managing the project to the scope schedule or budget as mandated by the project sponsorship. The Project manager can use the Envelope method to maintain the relationship between the agile working team, the non-agile elements of the project and the rest of the enterprise.

I am often asked about the role of the Project Manager in an agile environment. The fear is that the role will not be needed. Project Managers are not needed on small agile projects in simple business contexts, such as small and some medium sized businesses. Project Managers who feel the need to direct the work of the project team have no role on an agile project. Project Managers with a servant’s heart, who are willing to step up to the challenge of working on larger projects, have more than a role on agile projects. They are absolutely necessary for success.

About the Author

Joseph Flahiff is a popular speaker and project delivery consultant who facilitates enterprise organizations improve their project delivery through a combination of agile, lean and newly emerging project management methods. An experienced professional with more than 15 years in agile and traditional project management, Joseph lectures internationally on agile and waterfall integration. Video, posts and free resources about current trends in enterprise agile project management may be found at his Whitewater Projects blog.

Reference

• A tale of two teams. (2008, April 25). Retrieved January 29, 2011, from Youtube.com
• Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001, 2 11=13). The Agile Manifesto. Retrieved 1 21, 2011, from agilemanifesto.org
• Cassidy, D. (2002, 5). Quantum Mechanics: 1925-1927 THE UNCERTANTY PRINCIPLE. Retrieved January 20, 2011, from American Institute of Physics
• Ebert, D. C. (2009). Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 15-19.
• Hunt, A. (2010, September). The Agile Manifesto a decade later. (J. Flahiff, Interviewer)
• Legorreta, C. W. (2009, April 2). Beyond waterfall and agile methods:Towards a new contingency model for IT Project Management. Retrieved January 30, 2011, from Social Science Research Network
• Rusk, J. (2009). Earned Value for Agile Development. Retrieved January 30, 2011, from agilekiwi.com
• Schwaber, K. (2010). Scrum.org. Retrieved January 30, 2011, from Scurm.org
• Schwaber, K., & Sutherland, J. (2010). Scrum Guide. In K. Schwaber, & J. Sutherland, Scrum Guide (p. 5). scrum.org.
• Suliaman, T. (2007, October 5). AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. Retrieved January 30, 2011, from InfoQ
• van Bennekum, A., Hunt, A., Cunningham, W., Schwaber, K., & Cockburn, A. (2010, 2011). Whitewater Projects Podcasts. (J. Flahiff, Interviewer)
• Version One. (2009). 2009 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com
• Version One. (2010). 2010 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com
• Wikipedia. (2011, 1 5). Product management. Retrieved 1 21, 2011, from wikipedia.com
• Womak, J. P., & Jones, D. T. (1996). Lean Thinking. Simon & Schuster.
• Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme, 5th Edition. John Wiley & Sons.