I came across the diagram shown below that I think nicely summarizes different levels of mastery in Agile:
Many people don’t seem to realize that there are these three different levels of mastery and just learning the basic practices is only the beginning.
Three Levels of Mastery
The three levels of mastery are:
1. Practices (Doing)
The initial level of Practices is associated with learning the basic practices of Agile at a mechanical level.
There are many people who are at this level of learning – they’ve received their CSM certification (or equivalent) and they may have had some practice in the real world and know how to do the basics.
The danger is that many people think that this is all they need to know when they have mastered this level of learning.
People who get stuck in this level of learning can become fairly ritualistic or dogmatic and insist that there is only one way to do Agile and that is doing it exactly by the book as they have learned to do it.
2. Principles (Understanding)
People who have gone on to the Principles level of learning have gained a deeper understanding of the principles behind Agile and why it makes sense.
This deeper level of understanding gives people a broader perspective – instead of seeing Agile as a mechanical process that must always be done ritualistically “by the book”, people at this level recognize that there may be a need to customize and adapt the processes to fit a given situation.
They are also able to see Agile in a much broader context beyond the basic team-level Agile implementation and recognize the need to make Agile work at much higher levels of complexity for large enterprise-level projects.
3. Values (Being)
Values is the highest level of mastery.
People at this level of learning not only understand the principles at a deeper level, they also understand the values behind those principles and have internalized those values into the way they work.
People at this level are becoming Masters and are at the “top of their game” – they are able to easily go beyond applying Agile to routine Agile project implementations and they are able to apply the principles and practices to much more demanding and difficult situations with much higher levels of consistency and success.
The three levels of mastery shown in this diagram correspond to the “Shu-ha-ri” levels of mastery from martial arts that I have previously discussed:
How does this relate to the idea of “Agile Project Management”? People who look at Agile and traditional plan-driven project management practices (what many people tend to call “Waterfall”) at a basic level of practices will typically see them as competitive, mutually-exclusive, binary alternatives that are totally incompatible with each other. This is a basic problem and has led to Agile and traditional plan-driven project management being perceived as separate and independent domains of knowledge with little or no integration between the two.
I believe that people who are at a higher level of learning and understand the principles behind these two disciplines will see things in a very different perspective.
They will probably see them as much more complementary rather than competitive and recognize the reasons why one set of principles and practices makes sense in one situation and not another.
They will probably not see them as totally incompatible and be able to easily blend the two sets of principles and practices together as needed to fit a given situation.
Cooks and Chefs
One of my favorite analogies for this that was originally created by Bob Wysocki is the difference between a “cook” and a “chef”:
A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.
A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.
This is the challenge that I believe we face in creating a more integrated approach for Agile Project Management. We need to develop more “chefs” who are capable of seeing both Agile and traditional plan-driven project management principles and practices in a very different light as complementary rather than competitive alternatives.
What is the next generation of project management? What is the impact of Agile on the future of project management?
Does it mean that project managers who are heavily trained in a traditional plan-driven approach to project management will become obsolete over some period of time?
What do project managers need to do to adjust their career direction to adapt to the future direction of project management?
I believe that the project management profession is at a major turning point that requires broadening our view of what “project management” is and reshaping the direction of the project management profession for the future to fully embrace and integrate both Agile and traditional plan-driven project management as complementary approaches within an overall project management portfolio.
Reinventing Project Management
What sort of image comes to your mind when you think of the words “project management”?
Does it have any relationship to Agile? My guess is that many people have a very well-ingrained image of what “project management” is and many people wouldn’t associate “project management” with Agile at all.
In fact, many people still see those two disciplines as polar opposites.
To see things differently, we have to broaden our thinking about what “project management” is and get past many of the well-established stereotypes of what “project management” is.
Long-lasting companies have learned to “reinvent” themselves from time-to-time to keep up with changes in technology and the business environment they operate in. Here’s an excerpt from Harvard Business Review on that topic:
“Sooner or later, all businesses, even the most successful, run out of room to grow. Faced with this unpleasant reality, they are compelled to reinvent themselves periodically. The ability to pull off this difficult feat—to jump from the maturity stage of one business to the growth stage of the next—is what separates high performers from those whose time at the top is all too brief.”
“The potential consequences are dire for any organization that fails to reinvent itself in time. As Matthew S. Olson and Derek van Bever demonstrate in their book Stall Points, once a company runs up against a major stall in its growth, it has less than a 10% chance of ever fully recovering. Those odds are certainly daunting, and they do much to explain why two-thirds of stalled companies are later acquired, taken private, or forced into bankruptcy.”
“A successful company is like a great white shark. In its prime, it chews up the competition, but if it dares to sit still for too long, it dies. Some of the world’s most profitable and enduring companies have achieved their long track record of success by constantly reinventing themselves.”
“Cell phone maker Nokia started off selling rubber boots. The oil giant Shell used to import and sell actual shells. But these companies and the eight others on our list adapted with the times, evolving their product lines and business strategies to stay one step ahead of their customers’ needs. In business, it’s better to be a chameleon than a great white.”
Check out the link above for some great examples of companies that have done that successfully. As the article points out, the trick is recognizing that you are at a “stall point” and taking action before you have stalled for very long and that can be a difficult thing to do.
Project Management History
To understand the transformation that is going on, its useful to look at the history of project management and how we got to where we are today:
Project Management could probably be considered to be one of the world’s oldest professions. Think of the Egyptian pyramids and the Great Wall of China.
The level of “project management” at that time may have been very crude and they probably didn’t call it “project management” at all but large efforts like that don’t just happen without some kind of planning and organization behind them.
In the US, the development of the Transcontinental Railway in the late 1800’s is another example of a very large effort that had to have some kind of planning and organization behind it.
Scientific Management Approach
Around the turn of the century, along came Frederick Taylor and his co-worker, Henry Gantt. Frederick Taylor started developing new theories on how to organize workers and Henry Gantt created his famous Gantt Charts to describe the order of operations in work.
World War II and the 50’s and 60’s
World War II resulted in the Manhattan project which was another huge effort and the 1950’s and 1960’s had more large scale efforts such as the Polaris missile program and the Apollo program to put a man on the moon. PERT and CPM were invented and then in 1969, PMI was founded.
The Next Generation of Project Management
The general approach for doing project management hasn’t changed significantly since that time and the big question is “What’s next?” and also “Why Now?”
Has the project management profession reached its peak or is there yet another major phase of growth that is just beginning to take place? I believe it is the latter.
Here’s why I believe it there is some level of urgency to rethink the way we think about “project management” – the diagram below shows how the adoption rate of new technologies has changed over the last century.
“Source: Mulbrandon, Catherine, Visualizing Economics – Adoption of New Technology Since 1900, http://visualizingeconomics.com/blog/2008/02/18/adoption-of-new-technology-since-1900
This data only goes through 2005, but you can be sure this trend hasn’t slowed down since then. (Think of how quickly smartphones have evolved as an example) This rapid proliferation of new technology calls for a new approach to project management – the traditional, heavily plan-driven approaches of the past can’t keep pace with the speed that technology is changing in many areas.
This dynamic and rapidly changing environment calls for a more adaptive project management approach but that doesn’t necessarily mean that we need to throw out everything we’ve learned about traditional, plan-driven project management and start over again but it does create some significant challenges for individual project managers and for the project management profession, as a whole.
What’s the Impact on Project Managers?
This “raises the bar” for project managers significantly:
In the past, if you had a PMP certificate, that was as far as you needed to go for many project management roles.
PMI has now created the Agile Certified Professional (ACP) certification and that’s not an easy certification to get, but that’s only the beginning, in my opinion.
I think the PMI-ACP exam is good certification but it doesn’t go far enough. It is really mostly a test of terminology – it doesn’t really test whether you know how to integrate Agile and traditional project management principles and practices in the right proportions to fit a given situation and that’s the real challenge for project managers, in my opinion.
A good Agile Project Manager also needs to be a strong cross-functional leader – he/she cannot be just a coordinator or administrator. That means he/she needs to have some credible knowledge of the functions included in the project.
What Needs to be Done to Address These Challenges?
This is a huge challenge to transform the project management profession and broaden our thinking of what a “project manager” is and it will take some time. However, I believe that the alternative of ignoring these trends and continuing to think of a project manager in the narrow context of someone who only does traditional, plan-driven project management approaches will seriously degrade and undermine the project management profession over time. Here’s what I think needs to be done to address this challenge:
1. Acknowledge the Need to Make a Change
The first step in any twelve step program is to acknowledge that we have a problem – we cannot deny the impact of Agile on the project management profession and think that traditional, plan-driven project management approaches as we know them will go on forever and Agile is just a fad that will go away.
2. Get Past Sterotypes
There are many stereotypes about what traditional project management is and about what Agile is that we need to overcome and change our thinking to see both Agile and traditional project management approaches as complementary to each other rather than competitive.
3. Redefine Project Management
We have to better define and develop the concept of what an “Agile Project Manager” is and better define the role that an “Agile Project Manager” might play. In my view, an “Agile Project Manager” is not someone who only does Agile projects; it is someone who has a deep knowledge of both Agile and traditional plan-driven principles and practices and knows how to blend them together in the right proportions to fit a given situation.
4. Develop Agile Project Management Training
We need to develop training programs and resources to help project managers reach the goal of becoming an “Agile Project Manager”.
Project Managers are a product of the environment that they work in. For example, many project managers take a heavily plan-driven approach to controlling costs and schedules of a project because that’s what their organizations expect of them. To change the behavior of project managers, we change the expectations of what companies expect of project managers and that can require some significant changes in organizational culture.
Agile has been most widely used in “product” development environments and less widely used in “project” development environments. The difference between product development versus project development is not widely recognized. Of course, this is not a totally universal, black-and-white distinction; but, in general, here are some key differences:
Products are less deterministic and the business model is usually a little more open-ended. For example, a company might say that we want to develop a product to satisfy “X” market need (where that market need may only be generally defined and might need to be validated) and we’re going to invest $X to fund a team for ongoing development to support that product development initiative.
For many products, it’s an effort that simply goes on-and-on without end to provide ongoing support and enhancements for the life of the product. Products are generally somewhat speculative and might require a significant amount of innovation particularly if it is something that has never been done before. For that reason, a product development effort is very well-suited to an Agile development process.
The business model behind a product development effort is typically based on a projected return on investment (ROI) that the decision to invest $X in the ongoing development effort will provide an acceptable return from the profitability that the product will generate over a period of time.
The decision process associated with a product development effort is generally focused on prioritizing what features should be added to the product to provide the highest level of customer satisfaction and profitability. That decision process is ideally suited to an agile development process.
Projects are typically more deterministic and less speculative. Very few development teams are given a “blank check” to do some kind of project without having some expectations of what the project will accomplish, what it’s going to cost, and what the schedule will be.
The business model behind projects is also typically very different.
A company typically has a given amount of funding to invest in projects and some kind of project portfolio management approach is generally needed to determine the appropriate mix of projects that will provide the greatest overall benefit.
In order to make that decision, something must be known about the expected results, costs, and schedules of the projects in that portfolio and there is an ongoing need to monitor the performance of those projects to see if they really are going in the right direction to provide the return that was expected.
Applying Agile to Project Development
The process associated with managing a “project” is also typically different…the general nature of the features the “project” will provide would generally be much more well-defined prior to the start of the project, there would typically be some expectations about what the cost and schedule of the project would be, and it probably wouldn’t be completely open-ended to add features as a “product” might be. These are key reasons why it is more difficult to apply an Agile development model to projects than it is to products.
Applying Agile principles and practices in a “project” development environment rather than a “product” development environment can be a bit more challenging but it definitely can be done.
Agile works best where there are no constraints on costs and schedules and the primary goal is to add features to maximize customer satisfaction (product model).
When you introduce constraints on costs and schedules (project model), this is the area where it is many times appropriate to use some kind of hybrid managed agile approach to meet the competing demands of a highly flexible and adaptive development approach and the predictability of meeting cost and schedule constraints that is often demanded in a project environment.
The Hybrid Agile Development Approach I’ve described in one of my other posts is an example of how this can be done. It involves wrapping a “shell” around an Agile development process that can be as thick or thin as you want it to be to provide a sufficient level of planning and predictability to meet the needs of the business environment while retaining a lot of flexibility and adaptivity within the development process.
I was recently asked by a company I am working with to create an Agile Project Manager job description. Here’s what I came up with:
The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating Agile project teams. The goals are to:
Achieve a high level of performance and quality, and
Deliver agile projects that provide exceptional business value to users
The APM may be responsible for managing several concurrent high visibility projects using agile methods in a fast-paced environment that may cross multiple business divisions.
Potential Agile Project Manager Roles
The APM may play a number of different roles in actual practice:
At an enterprise level, potential roles include:
Leading and managing large, complex enterprise-level projects
The projects may consist of multiple Agile teams and require integration with other activities outside the scope of the Agile teams
At a team level, potential roles include:
Playing a consultative role to put in place the appropriate people, process, and tools, to improve team efficiency and effectiveness
Coaching members of the team as needed to optimize the efficiency of the project team
Hybrid Agile Role
In situations that require a hybrid Agile approach, potential roles include:
Using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort
Achieve the project goals within designated project constraints
In performing these roles, the APM will be expected to use a high level of knowledge and experience in blending traditional project management principles and practices with an Agile development approach in the right proportions to fit large, complex, mission-critical, enterprise-level projects and with the appropriate level of planning and provide the right balance of agility and predictability.
Essential Job Requirements
Project Planning and Management
Define project scope and schedule while focusing on regular and timely delivery of value; organize and lead project status and working meetings; prepare and distribute progress reports; manage risks and issues; correct deviations from plans; and perform delivery planning for assigned projects
Assist in team development while holding teams accountable for their commitments, removing roadblocks to their work; leveraging organizational resources to improve capacity for project work; and mentoring and developing team members
Product Owner Support
Support the Product Owner in managing customer expectations for project deliverables, managing stakeholder communications, and helping to implement an effective system of project governance
Process Management and Improvement
Define and manage a well-defined project management process and champion ongoing process improvement initiatives to implement best practices for Agile Project Management
Promote empowerment of the team, ensure that each team member is fully engaged in the project and making a meaningful contribution, and encourage a sustainable pace with high-levels of quality for the team
Solid understanding of software development life cycle models as well as expert knowledge of both Agile and traditional project management principles and practices and the ability to blend them together in the right proportions to fit a project and business environment
A proven track record of successfully implementing software or web development projects using Agile methodologies including 8+ years of experience as a Project Manager managing large, complex projects in a high-tech development environment with multi-function teams. PMP preferred
Prior experience with SCRUM/Agile methodologies with enterprise-level application development projects. PMI-ACP, CSM, or equivalent preferred
Experience overseeing multi-function project teams with at least 10-15 team members including Developers, Business Analysts, and QA Personnel
Balanced business/technical background:
Sufficient level of technical background to provide highly-credible leadership to development teams and to be able to accurately and objectively evaluate complex project risks and issues
Ability to provide leadership to business analysts and collaborate with customers and develop strategies and solutions of high business value
BA or BS or equivalent experience is required; MA or MS is a plus
Very effective interpersonal skills including mentoring, coaching, collaborating, and team building
Strong analytical, planning, and organizational skills with an ability to manage competing demands
In-depth knowledge and understanding of business needs with the ability to establish/maintain high level of customer trust and confidence
Proven ability to lead software development projects and ensure objectives, goals, and commitments are met
Solid understanding of and demonstrated experience in using appropriate tools:
Agile Project Management tools such as Jira/Greenhopper, Rally, VersionOne or equivalent
Microsoft Project, Visio, and all Office Tools
Excellent oral and written communications skills and experience interacting with both business and IT individuals at all levels including the executive level
Creative approach to problem-solving with the ability to focus on details while maintaining the “big picture” view
This is a new and rapidly evolving field. For more insight into the role of an Agile Project Manager, check out the online training curriculum below:
I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That presumes that this is a binary, all-or-nothing choice that you have to choose one or the other and not both. It excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement
A few years ago I was responsible for managing a large government project that required meeting some defined cost and schedule milestones but the customer wanted to take an Agile approach to defining the requirements. In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals.
We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the “macro-level”, and
Within that “macro level” envelope, we were still able to implement a fairly Agile development approach at the “micro-level”
How Does It Work?
I’m providing a brief description of how it works here (refer to my book for more details). There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.
The macro-level framework is a plan-driven approach, designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach that is designed to be adaptive to user needs
Trade-offs to Consider
Naturally, there are tradeoffs between the level of agility and flexibility to adapt to change at the “micro-level” and the level of predictability and control at the “macro-level”. It is important that both the client or business sponsor and the development team need to agree on those tradeoffs. The framework provides a mechanism for making those tradeoffs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.
Increasing the level of predictability and control requires beefing up the macro-level and providing more detailed requirements at that level and implementing at least a limited amount of change control
To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements
Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors
A question that often comes up is “How do you handle change control?”. The answer to that question is that you have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level. However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones. This general approach can be used on almost any project.
I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and lessons learned from the martial arts like Karate.
What Is the Similarity?
In theory, there should be a lot of similarity:
Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”
How Does It Compare to Actual Practice?
In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:
Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.
Finesse and Skill
I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.
People may not be dedicated to Agile teams
The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
There may be no Product Owner role and the business side may not be well-integrated with the project
Levels of Skill
Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).
There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.
There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:
“Shu” means to keep, protect, keep or maintain.
During the “Shu” phase, the student builds the technical foundation of the art.
In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher.
In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based
“Ha” is the second stage of the process.
“Ha” means to detach and means that the student breaks free from traditions to some extent.
In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.
“Ri” means to go beyond or transcend.
In this stage, the student is no longer a student in the normal sense, but a practitioner.
The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life.
In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.
If you think about our current level of knowledge of Agile as it exists today,
I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery.
I’m not sure how many people realize how big this gap is between where we are now and where we need to get to.
I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.
Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked:
I participated in a discussion recently on the subject of estimation in an Agile Project – the individual who started the discussion indicated that his team was not very good at estimating and asked whether it was important for them to become more proficient in estimating the level of effort required.
Why Is Estimation Important?
I think it is very important and it is a skill that is often neglected in Agile development projects. Here’s why I think it is important:
At a project level, there is a need for some kind of planning to estimate the scope of the effort and to set expectations of how long it is going to take to finish the project.
Very few projects are given a “blank check” to get something done without some kind of expectations associated with the cost and schedule of the project and it’s irresponsible to not set and manage those expectations.
I have seen Agile projects where the project has gone on-and-on for an extended period of time without a plan for when it would finish; and, in one case, the project was so large that it couldn’t possibly be done by a single Agile team and that wasn’t discovered until well into the project when the project had to be re-planned and estimated.
At a more tactical level within a project,
There is an ongoing need for the Product Owner to evaluate the value produced by stories against the level of effort required to develop that capability to ensure that the work is being prioritized properly to maximize the value the project produces. If you only know the business value to be produced without an idea of the level of effort associated with it, it is very difficult to make a good decision about that.
There is also a need to accurately size the level of effort that can be taken into a sprint so that it can be completed successfully. It can be demoralizing for a team to never finish a sprint successfully because they weren’t able to accurately estimate the level of effort required.
The Role of Estimation in a Project
There is no question that estimation is a difficult thing to do in an Agile environment, but the importance of doing estimation is not well-understood and developers sometimes resist making estimates.
The important thing is to define the approach for doing estimation in the context of the project you’re operating in. Some projects may have very uncertain requirements and may be very difficult to estimate and that may be considered OK but that doesn’t have to be the norm for all Agile projects.
It is not an all-or-nothing decision to be totally adaptive with no plan or estimates at all or to be rigidly plan-driven. There are plenty of alternatives between those two extremes.
The inter-relationship of people, process, and tools in an Agile project is important to understand particularly when you try to fix a broken project.
Typical Traditional Project Management Approach
On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager, I will re-plan the project, get it on the right track, and perhaps also”ram-rod” the effort to get it moving through to completion if necessary. That’s the typical expectation of what a traditional Project Manager might do. If a project fails, it is the Project Manager who is held responsible.
I think the Agile environment is different…I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however, a more critical role in many cases in an Agile project is working on developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient.
The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project – in a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.
I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning and, as a result didn’t have the right people, process, and tools to do the project successfully – this happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:
It takes a lot more skill to organize a large, enterprise-level Agile project because the number and different types of people involved are typically a lot more numerous and complex. It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully.
For example, I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project. In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction and without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble.
In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels. There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure.
It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams. There is also often a need to define a hybrid process that blends together some amount of traditional plan-driven project management at a higher level with an Agile development approach like Scrum at the team level.
Tools also can be a major problem area. The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects.
For example, people might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated. Managing that type of situation typically requires more sophisticated, on-line electronic tools.
I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools.
In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful.
That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.