Category Archives: Agile Project Management

Why Should a Project Manager Care About Agile?

Why Should a Project Manager Care About Agile? Many people in the project management profession seem to be in “denial” about the impact of Agile. Many seem to think it is something that they can ignore that has no impact on the project management profession. There are a number of potential reasons why project managers might believe that Agile doesn’t have any impact on them and that the project management will continue to be limited to traditional plan-driven approaches that haven’t changed significantly since the 1950’s and 1960’s:

  • There is a big misconception that “Agile” and “Waterfall” are binary and mutually-exclusive choices which might lead a project manager to believe that he/she can concentrate on “Waterfall” projects and ignore Agile.
  • Agile and traditional plan-driven project management are treated as separate and independent domains of knowledge with little or no integration between the two and it can be quite challenging for anyone to try to figure out how to blend the two approaches together in the right proportions to fit a given project
  • The role of a project manager at the team level in an Agile project is completely undefined and it would be a big risk for anyone to move their career in that direction for that reason. The path of least resistance is to continue to focus on traditional, plan-driven project management and ignore Agile for as long as possible.
  • There may also be an opinion that “Agile” is just a passing fad and will go away and/or the people who do Agile or just a bunch of “cowboys” and it really isn’t a legitimate form of project management at all.

Here’s my perspective:

  • There are many myths, stereotypes, and misconceptions about both traditional project management and Agile that have caused a lot of polarization between these two communities. I’ve developed a free online training course that is designed to help project managers get past some of these misconceptions and see Agile and traditional plan-driven project management in a fresh new light as complementary to each other rather than competitive. Check it out here:

    “Learn the Truth About Agile versus Waterfall”

  • Agile is precipitating a major transformation of the project management profession that will cause us to rethink many things we have taken for granted about project management for a long time. Anyone who ignores this trend risks becoming a “dinosaur”. I believe that in the not-too-distant future, a project manager who only knows how to do traditional, plan-driven project management will be like a carpenter who only knows how to use a hammer.
  • Even if you’re never involved in a real Agile project, learning the Agile principles and practices will broaden your thinking, expand the number of “tools” in your toolkit, and make you a better project manager.

I saw a similar transformation when I worked in the Quality Management profession in the 1990’s and early 2000’s. At that time, the Quality Management profession was shifting from an emphasis on quality control and inspection where someone with the title of “Quality Manager” was responsible for quality and played the role of enforcing quality standards. We learned that a much more effective approach was to engage everyone in feeling responsibility for the quality of products and services and integrating a proactive focus on building quality into the process rather than inspecting for quality at the end of the process.

That was a gut-wrenching change for many people in the Quality Management profession and I can remember that there were a lot of people who were out of work at that time who were slow to recognize and adapt to that transformation. The similarities to the Project Management profession are obvious to me and I hope I can help project managers see the need to recognize and adapt to this transformation. Check out my blog post on “The Future of Project Management” for more on this.

Multi-Dimensional Project Management

I recently wrote a post on “Adaptive versus Plan-driven Project Management”. It occurred to me that this same framework would be useful to help people understand the migration that I believe is happening in the project management profession. Here’s how I see the migration to a new multi-Dimensional project management approach that is likely to take place in the future:

Project Management Transition

