Tag Archives: Agile Project Management

Agile Project Management: Are You a Caterpillar or a Butterfly?

I attended a very good webinar the other day with Ankur Nagpal, the CEO of Teachable, which is one of the training platforms that hosts my Agile Project Management Training curriculum.   He was talking about how to market training and made a comment something to the effect of:

“We shouldn’t be providing “training courses”; we should be providing “transformation”

He used the example of transforming a caterpillar into a butterfly.  He is absolutely right and that is exactly the approach I’ve strived to develop in my Agile Project Management courses for the past year and a half.  In fact, the picture I use as a symbol of my new Agile Project Management Academy and my Mastering Agile Project Management course is based on transformation:

Agile Transformation

It’s not exactly transforming “caterpillars” into “butterflies” but I think that analogy fits pretty well. It’s about transforming project managers (who may have been heavily indoctrinated in a traditional, plan-driven approach to project management that hasn’t changed significantly since the 1950’s and 1960’s) into a much more high impact orientation that is:

  • Focused on producing results in addition to simply managing projects
  • Based on blending together Agile and traditional plan-driven project management principles and practices in the right proportions to fit any situation rather than force-fitting all projects to a traditional, plan-driven approach

That’s not an easy thing to do for several reasons:

  • PMI has at least recognized Agile as a legitimate variation of project management but “Agile” and traditional plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two
  • The prevailing thinking among many people in the project management profession is that, by definition, “project management” is defined as managing projects using a traditional, plan-driven approach and anything else isn’t really “project management”
  • There also many well-established stereotypes, myths, and misconceptions to overcome. For example, one of them is that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” and you need to force-fit your projects and business environment to one of those extremes rather than going in the other direction and fitting the methodology (or combination of methodologies) to the project and business environment

There are obviously some big transformations needed in this area to shift people’s thinking:

  • We need to see “Agile” and “Waterfall” in a fresh new perspective as complementary approaches rather than competitive
  • We also need see “Agile versus Waterfall”  from the perspective of a continuous spectrum of approaches from heavily adaptive at one extreme to heavily plan-driven at the other extreme with lots of alternatives in between rather than a binary and mutually-exclusive choice between two extremes
  • Project Managers, and the project management profession as a whole, need to take a broader view of what “project management” is that embraces Agile as well as traditional plan-driven project management
  • And, Project Managers also need to see “project management” in terms of producing results and not just managing projects and using whatever methodology (or combination of methodologies) is needed to produce the results as effectively and efficiently as possible

I think you will agree that is a very tall order and a daunting challenge but that is exactly the challenge I have taken on in the Agile Project Management curriculum I’ve developed.  Check it out here:

Agile Project Management Academy

What is an Agile Project Manager?

I’ve participated in some discussions recently that indicate that there is still a lot of confusion and controversy about what is an Agile Project Manager is. It’s understandable why this confusion exists:

  • There have been some very strong stereotypes built up over many years of what “project management” is and what a “Project Manager” is.  Those stereotypes are centered around the belief that “project management” is limited entirely to traditional plan-driven project management and project managers are so heavily engrained into that way of thinking that they can’t possibly adapt to an Agile environment.
  • PMI has made a step in the right direction by introducing the PMI-ACP certification.  That certification at least recognizes Agile as a legitimate form of project management but PMI has never really defined exactly what an “Agile Project Manager” is and what role he/she might play in the real world.
  • Many people think of Agile in a very narrow sense as limited to simple, single-team Scrum projects; and, because there is no “Project Manager” role defined at that level, they assume that there is no role for Agile project management at all in an Agile environment; however, there is more to Agile than simple, single-team projects.

In order to better understand what “Agile Project Management” is, we need to get past these stereotypes and develop a broader vision of what “project management” is, what “Agile” is, and what an “Agile Project Manager” is.

