Background
We are a traditional “conservative” IT shop in the financial services industry and have a long tradition of building and maintaining highly reliable business systems. Certainly we are more than normally concerned about transactional accuracy, security, access control and “compliance. Hey – Sarbanes-Oxley was written specifically for our industry! However our user community was not satisfied with our time-to-market (read speed, cost, flexibility, Microsoft expectations of “user friendly”, you know the story!). In response to this perceived poor and slow performance, our senior management got sold on SCRUM as the silver bullet to solve all of our time-to-market and quality problems!
So the new law was laid down – “You can use either approach – BUT, you - the PM are now the “single wringable neck” Results are now completely on your shoulders.
How is the company driving us towards this new paradigm? First we brought in an industry GURU to lead workshops, meetings and training sessions on SCRUM. A major focus of this initiative (which is still ongoing) is to transform PMs from “project managers” to “SCRUM Masters”. A significant emphasis on this training is the changing role the leader of an Agile project has from the traditional roles and responsibilities of a PM. Gone are the “command and control” activities of leading, assigning, monitoring and controlling task activities. A SCRUM master is more like a “facilitator” to the team – primarily focused on facilitating getting the team what it needs and blocking distractions of team members by outsiders. In addition to coaching us on how to perform as SCRUM masters, our industry pundit coaches us on how to adhere to the Agile priorities and values and away from more traditional project management techniques and priorities. Finally, the pundit, is coaching and encouraging the movement of project organization and execution to Agile software development techniques and stripping off all other activities that are not value-add (from the Agile perspective).
The company has re-organized, re-prioritized and re-energized our PM center of excellence to “tool” itself to support, encourage and enable SCRUM/ Agile project behavior.
Finally, senior management publicly recognizes Agile projects as the new standard of excellence.
Introduction
So what happens when a traditional PMBOK® Guide / RUP shop abandons “prescriptive” approaches to project management and embraces an Agile/ SCRUM philosophy? Controlled chaos? Massive confusion and discontent? No life goes on much as before – projects still get launched, problems encountered and solved, where we are, what we are doing and how much it is costing (time, dollars, resources, etc.) still get reported. This is a story of a traditional PMBOK® Guide shop driven to embrace SCRUM and its dependent “agile” methods for software development.
So, is there any common ground here? Are the two approaches and techniques so diametrically opposed as their evangelists preach? Our experience seems to indicate that there is much common ground between the two extremes and that useful techniques and habits from both camps can be effectively integrated to achieve faster / more flexible software delivery while still providing management with the pre-, post- and ongoing planning, controlling and communicating instruments management still requires.
PMBOK® Guide / RUP are promoted by us traditionalists because we feel they provide predictability, foster accurate communications, assist in organizing software development over a controllable “lifecycle” and have a long proven track record of delivering on their promises. Our detractors say that they take too long, waste too much time and energy on non-core activities (i.e. documentation and planning), have not proven to result in accurate delivery of either the planned product or execution process, and result in an inflexible and anti-software engineering environment.
Agile and SCRUM (the implementation of leadership techniques over agile projects) is promoted by its adherents as an effective / pragmatic realization that best-practices software development should be developer-centric, functionality oriented, quick to market (30 day sprints), developer/user tightly coupled (co-developed), and quick to respond to developing / changing user requirements. Its detractors question the practicality of ignoring budgetary, time-line and resource pre-commitments, question developers ability to develop architecturally sound solutions from code-up (inside out) development approaches, and how much time and attention the users are really going to devote to “holding the hand” of the developers as they build their solution.
As we move forward along this journey of evolving our software development practices from highly formal, structured and “prescriptive” practices toward more developer-centric, incrementally implemented and adaptive techniques, we are continually learning and adapting our traditional PM methods, tools, processes and people management techniques.
Come along with us as our journey unfolds. We will detail the specific points of congruence along with the points of divergence we have discovered thus far. As we learn to adapt and adopt these two seemingly opposed and competing approaches to project management we will find more common ground and the best practices from both camps. Our mission has never varied – to deliver high quality projects, on-time, on-budget while meeting our organization’s expectations and commitments and satisfying our clients.
Contextual framework
PMBOK® Guide and SCRUM occupy substantially different project domains. PMBOK® Guide addresses a very broad spectrum of industry and solution situations; from capital construction projects to government compliance initiatives to fast pace / dynamic software development efforts. PMBOK® Guide provides a framework of “good practices” validates by years of research by highly disciplined professional and research organizations. PMBOK® Guide can be described as being highly descriptive and weakly perspective in terms of recommended approaches, disciplines and methods. PMBOK® Guide does not mandate or recommend any one method or approach rather PMBOK® Guide identifies many practices, processes, discipline areas and management tools that can aid project practitioners in planning, organizing and delivering projects with predictable, sustainable quality, cost and delivery timelines.
Exhibit 1 PMI(2004) A Guide to the Project Management Body of Knowledge (PMBOK® Guide). processes
“It is important to note that many of the processes within project management are iterative because of the existence of, and necessity for, progressive elaboration in a project throughout the project’s life cycle.”
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
(Cunningham, 2001)
Agile, according to its adherents, is a software development conceptual framework. Thus it appears to have the same context as PMBOK® Guide. However, a review of the Agile Manifesto exposes that Agile has a set of values and preferences that are quite explicit and exclusionary in their implications to software engineering practices. These values expound a profound centricity towards programmer-centric processes and work products.
SCRUM addresses the project management space identified with the newly remerging suite of software development lifecycles oriented towards Agile methods. SCRUM is the project manager layer overlaying a suite of software engineering techniques defined as adding speed of deliver (to functioning code). SCRUM identified very specific management techniques and activities to be strictly and invariantly performed through out the SCRUM / Agile software development lifecycle. SCRUM thus, in converse to PMBOK® Guide, is highly prescriptive and weakly descriptive. Agile, and there-for SCRUM. Is highly focuses on and applicable only to a limited set of project situations involving simple software development efforts. And within that industry only those project where organizational, contractual and/or situational conditions do not preclude the simplified set of project management activities pre-defined by SCRUM. For example, SCRUM mandates that the user community be highly available (to the programmers to aid in co-development of the functionality & features), co-active in these efforts with the developers, and able to respond and agree to changes to requirements and needs real-time and with little external negotiation. Projects that involve multiple stakeholder organizations, formal change management requirements, and/or contract negotiations preceding scope changes will find it difficult to meet the Agile expectations for user interactive user involvement, collaborative development and quick decisions as mandated by SCRUM/Agile techniques.
Exhibit 2 SCRUM Lifecycle – source (www.controlchaos.com)
”At the beginning of a Sprint, we start with the Product Owner ensuring that we have a prioritized and up-to-date Product Backlog.…The team will continue Sprinting until they have developed a sufficiently useful system that can be put into production in a Release Sprint.”2
Life cycle philosophy; SCRUM “sprints” versus PMBOK® Guide “iterations”
Some in the Agile community contend that PMBOK® Guide is an inherently “waterfall” approach – i.e. that it proceeds along a linear / one-directional timeline from inceptions through to post-production support. However nothing in PMBOK® Guide presents such a view. In fact PMBOK® Guide identifies the need for and adapts to any sequencing and re-visiting of the PM disciplines and activities as needed by the individual project.
Points of Convergence
PMBOK® Guide: 5. Project Scope Planning
Both PMBOK® Guide and SCRUM address the product planning and management activities required to organize software development. PMBOK® Guide identifies the need for a Product Breakdown Structure (PBS) as a good practice way to articulate a project’s desired “product”. SCRUM identifies a product Backlog for this purpose.
Product Breakdown Structure – DLO (2001)
Exhibit 3 Product Backlog
PMBOK® Guide 6. Project Time Management
Both PMBOK® Guide and SCRUM address the task planning and management activities required to organize software development. PMBOK® Guide identifies the need for a Work Breakdown Structure (WBS) as a good practice way to articulate the steps needed to product a project’s desired “product”. SCRUM identifies a Sprint Backlog for this purpose.
Exhibit 4 Work Breakdown Structure
Exhibit 5 Sprint Backlog
Both PMBOK® Guide and SCRUM address the progress reporting activities required to manage software development. PMBOK® Guide identifies the need for a periodic status / progress reporting as a good practice way to communicate progress and maintain customer confidence as the project unfolds. Tracking progress also provides the project practitioners and stakeholders the visibility they need to identify when a project is not proceeding according to plan. SCRUM identifies a Sprint Backlog for this purpose. Our company utilizes a task completed chart as part of progress reporting for traditional projects and a sprint backlog chart for SCRUM / Agile projects.
Exhibit 6 Task Complete chart
Exhibit 7 Sprint Burn down chart
Points of Divergence
As mentioned earlier, SCRUM approaches project management as a discipline that is quite focused and specific in its techniques and activities. In the SCRUM / Agile world there are “SCRUM Masters” NOT project managers. SCRUM masters serve as facilitators and “blockers” for the project team. A SCRUM masters primary role is to help the team get the resources it needs and to insulate the project team from distractions from the outside (read senior management) such that they can focus on their agile assignments. SCRUM masters do NOT assign roles or responsibilities to their team members – the team does that itself either explicitly, or by allowing a “natural” evolution as the team learns to work together. SCRUM Masters take a back-seat role in coordinating work activities, facilitating inter-team communication, monitoring performance and confirming task completion. These traditional tasks are to be self-managed by the Agile team. While none of these techniques are exclusive of the traditional role, responsibility and work activities identified as good practices in PMBOK® Guide, the SCRUM / Agile mandate that the SCRUM master role is excluded from assigning, directing and measuring work performance is in direct contradiction to PMBOK® Guide’s “good practices”.
PMBOK® Guide does not mandate or prefer any approach to delivering PM services. SCRUM mandates 30 day “sprints”, daily Quick SCRUM (30 minute standup team check-point meetings) and working from a customer prioritized backlog of desired features. PMBOK® Guide is willing to adopt these techniques where appropriate, but does not mandate them or recommend them over similar equivalent ways of delivering work.
PMBOK® Guide identifies multiple areas of management attention for which SCRUM/Agile does not have a counterpoint. For example PMBOK® Guide identifies good practices around vendor and contract management. SCRUM does not articulate any practices in these areas PMBOK® Guide has highly developed practices associated with risk identification, quantification and risk mitigation. SCRUM/Agile describes its methods as being inherently risk mitigating and this may well is true for software development exercises that are subject to evolving requirements.
PMBOK® Guide does not preferentially recommend one SDLC over any other. (I.e. waterfall over Iterative over eXtreme Programming). PMBOK® Guide Guide’s good practices have value and can be incorporated into any SDLC that does not reject investing time and attention to additional areas that a SDLC has predefines as in scope of their methods.
What have we learned thus far?
PMBOK® Guide and Agile / SCRUM are NOT diametrically opposed.
Agile’s emphasis on individuals and interactions over processes and tools, working software over comprehensive documentation , and customer collaboration over contract negotiation is completely consistent with PMBOK® Guide and was already in place for most of our projects. In addition its approaches of incremental development of working code, close synergy with the user community, test-driven development and flexible willingness to change in midstream are best practices we can readily adopt.
Traditional project management (i.e. PMBOK® Guide) with its associated PM work products, check points, focus on the end-goal and how to get there and strong communications capabilities are valued by management and the project team alike. They promote common understanding and expectations; provide a basis for organizational planning, commitment and predictive scheduling of financial and human resources.
Together, traditional PM disciplines and newly emerging software development techniques along the Agile / SCRUM philosophy can help us bring in our software development projects more quickly, with greater client satisfaction and often at a lower cost. PMBOK® Guide and Agile / SCRUM are NOT diametrically opposed or mutually exclusive. The opposite is true – the strengths of PMBOK® Guide and Agile / SCRUM can be effectively integrated to better deliver on our software development project commitments.