I don’t think that anyone today would disagree that “Project Management”, as we’ve known it, is heavily defined by plan-driven principles and practices as shown by the oval in the left-hand column of this diagram and there are many stereotypes that heavily associate “Project Management” with plan-driven practices. What I believe is likely to happen within the project management profession in the future is this:

  • At a team level, a large percentage of project management roles are likely to migrate towards a more adaptive approach over some period of time. That means that many of those project management roles might disappear and project managers who are only qualified to do plan-driven project management at a team level may have to move in one of two different directions:
    • Move up to assume a higher-level enterprise-level role managing larger, more complex projects
    • Develop more adaptive project management skills
  • Project Managers who are already managing larger, more complex projects and enterprise-level projects may be less impacted by this migration; however, even at that level, the demand for project managers who only know how to do plan-driven project management will likely decline significantly.
    • Some of these new roles may not even be recognizable as we know project management today and may not even have the title of “Project Manager” associated with them. For that reason, I think we need to shift our thinking about what “Project Management” is. Instead of thinking of it as a narrow vertical column that is dominated by plan-driven thinking, what I believe is needed is more of a broader, multi-dimensional view of project management that goes beyond just doing traditional, plan-driven project management functions and also embraces a more adaptive approach to project management.

      In my opinion, project managers of the future will need to take on a broader range of roles and must be able to operate in either a plan-driven role or a more adaptive project management role and should be able to select the appropriate blend of those two approaches to fit a given situation rather than force-fitting all projects to a plan-driven approach.

      It seems to me that the Project Management profession needs an image makeover to shift the image of how people think of what “Project Management” is to prepare people for this migration that I believe is likely to happen. I think that there are a lot of people in the project management profession who are in “denial” and seem to think that the way we’ve been doing project management will go on unchanged into the future. I hope this post has helped people more clearly see this migration trend.

Adaptive versus Plan-driven Project Management

I’ve written several articles on the subject of why the comparison of “Agile versus Waterfall” that is so widely used is so inaccurate and misleading. A better way to view it is to think of adaptive versus plan-driven project management. Check it out here:

Learn the Truth About ‘Agile versus Waterfall’

There’s a lot of reasons why that comparison isn’t very meaningful and can be misleading – What is Agile? What is Waterfall? What are you comparing to what? Is it really a meaningful comparison? (I don’t think so)