First, we need to recognize that the discipline of ”project management” isn’t limited to traditional, plan-driven project management with an emphasis on planning and control just because that’s the way project management has been typically practiced for many years.  There is actually a lot of “project management” going on in an Agile project although it may not look like the traditional, narrow view of what project management is at all:

  • It’s a different style of project management with an emphasis on taking an adaptive approach to maximize the value of the project in an uncertain environment rather than the traditional emphasis on planning and control; however, if you take a broader view of what “project management” is, it is still project management.
  • And, although you may not find anyone with the title of “Project Manager” at a team level in an Agile project, there’s a lot of project management going on – the project management functions that would normally be performed by an individual with the title of “Project Manager” have just been distributed among the other members of the team:
    • The Product Owner has a lot of responsibilities that might be performed by a project manager in a traditional plan-driven project.  He/she is responsible for the overall successful business outcome of the project which means delivering a valuable product in a timely and cost-effective manner and making all decisions that would normally be done by a Project Manager for risk management as well as planning and managing the overall effort.
    • The Scrum Master also has some responsibilities that might be done by a project manager including removing obstacles and facilitating the project team.  It may be a different style of leadership, but it is still leadership.
    • And, finally every member of the development team has some project management functions on a very small scale for planning, scheduling, tracking, and reporting on their own work as well as the work of the team as a whole.

A related stereotype is that many people think that there is a binary and mutually exclusive choice between “Agile” and “Waterfall” and try to force-fit their projects to one of those extremes when a better approach is to go in the other direction and fit the methodology to the project.  And, “Agile” and traditional plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two.  There are many projects that call for blending those two approaches in the right proportions to fit a given situation particularly as you get into larger, more complex, enterprise-level projects.

So what is an “Agile Project Manager”?

In my opinion, an Agile Project Manager is equally trained and skilled in applying both Agile and traditional plan-driven project management principles and practices and knows how to blend them together in the right proportions to fit a given situation.  That is exactly what the training I’ve developed is all about – it is designed to:

  • Help people see “Agile” and traditional plan-driven project management in a fresh new perspective as complementary rather than competitive, and
  • Help project managers better understand what “Agile Project Management” is and what they need to do to prepare for it

So What role might an “Agile Project Manager” play in a real-world project?

I think it’s sad that some project managers see there only alternative in an Agile environment is to become a Scrum Master because the role of an Agile Project Manager is so ill-defined and poorly-understood.  I hope that the Agile Project Management training curriculum I’ve developed can help project managers see this new perspective and lead the rest of the profession into demonstrating successful Agile Project Management leadership. In my training, I’ve identified several potential roles that an Agile Project Manager might play:

  1. Team-level Role – There is officially no role for an “Agile Project Manager” at the team level in an Agile project; however, a project manager who is skilled in blending Agile and traditional plan-driven project management principles and practices can play a real value-added role as either a Product Owner, a Scrum Master, or an Agile Coach
  2. Hybrid Agile Role – For lots of reasons, companies choose to implement a hybrid Agile approach and this is an ideal environment for an Agile Project Manager to work in. An example would be an Agile contracting situation.
  3. Enterprise-level Role – As projects grow in scope and complexity to an enterprise level, there is a much more significant need for a dedicated Agile Project Manager role. As an example, I did a case study in my latest book on a project at Harvard Pilgrim that involved over 100 Agile teams – you just can’t do an effort like that without some form of project/program management

My training includes much more detail on this and several real-world case studies illustrating each of these roles.

What’s Next After Agile?

I recently saw a discussion on another forum where an individual raised the question of “What’s next after Agile?” and someone speculated that the next big methodology might be Lean.  I’ve also seen some people suggest that Kanban will become the next big methodology.  I’ve seen this pattern before – I call it the “Program Du Jour” pattern.  Here’s one of my favorite quotes on this subject:

“Americans are our own worst enemy when it comes to new business concepts. We love novelty and newness. We become so enamored with new ideas, we burn through them the way a child rips through toys on Christmas morning – squeals of delight, followed by three or four minutes of interest, then onto the next plaything. That is our pattern with new management techniques, too.

Barry Sheehy, Hyler Bracey, & Rick Frazier, Winning the Race for Value, American Management Association, 1996

The above quote was about business concepts and management techniques but the same thing can be said about methodologies.

