So, you’ve settling-in with the concepts of developing software in an “Agile” world, sprint-by-sprint. There’s a team of technically-qualified, cross-functional developers. The Scrum Master has a certification and has worked on “Agile” projects previously. The Product Owner has years of experience in the company and appears respected by the executive management. The line-up is pretty much in accordance to all the Internet articles, books and blogs you’ve read, about this modernized approach to software development.
Outside the office, you meet-up with some co-worker friends and conversation gets into how things are going with your project. Since your new project is using “Agile” and “Scrum”, they are interested in hearing your comments on how Agile is different from the company’s traditional project management methodology. One of the first questions you get asked is “Who’s running your Agile project?”
Traditionally, the answer was to simply name the Project Manager. However, this is not the Agile way. So, your discussion on Agile Project Management launches into topics of the Product Owner’s role as representative of the stakeholders, prioritizing the Backlog of required functionality to optimize business value; the self-managing development Team and their commitment to meeting the Sprint goals; and the responsibility of the Scrum Master to properly facilitate the Sprint and Scrum processes.
At this point you may have noticed your friend’s facial expression go from curious to concerned because not only was there no project manager’s name mentioned, there was no mention of a project plan, no project budget or scheduled end-date, no risk management, and no mention of upper management reporting or signoff.
The management of Agile software development and the Project Management of an enterprise-wide implementation initiative are not the same. So why does an Agile project need a Project Manager? From the enterprise view, project management provides valuable business benefits whether you are using Agile software development or not. From the executive management perspective, projects are articulated in terms of business needs, allocated budget and implementation Go Live” dates. Executive management want to see that their expectations for project scope, cost and time are being managed; that risks are being monitored and addressed, that scope change is being controlled and importantly, that someone is accountable to them for progress monitoring and the successful completion of the project. Traditionally, projects often start with the installation of a project manager who reports to executive management or to the Steering Committee that represents them. Executive management look to the project manager for assurance that their requirements are being met and the project manager is their “go to” person to get answers on anything that may relate to the project.
Something that is different with projects involving technology solution development is that often they involve a team of knowledge workers who have a better understanding of how to build the solution, than do the people that they report to. Consequently the power of the self-managing team approach becomes clear as the development Team make their own decisions on who works on which feature and create effort estimates as they plan the work for the next sprint. Executive management may be comforted to know that that there is a strong and dedicated, self-managing development team working on the project, but that does not address their question of who is accountable for successful project completion.
Although the Scrum Master runs the daily Scrum meetings to keep Sprint progress on track and addresses impediments impacting the Team, the Scrum Master isn’t consequentially a Project Manager. The Scrum Master’s role includes valuable activities for technology solution development, but the Scrum Master has no overall responsibility for project for scope, time and cost, or accountability for the successful completion of the project.
The Product Owner represents all the stakeholders in the project and manages the Product Backlog, prioritizing solution features by business value. The Product Owner has profound responsibilities on the project requirements side of the project, but no serious accountability on the solution delivery side. Although these activities relate to some standard project management practices and support a good bang-for-buck approach, the Product Owner does not fulfil executive management’s expectations of the Project Manager who is the overall “go to” person and accountable for the successful completion of the project.
So, Is the Agile Project Manager an oxymoron? Hopefully not! Scrum has taken some of the traditional Project Manager role and redistributed it into the Product owner, Scrum Master and Team members’ roles. Although Scrum has shown benefits in the technology solution development context, it provides little joy for executive management who are looking for the person who’s accountable for their planned project expenditure, the person who they’ve entrusted with the delivery of their required solution within the expected timeframe and cost, the person who deals with project risks before they turn into issues, the person who proactively monitors progress and keeps management appraised of achievements and challenges while taking on required changes and tenaciously removing impediments, the person they can go to get the straight answer on any project question – the Project Manager.
The Project Management landscape covers much more than technology solution development. Its horizons reach back to support transition from existing legacy systems that may remain business critical, in whole or in part, until the new solution is completed. It also looks forward, with consideration for future needs, taking care not to introduce potential impediments that could hinder potential future growth, and attempts to provide extensible solutions that can be leveraged and provide additional value to the project being undertaken.
At the foundation of the Agile movement, is the Agile manifesto, a set of values with associated principles to guide developers in a modernized approach to develop software. Scrum is a managed set of development processes with defined roles for those involved in software development projects. Scrum is predominantly considered the tool of choice for the practicing Agile Project Manager. Then again, Scrum has been utilized for technology solutions beyond software development and has been embraced as an essential tool for many of today’s professional Project Managers. Rather than join in the Project Management disputes of waterfall versus Agile methodology, let’s allow ourselves to be less rigid about traditional Project Management practices and develop an understanding of project management that leverages Agile concepts and looks at how the Agile Manifesto correlates to project management accountabilities. Let`s reconsider the Agile values and how they can be applied to improve our Project Management practices.
Individuals and interactions over processes and tools: A first step priority for an Agile project manager is to establish a proactive project management relationship with the project stakeholders, taking ownership of, and accountability for, the project. Identifying and speaking with the project sponsor and project authority – the highest level of project escalation, as well as all members of the Steering Committee, confirming the organizational will to undertake the project. The Agile project manager sets expectations, manage expectations and deliver on expectations. Projects tend to be more difficult than the initial impressions and the devil is in the details. So, an Agile project manager is conservative with promises, in hope for the opportunity to over-achieve.
A large portion of any Project Manager`s role is people management. Since the Scrum team members are self-managing, the Agile Project Manager will monitor team interactions and provide support and advice to ensure optimum Team performance. As much as possible, the Agile project manager will have the Team physically work together and communicate face-to-face.
Working software over comprehensive documentation: The Agile project manager understands the benefits of harvesting the “low-hanging fruit”, especially if these are features that have significant business value. Project team credibility can be gained by delivering on a required functional capability in a short timeframe, even if the working technology solution came straight out of a box.
A fundamental point here is about “delivering”. The Agile project manager knows that there is more to project management than developing the technology solution. The traditional project metaphor of “tossing the solution over the wall to the end user” will happen if the Agile Project Manager does not address end-user implementation. The “Working software” or “Working technology solutions” must include the end-user training and support in order for the end user to consider it “Working”. Project outcomes that are implemented for the end user, with consideration for training and support are much more valuable that an outcome without those considerations. However, a detailed design document for a project outcome that will not be developed until the full set of project detail design documents are signed off, holds no real present value to the end user.
Customer collaboration over contract negotiation: Project completion is successful when executive management can see that the business value of the project outcome justifies the project expenditure. Project Completion Criteria provides a high-level, documented feature list for your stakeholders, defining the business need and providing a description of the project end-state – a vision of what “Done” looks like.
The Agile project manager must be able to distinguish between “right” and “perfect”. Traditionally, it is common for the Product Owner to become more certain of their requirements after development has progressed; this led to the need for change management. The Agile Project Manager will allow the Product Owner to be uncertain about some requirements and focus development where the Product Owner is certain of the a feature’s need and associated benefit. The Sprint time-box approach is very good at enforcing this concept. Time isn’t developing a guess for a requirement that the Product Owner is not certain about. Any feature that is related to an uncertain requirement has a high probability of ending up on the project Risk Register, Issues List or Change Log. The “right” thing to do is take action on developing the “certain” requirements and leave the uncertainty to later iterations. Do not wait for the signed-off documentation to be “perfect”.
Responding to change over following a plan: Executive management plan in accordance with their business planning cycle, commonly planning by Fiscal year, many organizations use 3-year or 5-year planning horizons. Like many other areas of business, project management is very “time” sensitive, and timing is a determining factor in project success. One of the downfalls of the waterfall approach is that by the time requirements are collected and analyzed, and subsequent design is completed and signed off, things often change. These changes can result from changes in the business environment, improvements in technology relating to the target solution, or changes in the Product Owners perception of a feature’s business value. Onerous change management processes are seen more as handcuffs to change rather than enablers.
The history of technology project delivery has shown that users hardly ever know exactly what all their requirements are, in detail. The tradition project management processes to handle this included detailed requirements signoff that restricted chance and an onerous change management process that again, restricted chance. A more agile approach acknowledges that forcing users to guess at final detail requirements and restricting change often results in wasted effort. The Agile Project Manager will focus on the mandatory, or high priority features and address a lower-priority, easy feature only if the Product Owner is certain of the requirement and the development will fit within the Sprint time-box. The Agile approach of delivering working technology solutions for priority “certain” requirements in a short time provides initial successes and importantly, establishes a trust with management that the Agile team can deliver.
So, let’s reign in the zealots - not all projects managed using the more-traditional waterfall methods are doomed to failure, and Agile development is not just sanctioned hacking that’s complete when the money runs out. Within the context of their domains, there are valuable concepts that each can leverage from the other.
Although the Agile roles do not include a Project Manager, the Project Manager role can be included in Agile. In traditional project management practice, the Project Manager’s role is a standalone single point of project responsibility – a “go to” person accountable for the project’s successful completion. Implementing agility in project management requires the Agile Project Manager to be adaptive and accepting of change. Being Agile requires the Project Manager to not only be adaptive to project content changes without requiring detailed documentation, but also adaptive to changes in the way project management is carried out.
mplementation projects continue to need good project management. Unlike Agile, traditional project manager responsibilities include management of the Team and management of stakeholder requirements. The success of Agile demonstrates that there is little benefit to interfere with these management activities undertaken by the Product Owner or the self-managing Team. A skilled project manager, knowledgeable in Agile and Scrum, may be able to take on the Scrum Master role and the Agile Project Manager role. If the scale and complexity of the Agile project, combined with management reporting requirements are overly burdensome, separate Project Management and Scrum Master roles may be needed. Essentially, the Agile Project Manager assumes full accountability for the project and adapts project management practices to assist others on the project fulfil their various roles.
The Agile Project Manager runs the Agile project as a dynamic and adaptive set of processes including Sprints and Scrum. And, the Agile Project Manager runs the Agile project by setting a clear target for executive management, describing project completion criteria including mandatory outcomes and prioritized, conceivable outcomes, with associated timeline and financial metrics.
Today’s Project Managers need to understand and leverage Agile concepts and practices. Upholding Agile values, they promote transparency and inclusiveness for all stakeholders and strive to fortify the Team’s passion to develop elegant technology solutions. As a result, they will become better Project Managers and improve the potential for their Project’s success.
- Name
-
Ken Aalders
- Biography
-
PMP, Bank of Canada