A much more objective and meaningful way of comparing different methodologies is needed and I think the comparison of “Adaptive” versus “Plan-driven” is much better-suited for that purpose. Here’s how those terms are defined:

  • Plan-driven – “Plan-driven software development is a more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation” (Source: http://en.wikiversity.org/wiki/Plan-driven_software_development
  • Adaptive – An “Adaptive” approach, on the other hand is characterized by having a less well-defined plan that is more adaptable to fit the situation as the project progresses. It’s more of a rolling-wave planning approach where the plan evolves as the project evolves.

This is not a binary, all-or-nothing choice between 100% plan-driven and 100% adaptive:

  • You don’t typically find many situations that have an absolutely rigid plan down to the smallest detail that is not subject to any kind of change and
  • You don’t typically find situations that are totally unplanned where you just start doing something without any kind of plan and make up the plan as you go.

Most situations lie somewhere between those two extremes – there is a continuum of different approaches from a heavily plan-driven approach at one extreme and a heavily adaptive approach at the other extreme with lots of alternatives in the middle. If you were to plot different approaches on this continuum, here’s a sketch of what it might look this:

Adaptive versus Plan-driven Project Management

Here’s some notes on this diagram:

  • This is not meant to be an exhaustive and comprehensive diagram – it is simply an illustration showing a few examples
  • Each of these methodologies can be used in a range of situations – for example, Scrum can be used in a range of situations that have varying levels of adaptivity; however, it would be difficult to make Scrum work in a heavily plan-driven approach
  • However, by putting a plan-driven “wrapper” around Scrum, you can create a hybrid approach that provides a plan-driven shell at the project level but retains most of the flexibility of Scrum at the team level
  • Kanban is generally more adaptive than Scrum because it is typically used in more reactive situations that are less planned (like a customer service process)

There is no “good” and “bad” judgment in characterizing a methodology as “adaptive” or “plan-driven”. Neither an adaptive methodology or a plan-driven methodology is inherently good or bad just because it is adaptive or plan-driven. The problem comes up when they are misused – for example, when you try to use a heavily plan-driven methodology like Waterfall for a situation that has a lot of uncertainty in it and calls for a more adaptive approach.

Why is this important? The traditional comparison of “Agile versus Waterfall” is almost meaningless and very misleading. It frequently is used judgmentally that “Waterfall” is bad and “Agile is good. That leads people to think of those two approaches as binary, mutually-exclusive choices; and, as a result, people many times tend to force-fit a project to one of those extremes. A much better approach, in my opinion, is to view these approaches from a more objective perspective and fit the approach to the nature of the problem based on the characteristics of the methodology and the problem.

What’s the Difference Between a Project and a Process?

What’s the difference between a project and a process? I have a very broad view of what “project management” is. but there is a danger of broadening the definition of a “project” and “project management” so far that almost anything could be a “project” and that would make it meaningless. For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”. I think it could be both because “projects” and “processes” are very inter-related. To eliminate potential confusion, I think we need clearly-defined and objective criteria for drawing a line between what is a “process” and what is a “project”.

I’ve summarized some distinctions below:

ProcessProject
A “process” has an objective that is typically defined around the ongoing operation of the process.
For example, “provide ongoing maintenance for GM vehicles”
A “project” has an objective or outcome to be accomplished and the project ends when that objective is accomplished. That objective might be broadly-defined and might change or be further elaborated as the project is in progress.
For example, “find a replacement ignition switch that will solve the problem with GM vehicles".
A “process” is generally ongoing and doesn’t normally have an end.A “project” has a beginning and an end (although the beginning and end may not be well-defined when the project starts and the end might be a long time in the future).
A “process” is a repetitive sequence of tasks and the tasks are known at the outset since it is repetitive.The sequence of tasks in a “project” is not normally repetitive and may not be known at the outset of the project.

Here’s a similar distinction between “process management” and “project management”:

Process ManagementProject Management
Process management is focused on managing a process such as a software development process. Such a process might be used across a variety of projects.
Process management might involve some project management to define and improve the process.
Project management is focused on managing a project typically using some process in achieving some kind of desired end result.
Every project follows some kind of process even though it may not be formally defined.
Process management has an emphasis on increasing "repeatability" of the tasks, improving efficiency (decreasing time needed, reducing cost), and improving quality of the work product produced by the process (including consistency in quality).Project management has an emphasis on achieving the end result that the project is intended to accomplish.
Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.

In simple, terms, “process management” is focused on managing existing business processes as efficiently and effectively as possible – it’s associated with managing the current way the business operates. “Project management” is associated with managing some kind of change in the way a business operates effectively such as introducing a new product, implementing new processes, etc.

Closing the Gap Between Agile and Traditional Project Management

Most people will agree that there is a need for closing the gap between Agile and traditional project management communities – Agile and traditional project management are essentially treated as two separate and independent domains of knowledge with little or no integration between the two and that has led to some polarization between those two communities:

    1. On the Agile side, many Agile people think of “project management” as a bad word and see no need for it in an Agile project. The fact is that although you may not find anyone with the title of “Project Manager” in an Agile project, there’s lots of “project management” going on – its just a different style of project management and the functions are distributed among a number of people:
      • The Product Owner in a Scrum project performs many project management functions by setting the direction and priorities for the project and making decisions as the project progresses
      • The Scrum Master performs some project management functions by facilitating the team and the process as well as resolving obstacles
      • Everyone on an Agile team performs some very basic project management functions in planning and managing their own work and the work of the team as a whole

The important lesson to learn from this is that:

“(project) management is a function, not a role”.
(Daniel Mezick originally coined that phrase, in this blog post).

Just because you don’t see anyone with the formal title of “Project Manager” doesn’t mean that there is no project management going on.

  1. On the Project Management side, PMI has created the ACP certification that recognizes Agile as an alternative form of project management; however:
    • That certification doesn’t go far enough to define what Agile Project Management is and how someone would use it in a typical project that might require blending Agile and traditional project management principles and practices to fit the situation.
    • PMI needs to go a lot further to develop a broader concept of what “project management” is that fully embraces both Agile and traditional project management roles.

    Many of the definitions in PMBOK such as what a “project” is and what “project management” is are based heavily on a traditional, plan-driven approach to project management and really wouldn’t apply to an Agile project. For that reason, it’s very understandable why someone in the Agile community would have the perception that traditional project management principles and practices don’t apply to Agile at all.

In order to close this gap, I think it is essential to rethink some of the things we’ve taken for granted about project management for a long time to develop a new vision for “project management” that embraces both Agile and traditional plan-driven project management principles and practices. Agile and Traditional Project Management approaches need to be perceived as complementary rather than competitive approaches that are also capable of being blended together as necessary to fit a situation rather than being binary, mutually-exclusive choices.

I’ve recently drafted a document entitled “The Next Generation of Project Management” which outlines some of the more significant shifts in thinking that I think are needed and I’ve shared a preliminary draft of this document with some key people in PMI with some recommendations for what I believe needs to be done. That document has generated a lot of interest and some excellent comments and I’ve updated it to reflect the comments I received. Please take a look at it and let me know if you agree with this vision and recommendations:

The Next Generation of Project Management

Product Development versus Project Development

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:

  • 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.

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.

 

Agile Project Manager Job Description

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:

Introduction

The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating agile project teams to achieve a high level of performance and quality in delivering 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. The APM may play a number of different roles in actual practice:

  • At an enterprise level, leading and managing large, complex enterprise-level projects consisting of multiple Agile teams and/or requiring integration with other activities outside the scope of the Agile teams
  • At a team level, playing a consultative role to help put in place the appropriate people, process, and tools and coaching members of the team as needed to optimize the efficiency of the project team
  • In situations that require a hybrid Agile approach, using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort to 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
  • Team Management – 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
  • Team building – 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

Qualifications:

  • 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

Skills Required:

  • BA or BS or equivalent experience is required; MA or MS is a plus
  • Strong interpersonal skills including mentoring, coaching, collaborating, and team building
  • Strong analytical, planning, and organizational skills with an ability to manage competing demands
  • Strong 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

To understand the context of this and for more insight into the role of an Agile Project Manager, check out my online training course:

“Mastering Agile Project Management”

Managed Agile Development Framework

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”

Managed Agile Development Framework

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

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.

Check out my online training courses to learn more about developing a hybrid Agile approach and some case studies that show how it has been used successfully.

Agile and Lessons Learned From the Martial Arts

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 – 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”

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:

  • Techniques – 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.

(Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

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: http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology

The Impact of Wishful Thinking in Agile Projects

Have you ever been in an Agile project that was so badly under-staffed that it had no hope of success in any reasonable time? I’ve seen that situation more than once…what seems to happen is that people launch an Agile project without a lot of planning to understand the scope, without doing a schedule estimate to see how long it will take with the current team, and without determining if it is even feasible at all with the current resources. There seems to be a feeling based on a lot of wishful thinking in Agile projects, that an Agile team can do anything given enough time.

There are a couple of things that are typically missing in many Agile projects. One is upfront planning…a lot of people may think doing upfront planning to estimate the scope, costs, and schedule and to explore resource tradeoffs is inconsistent with Agile. I don’t believe it is, but you can do as much or as little of it as you want. At one extreme, you can start an Agile project with little or no defined Product Backlog, completely define the requirements as you go along, and have no idea what the overall cost and schedule will be. Or, at the other extreme, you could have a much more well-defined Product Backlog with story point estimates to estimate the costs and schedule, a defined Product Road Map for completing the project, and a reasonably good idea of when it will finish. I am amazed at the number of people who just launch into an Agile development effort without even realizing that is a choice they can make.

There is also typically such a sense of unbridled optimism and wishful thinking that everything will just somehow come out right that permeates Agile projects. Project Managers develop kind of a sixth sense about projects. It’s kind of a sense of smell you develop after you’ve been a PM for a while that you learn to recognize when a project just “smells” bad and is doomed for failure. You develop that sense of smell more rapidly if you’ve been burned a few times in projects that have failed. A good PM learns to recognize those symptoms of failure early.

That sense of impending doom seems to be missing from many Agile projects that are on a path to failure. What seems to happen is that from sprint-to-sprint; the project may be producing good stuff but without an overall plan, no one steps back to see if the project is really going to finish in a reasonable amount of time.

There’s seems to be an opportunity here to integrate some good, old-fashioned, traditional project management thinking with a modern Agile development approach.