Here’s an example – when Six Sigma came into vogue in the 1990’s and early 2000’s, it was really hot, everyone wanted to jump on the Six Sigma bandwagon, and any other earlier process improvement approach was considered obsolete and passé.  I published my first book on Business Excellence in 2003 and I interviewed a number of companies for my book at that time.  What I saw was that:

  • Many companies were doing Six Sigma very superficially and mechanically. In these companies there was a lot of “hoopla” and very visible ceremonies about Six Sigma including Black Belts, Green Belts, etc.  The implementation in many of these companies was not very successful because the company was looking for a “silver bullet” and when it didn’t meet their expectations, the company tossed it out and started looking for the next “silver bullet”.
  • In other companies where I thought Six Sigma was more successful and lasting, there was a big difference.   Six Sigma was seen only as a tool and not a “silver bullet” or panacea,
    people in the company understood Six Sigma at a deeper level, and the implementation was not just mechanical and superficial.   Six Sigma was so well-integrated into the way the company did business that it might not even have been very visible that it was Six Sigma and they might not even have called it “Six Sigma”

I see a similar pattern with Agile today.  Many people today see “Agile” as a “silver bullet” or panacea for almost any problem you might have; in many cases the implementation of Agile is superficial and mechanical; and, when it doesn’t work, there’s a tendency to toss it out and look for something new to replace it.  I think that kind of thinking has some serious flaws.

Rather than Agile being replaced by something new, what I hope that will happen is that:

  • People’s understanding of Agile will mature, they will start to understand the principles and values behind it at a deeper level, and they will go beyond superficial and mechanical implementations
  • People will stop seeing Agile as a “panacea” or “silver bullet” for any problem you might have and rather than force-fitting all problems to some particular methodology like Agile, they will recognize the need to go in the other direction and fit the methodology to the problem
  • People will also recognize that “Agile” does not make all other management approaches obsolete and passé and:
    • There’s a need to see Agile and more traditional plan-driven approaches in a fresh new perspective as complementary rather being competitive
    • Various Agile approaches such as Scrum, Kanban, and Lean are also complementary to each other rather than competitive

This is exactly the kind of thinking I’ve tried to help people develop in the curriculum in the new Agile Project Management Academy.  To learn more about that, you can check it out here:

Agile Project Management Academy

Agile Project Management Academy

I am very pleased to announce the opening of the Agile Project Management Academy! The Agile Project Management Academy is an online school that is dedicated to helping project managers and other students learn how to successfully integrate Agile and traditional plan-driven project management principles and practices in the right proportions to fit any situation and to develop a very high impact and adaptive project management approach that provides the best of those two worlds.

You can enroll in the Agile Project Management Academy at no charge by clicking this link. There is no obligation to purchase a course if you enroll in the school and enrolling in the school will keep you informed of new courses and discount offers that become available. You can also enroll in either of these two free courses to try it out with no obligation:

Any of my Udemy students will recognize the courses in the Agile Project Management Academy as courses that have been offered on Udemy that have drawn over 10,000 students and over 300 5-star reviews. I will continue to offer these courses on Udemy; however, offering these courses through the Agile Project Management Academy creates some new opportunities that were not available on the Udemy platform. The new platform provides:

  • A dedicated focus on Agile Project Management that will help students realize the full benefits of these courses in a much more integrated environment
  • More ways for students to take courses including bundled discounts and subscriptions
  • Much more capabilities for direct communication with students to create a more interactive learning experience
  • The ability to integrate courses from other providers with my own courses to provide a more complete learning experience
  • Better and more timely support for students

I hope you enjoy this new capability! I am very excited to make it available! Enrollment in the school is free and anyone who registers in the school will receive email updates of new courses as well as enhancements to existing courses. You can enroll in the school at no charge here:

Agile Project Management Academy

You can find a summary of the courses that are offered as well as some discount coupons for all of the courses here:

Course Summaries and Discount Coupons

Please send me an email if you have any questions or comments on this new capability:

Send email to Chuck

For any student who has previously purchased one of my courses through Udemy, I will be happy to provide access to the equivalent course in the new Agile Project Management Academy at no charge. If you would like to take advantage of that offer, just send me an email.

My Methodology is Better than Your Methodology

There are a lot of people who get caught up in what I call “methodology wars” where they are intent on their position that my methodology is better than your methodology and whatever methodology they advocate is better at solving any problem you can possibly imagine than any other methodology. You can see this in the many “agile versus waterfall” discussions and other discussions where SAFe, Kanban, or some other methodology/framework is positioned as a “silver bullet” for any problem you might have. They also tend to ignore all other methodologies as obsolete or irrelevant.

