Integrating agile in 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 a 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 four 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.
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 indicated 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:
- Agile is not made for projects as PMI defines projects
- Sequential planning to agile is a continuum of steps, not flipping a switch
- Mixing agile and waterfall methodologies
Before we go any further, 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, McDonald’s and IKEA use software, but it is not their primary product or their product or service delivery. Yes, they have websites, but McDonald’s does not sell hamburgers through the Internet, and, although you may order products from IKEA’s website, their primary channel is their stores.
There is a third gray area company, which 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 a gray area company. Both banking and health insurance could be either a software company or a non-software company, depending on 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. Although 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, examines their scope of authority. Can this product owner make all decisions for the product: Marketing decisions, IT decisions, and 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 in 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 Project Management Institute:
“A project is a temporary endeavor undertaken to create a unique product, service or result.” (PMI, 2008, p5)
The term agile was coined at the February 2001 meeting of software developers in Snowbird, Utah, USA. Prior to that it was just a collection of light-weight processes 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, et al. 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 cycle 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 life cycle 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 some day. Contrasted with a project in which 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 these three things:
- Know how project management and product management differ
- Plan what you will do when you run into project/product management boundaries
- 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). (Exhibit 1) 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.
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, the 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 (Thomsett, 2002). Don’t let them tell you it is two. I worked on a federally mandated project in the United States for a health insurance company. And, although 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 was only done when all of the scope was 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 the upcoming holiday season, then the 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, because there are 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.
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 (Exhibit 2). Then have a discussion with your project sponsors before the project work begins, if possible, and again throughout the life cycle 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 some day 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 versus 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 be 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 it will have on the schedule and budget. This is no different than the traditional waterfall approach to managing scope, although it will likely 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 what the impact of the changes will be and to document them in as lightweight of a process as possible. Note that it is NOT okay 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, as well as what the project schedule is and the ongoing product life cycle 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 differences between the two and they become the champions of the project/product backlogs, schedules, and budgets.
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 he or she clearly understands that boundary. Be very careful about your language — speak clearly about projects versus 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 six 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, and became an “official” project manager.
Over 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, USA. 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 down and I started doing 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, and 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 the trends in software project management and 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 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.
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. I always wanted to do everything I could to help the technical people on the project to be free to do what they did 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, 2010b), building projects around motivated individuals and trusting them to get the job done, self organizing teams, sustainable pace (Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler M. 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:
In my experience, the Adaptive and Exploratory approaches are one in the same. Most Adaptive methodologies will allow changes in scope (adding story cards 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(See exhibit 3).
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, and where the requirements are very well known and are not subject to change, such as a government or industry regulatory requirement.
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.
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, ranging 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 and Jones 1996). At this level of increasing agility, the team asks for input from the project sponsors and/or the customers; 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.
The agile model adds the ability to add or remove scope at specifically defined points (iterations or in the kanban backlog for example). 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 at specifically defined points. The effect of seeing the working software is like in Heisenberg’s uncertainty principle, in which 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 for projects in which 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 and product management combined with deliberate methodology selection to manage an agile project in a waterfall context. As Scrum is the most common methodology (Version One 2009) I will present this example using scrum but the principles apply to any agile methodology.
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. Although 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” (Exhibit 4). 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.
The innermost 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 well-being 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 believe 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 project manager
On multi-team projects, the Agile Team Lead and the project manager work together to coordinate across the teams through a number of forums:
- Joint Iteration planning
- Iteration Coordination
- Joint Iteration Demos
- Joint Retrospectives
Joint Iteration planning
Iteration planning should be done as a unified team on the same day, in the same room if possible. I have facilitated planning sessions with over 100 participants, including sponsors and external (waterfall) members, on four agile teams. Every other two-week iteration (we were using Scrum), the entire team travelled (many are remote), to meet for the joint iteration planning session. The event takes eight hours. The first two 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 telephone conference. 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, often 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 the next time.
Cross Team Coordination
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 he or she was 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 it is also 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.
After the iteration, each team should review their processes and work on improvements. 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 he or she 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 at each iteration, but I recommend that it be done at 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 the 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 to 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, which is typically given six weeks, take only 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 manager 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.
Finally, 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, because 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.
Agile in mixed waterfall/agile environments is complex. It is imperative that project managers keep a strict eye on the differences 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!
Spagnuolo. C (2008, April 25) A tale of two teams [Video file]. Video posted to http://www.youtube.com/watch?v=gDDO3ob-4ZY Retrieved on January 29, 2011
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler M. et al. (2001). Manifesto for Agile Software Development Retrieved from www.agilemanifesto.org
Cassidy, D. (2002. Quantum Mechanics: 1925-1927 the uncertainty principle . Retrieved on January 20, 2011 from http://www.aip.org/history/heisenberg/p08.htm
Ebert, C. (2009, January) Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 22(1)15-19.
Flahiff, J.. (2011, February 18)The Agile Manifesto 10 Years later – Arie van Bennekum Whitewater Projects Podcast retrieved from http://whitewaterprojects.com/2011/02/18/the-agile-manifesto-10-years-later-arie-van-bennekum/
Flahiff, J.. (2011, March 3)The Agile Manifesto 10 Years later – Andy Hunt Whitewater Projects Podcast retrieved from http://whitewaterprojects.com/2011/03/03/the-agile-manifesto-10-years-later-andy-hunt-joseph-flahiff/
Flahiff, J.. (2011, March 3)The Agile Manifesto 10 Years later – Ward Cunningham Whitewater Projects Podcast retrieved from http://whitewaterprojects.com/2011/02/14/the-agile-manifesto-wardcunningham/
Flahiff, J (2010) Interivew with Alistair Cockburn about the DOI. Retrieved from http://gallery.josephflahiff.com/podcast/AlistairCockburn.mp3
Legorreta, L & Ward, C. (2009, April 2) Beyond waterfall and agile methods: Towards a new contingency model for IT Project Management. Social Science Research Network. Retrieved on January 30, 2011 from http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1400254
Rusk, J. (2009) “Earned Value for Agile Development.” agilekiwi.com Retrieved January 30, 2011 from http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf
Schwaber, K. (2010a) Scrum.org. Retrieved January 30, 2011on from http://www.scrum.org.
Schwaber, K. & Sutherland, J. (2010b) Scrum Guide. Scrum Guide Retrieved from http://www.scrum.org/scrumguides/
Suliaman, T. (2007, October 5) AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. Retrieved on January 30, 2011 from http://www.infoq.com/articles/agile-evm
Version One. (2009) 2009 State of Agile Survey “The State of Agile Development” 4th Annual Retrieved January 21, 2011 from http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf
—. 2010 State of Agile Survey. (2010) . “The State of Agile Development” 5th Annual Retrieved on January 21, 2011 from http://www.versionone.com/state_of_agile_development_survey/10/page2.asp
Product management (2011, January 5) In Wikipedia, the free encyclopedia. Retrieved January 21, 2011 from http://en.wikipedia.org/wiki/Product_management (accessed 1 21, 2011).
Womak, J. P., & Jones, D. T.(1996). Lean Thinking. New York, NY: Simon & Schuster
Wysocki, R. K. (2009)Effective Project Management: Traditional, Agile, Extreme, 5th Edition. J Hoboken, NJ: John Wiley
© 2010, Joseph Flahiff
Originally published as a part of 2011 PMI Global Congress Proceedings – Dublin, Ireland