The truth is that all methodologies and frameworks have strengths and weaknesses depending on the situation and the right approach is to fit the methodology to the situation rather than force-fitting a problem to some pre-defined methodology. Sometimes that may require customizing a methodology to fit the problem and/or using a combination of elements from different methodologies. It’s a lot more difficult to do that, but it can be done – it requires:

  • Knowledge of a broader range of methodologies and frameworks,
  • Ability to see the strengths and weaknesses of those methodologies objectively, and
  • A deeper understanding of the principles behind those methodologies to know how they might be combined to fit a given situation

Here’s an example – I just finished adding some material on “Lean Software Development” to my online training courses on Agile Project Management.  Lean is not widely-used as a standalone methodology and it clearly didn’t win the “methodology wars” but the principles behind lean are the foundation for all Agile methodologies including Scrum.  If you look at the principles behind lean, they may appear to be at odds with other Agile methodologies:

  • Lean heavily emphasizes eliminating waste in a process to improve efficiency, while
  • Agile is more heavily-focused on taking a flexible and adaptive approach to meet customer needs and is less concerned about just eliminating waste

If you pursued each of these goals in isolation and to an extreme; they might be in conflict with each other, but if they are blended together in the right proportions to fit a given situation, they can be very complementary rather than competitive.

Here’s another example – many people seem to believe that all forms of traditional project management are obsolete and irrelevant and have been totally replaced by Agile.  On the surface; if you look at traditional, plan-driven project management and Agile, they may appear to be at odds with each other; and if each approach is pursued in isolation and to an extreme, they probably will be in conflict but that shouldn’t preclude blending the principles behind the two approaches together in the right proportions to fit a given situation.

This kind of thinking is commonly called “Systems thinking” – it requires seeing a problem in a holistic context and understanding the dynamics of the problem at a deeper level rather than mechanically imposing a predefined solution on a given problem.  This is the kind of approach I’ve tried to help students develop in all of my online Agile Project Management training courses.

Scaling Agile and Scrum for Large, Complex Projects

There is a lot of confusion and some fairly polarized opinions about scaling Agile and Scrum for large, complex projects involving multiple teams.

  • Some people think that it can be done simply by adding a Scrum-of-Scrums approach to provide a mechanism to coordinate the efforts of multiple teams.
  • A more comprehensive approach for integrating the efforts of multiple development teams is Large-Scale Scrum (LeSS). A Scrum-of-Scrums approach is a loosely-coupled approach that only provides for basic coordination of the work between teams – each team still operates fairly independently. LeSS is a much more tightly-coupled approach that goes beyond the very basic level of coordination of work that the Scrum-of-Scrums approach provides.

The table below shows a comparison of the two approaches:

Scrum-of-Scrums LeSS
Coordination of Work Formal Scrum-of Scrum’s Meeting Informal, “Just Talk”
Product Backlog Management
(Single or Multiple Backlogs)
Not Specified Single Product Backlog
Sprint Planning
(Separate or Joint)
Not Specified Joint
Sprint Review
(Separate or Joint)
Not Specified Joint
Allocation of Work
(Component or Feature)
Not Specified Feature

The right approach will depend on the project and the need for a more loosely-coupled or tightly-coupled approach for integrating the development efforts. However, both of these approaches only address integration of the teams from a technical, development perspective and do not explicitly provide any mechanism for integration of the efforts from a business perspective. It is assumed that the normal Product Owner role provides that level of integration but that may not be very realistic for very large, complex projects. This is really a multi-dimensional problem as shown in the diagram below:

Agile Scaling Dimensions

The Scaled Agile Framework (SAFe) and other enterprise-level Agile frameworks recognize the need to provide this level of business integration with an appropriate level of program management and/or product/project portfolio management to ensure that the development efforts are well-integrated and well-aligned with the company’s business strategy.

Enterprise Agile Scaling Frameworks

There is a lot of confusion and conflict in this area:

  • A number of people who see this from a development perspective tend to think that SAFe and other enterprise-level frameworks that address the problem of business integration are just unnecessary overhead and bureaucracy
  • Many people who see this from a business strategy perspective don’t understand the need for integrating development efforts from a technology perspective

There are three major challenges that need to be considered:

  1. Integrating the efforts of multiple teams from a development perspective
  2. Aligning the efforts of all teams with the organization’s business objectives
  3. Coordination with other related efforts outside of the project team and providing tracking and progress reporting to management

Both the development integration perspective and the business integration perspective have merit and need to be considered when scaling Agile/Scrum to large, complex projects and all of the above challenges may need to be addressed to make a large, complex, multi-team Agile project successful.

 

The New PMI PDU System

The New PMI PDU System has raised a number of questions. As many people may know, PMI has recently announced some significant changes in the process for claiming and reporting PDU’s. This new change went into effect on December 1, 2015. With this new change, PDU’s need to be split into three different categories:

  • Technical
  • Leadership
  • Strategic & Business Management

In addition, each major certification (e.g., PMP, PMI-ACP) requires you to achieve a certain number of PDU’s in each of these categories in order to renew your certification (Total number of PDU’s is no longer sufficient).

I applaud this change. It is going in absolutely the right direction to elevate the project management profession and is very much in line with the direction I’ve been developing in my own courses. The thinking behind this change is that a project manager can no longer be just a technical administrator who manages project plans and schedules and that sort of thing. The essence of this change is that, in addition to that kind of technical project management role, a project manager must also have:

  • Strong leadership skills (not just simply coordinate resources from a variety of functional departments) and
  • Be able to play a value-added role that connects projects with driving strategic business goals (not just simply meeting project requirements and controlling budgets and schedules)

It’s very apparent to me that we are in the midst of a major transformation of the whole project management profession and you can see this clearly with Agile:

  • The role of a project manager at the team level in a true Agile environment does not exist anymore in many environments, and
  • If there is a role for a project manager, at all, in an Agile environment, it is a very different kind of role and may be at a higher level that requires strong people leadership skills as well as the ability to help define a project management approach that is well-aligned with the company’s business

These are exactly the challenges I have tried to address in all of my courses to help the project management profession move in this direction!  All of my courses are eligible for PDU’s and you can find more information on all of my courses at the following location:

http://managedagile.com/training-courses/

How to Prepare for PMI-ACP Certification

I think there is a lot of confusion among project managers about how to prepare for PMI-ACP certification – some people may think that:

  1. Getting PMI-ACP certification is a matter of buying an “exam prep” book or taking an “exam prep” training course and then going out and taking the exam, and
  2. Once you’ve taken and passed the exam, that is your “ticket” to get a job working in an Agile environment as a project manager

Both of those assumptions are far from reality, in my opinion:

  1. You can’t just do some “exam prep” training and/or buy an “exam prep” book and go out and pass the exam for several reasons:
    • PMI won’t allow that – PMI requires a  minimum of 1,500 hours of working in an Agile environment before you can even apply to take the exam
    • There’s such a broad range of topics on the exam, it would be very difficult or impossible to pass the exam for someone who just “crammed” to pass the exam with little or no real-world Agile experience
    • Even if you could do that, simply “cramming” to pass the exam would have very limited value because it would have little credibility without some real-world experience to go along with it
  2. Just getting a PMI-ACP certification is not likely to be a “ticket” to getting a job as a project manager in an Agile environment for a  couple of reasons:
    • PMI-ACP is just a test of general Agile and Lean knowledge – it’s not designed to test your ability to perform a particular Agile role
    • The role of an Agile Project Manager is not well-defined and there is also some controversy that there is a role for a project manager in an Agile environment at all

I think it’s a mistake for anyone to think that getting PMI-ACP certification is just a matter of going out and passing the exam and getting a job in an Agile environment and people have to develop more realistic expectations about it.  I recommend:

  1. Understand the roles that an Agile Project Manager can potentially play in the real-world, develop a vision for yourself of what that target role is, and understand the overall “road map” for moving into that role.
  2. Understand how PMI-ACP relates to other Agile certifications and where it fits into that road map.  For example, a project manager who is new to an Agile environment may have to start out in a Scrum Master role to get some experience and PMI-ACP isn’t the best approach to become a Scrum Master – CSM or PSM is much better-suited for getting into that kind of role as a first step
  3. Don’t limit your focus to simply passing the exam – focus on developing solid, credible, real-world experience and use the PMI-ACP certification exam to validate that you do have the knowledge and experience needed to perform that role

I’ve just developed a new training course for project managers called “How to Prepare for PMI-ACP Certification” that elaborates on this to help project managers develop a strategy for themselves and helps them understand how to position my other Agile Project Management courses in this strategy.  You can find information on this course and my other Agile Project Management courses at the following location:

How to Prepare for PMI-ACP Certification

For a limited amount of time, I’m offering this course for only $5!

How Do You Go About Selling Agile?

A student in one of my courses asked if I could help him develop a short and succinct way of “How Do You Go About Selling Agile? I think it’s an excellent topic and I told him I would write up something on that. Here it is…

First, I don’t think that anyone should start with an objective of “selling Agile” to anyone. There are a lot of people out there who try to do that and I think it is fundamentally the wrong approach to try to convince someone to become more Agile rather than focusing on how becoming more Agile will help them and what problem it will solve.

I also very strongly believe that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”; and, rather than attempting to force-fit a business or project to one of those extremes, you have to go in the other direction and fit the methodology (whatever it might be – Agile or plan-driven or some combination of both) to the situation. It takes a lot more skill to do that but it definitely can be done. It requires:

  • A broader knowledge of different methodologies (both Agile or adaptive and plan-driven) and an ability to see past many of the stereotypes, myths, and misconceptions that exist about what’s commonly referred to as “Agile” and “Waterfall” to see those two approaches in a fresh, new perspective as being complementary to each other rather than competitive and to objectively understand the strengths and weaknesses of both approaches
  • The ability to take a “systems thinking” approach to see those methodologies in a broader context beyond just a development process perspective of how they relate to an overall business and what problems they might solve
  • In addition to all of that, you also need to understand the principles behind the methodologies at a deeper level (rather than just the mechanics of how to perform the methodology) to understand how to blend different, seemingly disparate methodologies together as needed to fit a given situation

I’ve developed a set of online training courses that are specifically designed to help prepare people for those challenges, you can check that out here:

Agile Project Management Training Courses

However, if you’re trying to “sell” a manager on becoming more agile, he/she probably doesn’t have all of those skills and they’re probably not willing to sit through a series of training courses to develop those skills either; so, how do you develop a relatively simple “elevator speech” to help someone understand why they should even consider becoming more Agile?  Here are some thoughts on that:

  1. First, you have to look at it from an overall business perspective , not from a more limited development process perspective. It’s very easy to get “tunnel vision” with Agile – we get so enthusiastic about the benefits of Agile from a development process perspective that we assume that what’s good for the development process must be good for the company as a whole and that’s not necessarily the case. Rather than attempting to force-fit a company to an Agile approach; you may have to craft an approach that is more well-aligned with the primary success factors that drive the company’s business and becoming more Agile may or may not be the most important factor in the company’s overall business success.
  2. Second, you have to recognize that some companies are scared to death of Agile – they’re afraid of losing control and that fear is not totally unfounded if the Agile approach is not well-designed and managed. So, you may need to start off with more of a hybrid approach as an initial first step to demonstrate success rather than going full-bore into a complete corporate Agile transformation. You also need to recognize that an Agile transformation can take a long time and demands a lot of patience and perseverance.
  3. Finally, nothing sells better than results. Work on developing good results and that will sell itself.

Although the benefits of adopting a more agile approach will vary from one company to another, there are some general benefits that apply, to some extent, to any company. Here are the key general benefits I would focus on in my “elevator speech”…

  • Adaptability – The biggest and most general benefit is adaptability – regardless of whatever other benefits an agile approach might provide, no one is likely to argue that there’s a big advantage in being able to tailor an approach to fit a project and a business rather than force-fitting all projects to a traditional, plan-driven project management approach
  • Time-to-market – Probably the next most important general benefit is time-to-market – a lot of people have the impression that an Agile project is always faster and that’s generally true but not always true. The real emphasis in Agile, in my opinion, is keeping the customer closely-engaged with the project as it progresses to ensure that what you’re developing really meets their needs. Sometimes that may actually take longer because it may involve some trial-and-error. However, very few people could argue that prioritizing requirements and delivering functionality incrementally rather than waiting to deliver the entire project all at once can significantly accelerate progress even if you don’t take a full Agile approach.
  • Reduced Costs – Another big factor is reduced costs associated with reducing unnecessary overhead in projects. This is another one that doesn’t require adopting a full Agile development approach to achieve – all it requires is taking a hard look at some of the documentation and other artifacts and controls used in a project and deciding whether they really produce value or not and who they produce value for.
  • Customer SatisfactionFinally, as I’ve mentioned, the big selling point of Agile is the improved customer satisfaction you get from having a customer directly engaged in the project to ensure that the project really solves their business problem and provides an appropriate level of value to them

The key point to emphasize is that all of these are relatively tangible benefits that can be realized, to some extent, on any project simply by using more of an “Agile Mindset” and it doesn’t necessarily require adopting a full-blown textbook Agile approach like Scrum and/or risk losing control of your business to get some of these benefits. Also, in addition to those more tangible benefits, there are also a lot of intangible benefits such as:

  • Improved employee productivity and morale that results from more empowered teams
  • Improved organizational synergy that results from higher levels of collaboration, trust, and shared responsibility within the organization

I want to add one note to this post that came out of some follow-up discussions we had on LinkedIn on this post…The word “selling” has a variety of different connotations. Some people regard “selling” as a manipulative process to convince someone to buy something they don’t want (like life insurance or used cars).

Years ago when I was a Program Manager in a large computer company, part of the training to become a Program Manager was a course called “Solution Selling” which was basically a consultative approach to “selling”. It created a different approach to “selling” – instead of going in to a client to sell them something like “Agile”, the “solution selling” approach is to go in to the customer and do a lot active listening to understand their problem before attempting to sell any solution. I think that’s the right approach with Agile also. There are people out there who get overly-zealous about “selling” Agile to the extent that “Agile” becomes a solution to any problem you might have. That’s the wrong approach, in my opinion.

Agile Contracts

A lot of people may think that it is inconsistent to impose constraints that the project needs to be completed within a certain expected cost and schedule on an Agile project. It is difficult, but it definitely can be done – one of the areas where that becomes essential is Agile contracts. For example, I once managed a large federal government project that had all the typical government contracting requirements for cost and schedule milestones; but, at the same time, the government customer wanted some level of flexibility to work out detailed requirements as the project progresses.

Does that sound inconsistent? It might be depending on the relationship you have with the customer. Obviously, this will only work if there is a spirit of trust and partnership with the customer to collaboratively agree to work out any tradeoffs between the scope of the requirements and the cost and schedule of the contract as it progresses. If there is more of a typical “arms-length” contracting relationship or some kind of adversarial relationship, it’s not going to work at all.

Doing this requires a hybrid Agile approach that blends an Agile development approach with a plan-driven “shell”. The plan-driven shell provides some level of predictability and control over the overall scope, cost, and schedule of the project while the Agile development approach operates within that shell to provide some level of flexibility and adaptivity in the detailed requirements. That approach is described in more detail in my article on the “Managed Agile Development Framework“.

Jeff Sutherland has created a very nice model for this called “Money for Nothing, Change for Free”. Jeff’s approach is based on two primary clauses in an Agile contract:

  • “Change for Free”

    The “Change for Free” clause is based on the idea that the customer can make any change they want provided that the total contract work is not changed. This allows new features to be added provided that lower priority items are removed from the project. I have documented a case study in my book on how General Dynamics, UK successfully used this approach on a large government contract in the UK.

  • “Money for Nothing”

    The “Money for Nothing” clause is interesting. It recognizes the fact that in many projects, the customer always asks for everything that they could possibly need but if you prioritize those items and deliver the highest priority items first, at some point you will reach a point of diminishing returns where the cost of developing incremental features exceeds the value that those features provide. This clause allows the customer to cancel the contract at that point and save 80% of the cost that would have been spent to complete the remaining items; however the contractor receives a fee of 20% of the cost for early cancellation which makes it a win/win for both the customer and the supplier.

This concept is not limited to fixed-price contracts – that’s only the extreme case. It can be applied to almost any Agile project where there is a need for some level of predictability and control over the costs and schedule of the project. Very few people get a “blank check” to do an Agile project without any expectations of what will be delivered and what the estimated cost and schedule of the project are likely to be.