Using Agile for Non-Software Projects – Agile Home Remodeling

A number of my students have requested some case studies that show applying Agile to non-software projects. As an example, I recently completed a home remodeling project which may seem simple and trivial; but believe me, it was not.

Agile for Non-software Projects

Using Agile for Non-Software Projects

It is possible to apply Agile to almost any project but that doesn’t necessarily mean using Scrum. And, it certainly doesn’t mean just going through the rituals of doing Scrum mechanically. Applying Agile principles and figuring out how to apply them to non-software projects can be very challenging.

Background

I have been a project manager for a long time. I’ve managed large, complex multi-million dollar projects; but nothing compared to a recent project to do a major remodeling of the kitchen in our house. The project involved:

  • Knocking down a wall that separated the kitchen from the rest of the house to create a more open environment
  • Ripping up the concrete floor to re-route electrical and plumbing connections
  • Replacing all of the existing kitchen cabinets and appliances
  • Installation of new lighting fixtures
  • Moving the entrance-way to the master bedroom to be more consistent with the new floor plan
  • Removing a pantry and replacing it with a new pantry cabinet which required knocking down a wall and moving an intercom system
  • Repainting the entire area and many other cosmetic enhancements

Agile Home Remodeling – Why was this project so difficult?

  • My wife was the major stakeholder in the project, she is a perfectionist, and she has a habit of changing her mind frequently about what she wants. (Her response to that is “She doesn’t change her mind, she just decides as she goes along”)
  • Multiple outside contractors did all of the work in this project
  • A major challenge was to try to manage the costs and schedule of this project within reasonable levels

Agile Contractor Selection

The first task was to select a contractor (or contractors) to do the work. I had several choices:

Contractor “A”

Contractor “A” was the most widely-known contractor in this area. They advertise widely on television and have a good reputation for delivering a high-quality result. They would also take full responsibility for the overall solution. However, their approach is fairly rigid and controlled. Once you sign a contract with them, it is very difficult to make any changes.

Contractor “B”

Contractor “B” was much less widely-known but offered much more flexibility and willingness to work with on a design that was customized to meet our needs. They would also take overall responsibility for managing the overall solution.

Contractor “C”

Contractor “C” offered the most flexibility to meet our needs but was actually two different contractors. It was not really possible for either of them to take overall responsibility for the overall solution

  • One contractor did the demolition and prep work including electrical and plumbing to prepare the new kitchen
  • Another contractor provided the kitchen cabinets and counter-tops. They installed them after the initial demolition and prep work had been completed
  • Following the installation of the cabinets and counter-tops, the original contractor returned to do the finish work. That work included final installation of new lighting fixtures and repainting of the entire area

Choosing a Contractor

Selecting a contractor was difficult:

  • Contractor “A” was probably the lowest risk choice from a traditional project management perspective. It would require less management on my part but offered little flexibility to adapt the solution to meet our needs
  • Contractor “C” was the highest risk and involved coordinating the work of two different contractors. However, they offered the most flexibility to meet our needs
  • Contractor “B” was a compromise between those two extremes. They had the advantage that they were a single contractor who would take overall responsibility for the solution. However, their costs were considerably higher than Contractor “C”

Final Contractor Selection

We chose contractor “C” because flexibility and adaptivity to meet our needs was so important; even though contractor “C” had the highest risk and might be the most difficult to manage. However, these two contractors had a history of working together successfully on other similar projects. I also had a good feeling that I could trust and partner with these individuals to manage the overall solution. That was a key difference:

  • With contractor “A”, we would have relied on a very clear and well-defined contract to deliver the solution. However, we would have little or no flexibility to make changes (That’s what many people might call “Waterfall”)
  • Contractor “C” had a statement of work but it was understood to be flexible and subject to change. The relationship relied on a spirit of trust, partnership, and collaboration (This relationship was much more similar to Agile)

How Did the Project Work Out?

This was a difficult effort to manage.

The scope of the project changed numerous times

My wife decided that we couldn’t remodel the kitchen without replacing all the living room furniture and carpets. And, of course, other changes to the rest of the house became necessary as well which included:

  • Repainting the master bedroom,
  • Replacing pictures and reupholstering other furniture. and
  • Enhancements to other areas of the house

Nailing down the design requirements was very difficult

As I mentioned, my wife changes her mind frequently, and insists on perfection in the end-result. We looked at many different kinds of granite counter-tops and many different floor tiles before making a final selection. There were also many times when a “final selection” changed before it really became a “final selection”

This Was a Project Management Nightmare

This was not a large project but it was one of the most difficult ones that I have ever had to manage. For a traditional plan-driven project manager, this would have been a nightmare attempting to control all of these changes. It is also very challenging to be caught in the middle between a very demanding stakeholder and contractors who have to deliver the work within a given cost.

However, this is a perfect example on a small scale of what an Agile Project Manager has to do. You have to learn how to balance flexibility and adaptivity to maximize the business value of the solution with some level of planning and control,

What Were the Results?

The project turned out to be enormously successful

  • The whole project was completed in a little over three weeks from the time the work started
  • It went over the budget that that we expected to spend but the costs were still at a reasonable level
  • Most importantly, my wife was delighted with the way it came out and she is the most important stakeholder I needed to satisfy.

Finished Result

Here’s a picture of what the finished kitchen looked like:

The New Finished Kitchen

Work-In-Progress

Here’s a couple of pictures taken during the work-in-progress leading up to finishing the kitchen:

Tearing Down the Wall to the Old Kitchen
Ripping Up the Concrete Floor to Re-route Plumbing and Electrical

How Does This Apply to a Business Situation?

I know this is an unusual situation but I like to use unusual situations. I think it encourages “out-of-the-box” thinking rather than viewing standard, stereotypical Agile case studies. The following is a summary of how I think these lessons-learned can be applied to a business situation:

Contractual Relationships

Most businesses could not survive without some kind of contractual relationships with outside contractors. In addition, many businesses have significant supply chains that are critical to the success of their business.

  • Typically, a firm, fixed-price contract and a competitive bidding process among multiple bidders is used to get the lowest possible price.
  • That is a relatively low-risk approach from a cost-management perspective but doesn’t necessarily result in the best overall solution.
  • When there is a lot of uncertainty in the requirements, a different approach is needed to maximize the business value of the solution. It requires a collaborative partnership with a contractor to work together to maximize the value of the solution is essential

Trust

Developing that kind of relationship with contractors requires trust. For that reason, it will not be possible to develop that kind of relationship with just any contractor. That’s why it is important for a business to have strong relationships with a selected number of contractors who can be regarded as close partners.

Risk Management

I took a risk by going with contractors that I thought were the highest risk from a project management perspective. However, that risk paid off in terms of the overall quality of the solution. A similar thing is true in a business environment. Many times you have to take a risk to maximize the value of the solution.

Productivity

The project was completed in a very short time once the work was started. That was largely due to the fact that I empowered the contractors to get the job done the best way they knew how and I didn’t attempt to micro-manage what they were doing. Conventional project management might attempt to more directly manage the work being done.

Overall Summary

Here are some of the important conclusions and lessons learned from this project about applying Agile to non-software projects:

  • Agile principles and values can be applied to some extent to almost any project. However, it requires some skill to interpret these principles and perhaps combine them with traditional project management practices.
  • The overall value that the project delivers is what is most important. The key stakeholder determines “value”. Cost and schedule goals have some value but are only one component of value and not necessarily the most important,
  • A spirit of trust and partnership is important even in a contractual situation. Over-dependence on a traditional contractual relationship can severely reduce flexibility and impact the value that the solution provides.
  • Risk management is important but attempting to minimize and over-control risk can also impact the value of the solution. Taking risks may be necessary to maximize the value of the solution.

Additional Resources

For another example of applying Agile to non-software projects, check out this article:

You will find much more detail on this in my Online Agile Project Management Training.

Why Is Planning Difficult? Is It a Waste of Time?

Why Is Planning Difficult?

Why is planning difficult? A lot of people seem to think that planning is very difficult and some think it is a waste of time because even very well-thought-out plans often don’t work out as expected. This issue is important because it is at the crux of selecting a methodology and planning approach for a project. Do I use Agile or plan-driven (aka Waterfall)?

Why Is Planning So Difficult?

Many people seem to think of planning as an “all-or-nothing” proposition – either you develop a highly-detailed plan or you do no planning at all. I don’t believe that to be the case. There seems to be two major problems associated with why people have this difficulty with planning:

Dealing With Uncertainty

Many people seem to have difficulty dealing with an uncertain environment – they want things to be crystal-clear, black-and-white and, in an uncertain environment, they think that it is a waste of time to do any planning at all.

Unrealistic Expectations

A related factor is that many people develop unrealistic expectations about planning.

  • If you develop a well thought-out plan, they expect that it should work every time.
  • Many people are also unrealistic that everything about a project will go absolutely perfectly all the time and
  • Murphy’s Law often contradicts that belief.

Planning Fundamentals

Let’s review some fundamentals about planning. We can learn a lot about how the military does planning.

Planning in the Military

Here are a few of my favorite quotes on planning in the military:

Plans are nothing; planning is everything”  – (Dwight D. Eisehhower)

What Eisenhower is saying is that documented plans should not be considered to be sacrosanct. When people document a written plan, the plan often takes on a life of its own and it becomes the “gospel” that everyone is expected to follow rigidly. However, that should not be the case and that’s not a reason to not do any planning at all. Here are a couple of examples:

  • It would be foolish for a military unit to go into battle without doing any planning at all. You should take advantage of whatever intelligence you might have about the enemy positions (as uncertain as it might be) but you shouldn’t lose sight of the uncertainty in that information.
  • In an American football game (or any other sport you want to choose), the coach prepares his team for what he thinks the strengths and weaknesses of the opposing team are; but, again, that planning is based on very uncertain information and lots of assumptions.

Here’s another quote along the same lines:

“No battle plan survives contact with the enemy”  (Helmuth von Moltke the Elder)

What Helmuth von Moltke is saying is that you shouldn’t expect that a plan won’t change at all once you start to execute it.

An Example

In World War II, Churchill and Roosevelt spent years planning the invasion of Europe that ultimately resulted in the Allied forces landing in Normandy on June 6, 1944. Both men knew that an invasion of Europe was the only way that the war could be won but there was a lot of uncertainty about:

  • Where should the invasion take place? How can the Allies preserve the element of surprise?
  • What’s the best way to do it? What are the odds of it being successful?
  • How many deaths and casualties can be expected?

This was a huge decision that had enormous impact:

  • The fate of Europe and most of the free world at that time depended on this being successful
  • Both men faced some level of opposition at home knowing the large number of casualties to be expected

It took a lot of courage to do this planning and make a decision under these circumstances knowing that there was a lot of uncertainty in the situation and the impact of the decision was so enormous. However, planning was essential – can you imagine what might have happened if the invasion was attempted without any planning at all?
Source: Churchill and Roosevelt Spent Years Planning D-Day

What Does This Have to Do With Agile?

This whole issue about planning is at the crux of the controversy about “Agile versus Waterfall”. Many people see the choice between Agile and Waterfall as a binary and mutually-exclusive choice and planning is at the center of this controversy:

  • Some people in the Agile community might say that its a waste of time to do planning in an uncertain environment and you should just use an Agile approach and let the project plan evolve as the project is in progress
  • Some people in the traditional plan-driven project management community might say that it would be foolish to attempt to do a project of any significant scope without a detailed plan for it to be successful

The truth is somewhere between those extremes – it’s not an “all or nothing” choice and you should adapt the methodology and the level of planning to fit the nature of the project. The level of uncertainty in the project is a big factor in making that choice. In an uncertain environment, it might be foolish to attempt to develop a highly detailed plan but uncertainty is never an absolute and it would be equally foolish not to take advantage of whatever information you might have.

How Do You Put This Into Practice?

A lot of people might see “Agile” and “Waterfall” as totally incompatible with each other. It’s like mixing oil and vinegar – they just don’t mix well. And, if you look at this from a mechanical process perspective, that might be true.

In order to learn how to blend these two approaches together in the right proportions to fit a given situation,

  • You have to understand both approaches at a deeper level and get past some of the strong stereotypes that exist about both “Agile” and “Waterfall”.
  • It’s really a choice of selecting a more plan-driven approach or a more adaptive approach based on the level of uncertainty in the situation and there is a whole spectrum of alternatives as shown below:
Levels of Agility

Rather than thinking of “Agile” and “Waterfall” as binary and mutually-exclusive choices and trying to force-fit a project to one of extremes, a better approach is to fit the methodology to the nature of the project and the level of uncertainty and the planning approach is a major factor in making that determination

Overall Summary

Here’s a summary of the key points I want to make in this article:

  1. Planning is not an “all or nothing” proposition
    • The planning approach should be directly related to the level of uncertainty in the environment
    • Planning in an uncertain environment can be difficult but that should not be an excuse for not doing any planning at all
    • However, to quote Eisenhower, “A plan is nothing – planning is everything” – don’t get locked into thinking that a written plan is sacrosanct and doesn’t need to be changed to adapt to the level of uncertainty in the environment
  2. The level of uncertainty and the planning approach is probably the most important factor in selecting a project management approach for projects
    • Rather than thinking about “Agile” and “Waterfall” as binary and mutually-exclusive alternatives,
    • Its more accurate and more objective to think of a spectrum of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Agile Project Management for Business Executives

I have just released a new online training course called “Agile Project Management for Executives”.

Agile Project Management for Business Executives

The Agile Bandwagon

In many areas, “Agile” is becoming a hot new buzz word and everyone wants to jump on the “Agile bandwagon”. They may not fully understanding why they’re getting into it and exactly what they expect to get out of it. In addition, many companies also make the mistake of assuming that whatever is good for the development process is good for the business as a whole and that is not necessarily the case.

Agile Bandwagon

Agile Project Management for Executives Course Summary

Agile has huge potential benefits for a business; however, it is easy to get carried away with some of the hype that exists about Agile. To avoid that, it is important to develop an objective understanding of its benefits and limitations to know how and when to apply it successfully. The right approach is to not necessarily to just implement Agile for the sake of becoming Agile, but figure out how it’s going to help your business and what problems it will solve. The typical questions and challenges this poses for business managers and executives are:

  • How do I reconcile an Agile development approach with my existing business management and project management processes?
  • Do I need to unravel all of my existing management processes in order to adopt an Agile development approach?

This course will help you answer those questions. It also includes assessment tools and planning tools that are designed to help you develop a very effective Agile Project Management approach that is very well-aligned with your business.

Intended Audience – Agile Training for Managers

There are three potential audiences for this course:

1. Senior-level Executives

The first audience is senior-level executives who want to make their business more agile. The course will help develop a well-integrated approach to fit an Agile development process to their business

2. Business Sponsors

The next audience is Business Sponsors of an Agile initiative who want to learn more about Agile Project Management. The course will help them prepare to provide more effective leadership for the initiatives that they are responsible for

3. Product Owners

The final audience is for Agile Product Owners.  Many of the people who are selected to perform that role are not well-prepared for what it requires and the role is not well-understood. The course will help them to better understand how to effectively perform the Agile Product Owner role

Why Is This Course Unique and Important?

For many years, many people have treated Agile as a development process. However, in recent years it has become apparent that the implementation of Agile as a well-integrated, enterprise-level business strategy is not well-understood.

1. Business Perspective

A lot of the Agile training that exists today is very focused on implementing Agile as a development process and on the “mechanics” of how to do Scrum. There is a relatively weak focus on Agile from a business perspective. For example, my own Certified Scrum Product Owner certification was heavily focused on the “mechanics” of how to do Scrum. It didn’t really directly address the role of the Product Owner as a business decision-maker at all.

2. Objective, Pragmatic Approach

This course is not a sales-pitch for Agile. It recognizes that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. Instead, it objectively presents Agile and traditional plan-driven project management approaches as complementary to each other rather than competitive.

3. In-depth Training

This course is not a superficial seminar on how to implement Agile. It is a very substantive, university-level course that is over four hours long. It provides a very in-depth understanding of Agile from a business perspective

4. Complementary to Agile Project Management Approach

This course is also designed to complement all of my Agile Project Management courses. Implementation of Agile at an enterprise-level requires a collaborative partnership between a business executive and a senior-level Agile Project Manager. That relationship should be based on a mutual understanding of how an Agile approach might apply to their business.

Overall Summary

Business Executives and other business-oriented people such as Product Owners and Business Analysts need to understand the fundamentals of how an Agile process work because they will likely play a critical role in its implementation.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What Are the Critical Skills of a Scrum Product Owner in Agile?

I recently participated in an online discussion on the question of “What are the Critical Skills of a Scrum Product Owner?” This is a very good question because the role of a Product Owner is not very well-understood. The actual role that a Product Owner plays can vary significantly in the real-world depending on the nature of the company’s business and the scope and complexity of the projects that the Product Owner is responsible for.

What are the Critical Skills of a Scrum Product Owner?

What Does the Scrum Guide Say?

The Scrum Guide defines the role of the Scrum Product Owner. However, it recognizes that the role varies widely across organizations. Here’s what the Scrum Guide has to say:

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

“The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:”

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed

“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

Impact of the Nature of the Company’s Business

The nature of the company’s business will have a very big impact on the role of the Product Owner. In this regard, there are two major types of companies that are most significant:

  • Product-oriented Companies
  • Project-oriented Companies

Product-oriented Companies

Product-oriented companies who are in the business of selling products to external customers are at one extreme. In those companies, a Product Owner may have the full responsibilities of a Product Manager, including product profit-and-loss responsibility.

In this world, the critical skills of a Product Owner are essentially the same as the skills of a good Product Manager

Project-oriented Companies

At another extreme, are companies that are not really in the product development business at all. The work is more project-oriented to develop projects for internal use inside the company. In that kind of environment, the role of a Product Owner is likely to be very different. What is typical in this role is the role of the Product Owner is somewhat of a combination of a “Business Analyst on steroids” and a “Project Manager on steroids”.

Scrum Product Owner versus Business Analyst Role

A Product Owner has some attributes of a Business Analyst:

  • Both have a responsibility to represent the requirements of the business solution, but the Product Owner role is much more than an ordinary Business Analyst. A Product Owner has decision-making responsibility on the requirements where a normal Business Analyst does not have that kind of authority. 
  • The Product Owner also has some attributes of a Project Manager as he/she is responsible for the successful completion of the project. That responsibility is also much more than a normal Project Manager. A Project Manager is normally responsible only for delivering defined requirements without responsibility for the overall project’s business success. 

Critical Scrum Product Owner Skills

In this world, the critical skills of a Product Owner are:

  • Business Analysis Skills – Some “Business Analyst” skills are necessary for succinctly and accurately defining requirements but also have the domain knowledge and business knowledge to be a decision-maker to determine and prioritize what those requirements should be
  • Project Management Skills – Some “Project Management” skills are necessary to make good risk-based decisions on managing the project to make it successful from an overall business perspective (not simply meeting defined requirements)
  • Overall Management Skills – Above all else, the Product Owner is ultimately responsible for the success or failure of the project from a business perspective. He is an important decision-maker and is sometimes referred to as the “CEO of the project”.

Impact of the Scope and Complexity of the Project

Beyond the nature of the company’s business discussed above, the role of the Product Owner can also vary widely due to the scope and complexity of the project.

  • At one extreme, you might have a small, single-team Agile project with a very limited scope and complexity
  • At another extreme, you might have a much larger and more complex enterprise-level project with multiple teams

Naturally, that will also have a very big impact on the role of the Product Owner.

What Does a Scrum Product Owner Really Do?

So, what does a Product Owner really do? Here’s a very good article on that subject:

The Top 10 Responsibilities of a Product Owner

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What Are the Advantages and Disadvantages of Agile and Scrum?

I have often been asked “What are the advantages and disadvantages of Agile/Scrum?” so I thought it would be useful to summarize what I believe are the most important advantages and disadvantages.

Advantages and Disadvantages of Agile/Scrum

Advantages of Agile/Scrum

1. Flexibility and Adaptivity

An Agile/Scrum approach is best-suited for a relatively uncertain environment. In that kind of environment:

  • It is very difficult, if not impossible, to accurately define the requirements and design for the solution in detail prior to the start of the project
  • Flexibility and adaptivity are essential to further define and elaborate the requirements and design of the solution as the project is in progress

2. Creativity and Innovation

In the highly competitive environment that we live in today, no one wants to buy average, run-of-the-mill products.  People expect a higher level of excellence and that requires creativity and innovation.  An Agile/Scrum approach emphasizes creativity and innovation to maximize the business value of the solution. An over-emphasis on planning and control tends to stifle creativity and innovation.

3. Time-to-Market

An Agile/Scrum approach typically results in faster time-to-market due to shorter startup times. An incremental development effort will also allow early delivery of at least a portion of the solution without the entire solution to be 100% complete

4. Lower Costs

An Agile/Scrum approach can lower the costs of a project in several ways:

  • Significantly reduced overhead resulting from reducing unnecessary documentation and control requirements
  • Higher productivity of the project team
  • Reduced “feature bloat” from using an incremental development effort and prioritizing the requirements. Using that approach, it will become apparent when the project begins to reach a point of diminishing returns where the incremental value of the features no longer exceeds the incremental development cost

5. Improved Quality

In an Agile/Scrum project, quality is an integral part of the development process rather than a sequential activity.  The developers know that quality is not “someone else’s responsibility”

6. Customer Satisfaction

An Agile/Scrum approach should result in higher customer satisfaction and more effective solutions because the customer is heavily involved in providing feedback and inputs throughout the development process

7. Employee Satisfaction

An Agile/Scrum approach should also result in higher employee satisfaction from all employees that are engaged in the effort because they are much more engaged to take responsibility for their own work as part of an empowered team

8. Organizational Synergy

An Agile/Scrum approach can improve organizational synergy by breaking down organizational barriers and developing a spirit of trust and partnership around organizational goals.

Disadvantages of Agile/Scrum

1. Training and Skill Required

An Agile/Scrum approach requires a considerable amount of training and skill to implement successfully.  Many project teams don’t fully understand the need for training and skill or don’t want to put the effort into it. They attempt to do Agile/Scrum mechanically without fully understanding the principles behind it and that is typically not very effective

2. Organizational Transformation

An Agile/Scrum approach may also require some level of organizational transformation to make it successful.  It require the business users to work collaboratively with the development team in a spirit of trust and partnership.  That may require breaking down some organizational barriers that make that difficult or impossible to do

3. Scalability

It can be difficult to scale an Agile/Scrum approach to large, complex projects.  There are some models for doing that (Scrum-of-Scrums, LeSS, and SAFe are examples) but none of those are a cookbook solution that are easy to implement.

4. Integration with Project/Program Management

An Agile/Scrum approach may not be totally appropriate for projects that require a more plan-driven approach to achieve some level of predictability. However, there are many ways to create a hybrid approach that blends a traditional plan-driven approach and an Agile/Scrum approach in the right proportions to fit the situation

Overall Summary

Agile is not a “silver bullet” and it is not a solution to every problem you might have. However, if Agile is applied intelligently in the right situations, it has huge advantages and the advantages can easily outweigh the disadvantages.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What Is Distributed Project Management? Why Does it Make Sense?

“Distributed Project Management” is a new approach to project management.   Here’s a brief overview of what it is all about.

What is Distributed Project Management?

“Distributed Project Management” is very important to help people see the relationship of “project management” and Agile in a very fresh new perspective.  It has the potential to redefine many of the heavily-ingrained notions that we have about what “project management” is.

What Is Distributed Project Management?

There are a number of people in the Agile community that believe that “project management” is not consistent with Agile. That opinion is based on:

  • A very narrow and stereotypical view of what project management is
  • An assumption that all project management functions are done by a single person called a “Project Manager”.

I think it is time to take a broader and more modern view of what “project management” is.

How Is Project Management Implemented in an Agile Team?

There is actually a lot of “project management” going on in an Agile environment, but many people won’t recognize it as “project management” because:

  1. It’s a different kind of project management, and
  2. The project management functions have been distributed among multiple people on the team

Let’s explore each of those areas individually.

1. It’s a Different Kind of “Project Management”

We need to broaden our thinking about what project management” is 

  • The traditional view is based heavily on planning and control to achieve predictability over project costs and schedules.  
  • A more modern and broader view of “project management” is based on delivering business value. 
    • That doesn’t mean that meeting cost and schedule goals is unimportant.
    • Achieving cost and schedule goals is only one component of business value and not necessarily the most important component. 
    • Creativity and innovation to maximize the value of the solution can be at least equally important

2. The Project Management Functions Have Been Distributed Among the Team

The functions that would normally be performed by someone called a “Project Manager” at the team level have been distributed among other members of the team.  As a result, you typically may not find anyone at the team level in an Agile project called a “Project Manager”.

In an Agile team, everyone on an Agile team has some kind of responsibility that might normally be performed by someone called a “Project Manager”:

RoleProject Management Function
Product Owner RoleThe Product Owner comes closest to the overall responsibilities of a project manager. However, the Product Owner role actually goes beyond a project management role. The Product Owner is expected to:
  • Take overall responsibility for the success or failure of the project
  • Make any decisions or trade-offs that might be needed to meet the project goals
Developer RoleIn an Agile environment, developers actually have responsibilities that might normally be done by a “Project Manager”. Developers are expected to:
  • Take responsibility for planning and completing the tasks that they are responsible for
  • Following through to meet commitments that they have made
  • Reporting progress and coordinating their work with other members of the team as necessary to produce an overall result
Scrum Master RoleThe Scrum Master also has responsibilities that might normally be performed by a Project Manager. The Scrum Master is expected to:
  • Facilitate the work of the team and team meetings
  • Coaching the team in Agile practices and
  • Removing any obstacles that might be impeding the team’s progress

A project manager in a traditional plan-driven environment would normally perform those functions.   A “Distributed Project Management” approach distributes these functions among multiple people.

Why Does Distributed Project Management Make Sense?

In an Agile environment:

  • Solutions can be much more complex and the level of uncertainty can be much higher. That makes it very difficult, if not impossible, to completely define a solution prior to the start of a project
  • That environment requires a much more flexible and adaptive approach

In that environment,

  • It is essential to further elaborate the requirements and the design of the solution as the project is in progress.
  • That calls for a very different approach to project management.

Distributing the project management functions among the different Agile team roles provides a much more dynamic approach:

  • Instead of centralized control where all decisions are made by a project manager,
  • Decision-making is more decentralized among the various roles on an Agile team
    • The team, as a whole, is self-organizing and empowered
    • That approach is very well-suited for an environment with a high level of uncertainty

Overall Summary

Distributed Project Management is a new way of thinking about how to do project management:

  • Instead of the normal project management functions being performed by a single person called a “Project Manager”
  • Those functions may be distributed among other roles

This approach may be threatening to many traditional project managers because, in many cases,

  • It could eliminate the role of a project manager at the team level in an Agile project, and
  • It also could require a significant adaptation for many project managers who are used to being in control of a project

For more on that check out this article on The Future of Project Management:

For the project management profession to continue to thrive, we need to recognize this fundamental shift in thinking and develop a broader vision of what “project management” is.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

How Do You Choose the Best Methodology for a Project?

I often see questions on “How do you choose the best methodology for a project?”

Choose the Best Methodology for a project

Is There a Best Methodology for a Project?

I don’t think that there is one single “best” methodology for a project that works for all projects.  A lot of people make the mistake of force-fitting a project to some standard methodology.

Traditional Plan-driven Approach (“Waterfall”)

Some project managers will try to use a traditional plan-driven methodology for a project (what many people loosely call “Waterfall”):

  • It may be the only project management approach that they know.
  • It has also been widely-accepted as the only way to do project management

Force-fitting a Project to a Methodology

Many other people have the misconception that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”. As a result, they will attempt to force-fit a project to one of those extremes

Fit the Methodology to the Project

The “best” approach is to go in the other direction and fit the methodology to the nature of the project. 

  • That takes more skill but it definitely can be done
  • You should also recognize that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”
  • There is a whole spectrum of different approaches ranging from heavily plan-driven at one extreme to heavily adaptive (or Agile) at the other extreme
Range of Agility

Factors to Consider

There are a number of factors that influence the selection of the best approach for a particular project:

1. Level of Uncertainty

First and probably the most significant factor in choosing an approach, is the level of uncertainty in the project. A project with a high level of uncertainty would be best-suited for a more adaptive (Agile) approach. Attempting to force-fit such a project to a traditional plan-driven project management approach could be disastrous.

  • It would force you to make a lot of assumptions to try to resolve the uncertainty; and, in many cases, those assumptions may be wrong and require a lot of re-planning and possible re-work
  • The emphasis on planning and control in a traditional plan-driven project is not conducive to changes. That will make it difficult to maximize the value of the solution in an uncertain environment

2. Need for Creativity and Innovation

Next, in today’s competitive environment, creativity and innovation can be very important to create very competitive business solutions. An approach with a heavy emphasis on planning and control can stifle creativity and innovation.

3. Customer Relationship

Finally, managing customer expectations is probably one of the most critical aspects of any project.  If the results of a project are not consistent with customer expectations, the project will likely not be viewed as successful no matter how good you think it is.  The nature of the customer relationship can range between:

Contractual Style of Relationship

A contractual style of relationship is where there are very definite and well-defined customer expectations that must be met.  In this type of relationship, the customer may not take any responsibility for the success of the project.  The customer defines requirements and expects the project team to do whatever is necessary to meet those requirements. In this style of relationship, there is limited participation by the customer in the project

Naturally,  the contractual style of relationship is well-suited to a project with a relatively low level of uncertainty. It must be possible to define the customer’s requirements in some level of detail prior to the start of the project.  It would be much more difficult to make a contractual-style relationship work in a project with a high level of uncertainty.

Collaborative Style of Relationship

A collaborative style of relationship is where there is a shared responsibility for the success of the project. In this environment both the project team and the customer take an active role in defining the direction of the project as it is in progress

What’s the Right Style of Relationship?

Of course, the customer has to be amenable to whatever type of relationship you choose.  If the project has a high level of uncertainty, that would lean towards more of a collaborative relationship; however:

  • The customer has to be open to that kind of relationship for it to be successful. 
  • This is a big problem in many companies where it is difficult to break down organizational boundaries between organizations
  • It requires establishing truly collaborative relationships based on a spirit of shared responsibility, trust, and partnership.

3. Project Team Capabilities

The final major factor in selecting a project approach is, of course, the capabilities of the project team.   

  • An Agile approach requires a lot of training and skill and a hybrid Agile approach  can require even more training and skill. 
  • Naturally, it does not make any sense to choose an approach that the team is not capable of implementing.

Why Is Choosing the Best Methodology for a Project Important?

There are two major factors that require us to broaden the way we think about “project management” today:

  • Solutions tend to be much more complex and the level of uncertainty is much higher
  • Competitive pressures frequently require much higher levels of creativity and innovation

For those reasons, force-fitting all projects to a standardized plan-driven approach is not necessarily the best approach for all projects.

Overall Summary

Choosing the best methodology for a project can be a difficult thing to do. It is not necessarily a simple matter of choosing Agile or Waterfall. You have to fit the methodology to the nature of the project. A project should be focused on producing value for the customer and its very important to understand what “value” means to the customer:

  • First of all, meeting cost and schedule goals is only one component of value, and it may not be the most important component of value to the customer
  • Second, there have been many projects that have met their cost and schedule goals but failed to deliver an acceptable level of business value
  • Finally, “Value” can be a very elusive goal but, in any case, it’s what the customer thinks that “value” is that counts

There is no “best” process. Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. Both have advantages and disadvantages depending on the environment you’re in:

When Does an Agile Approach Work Best?

When does an Agile approach work best? An Agile model tends to work best in projects where:

  • There is a relatively high level of uncertainty and a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
  • Creativity and innovation are needed to maximize the business value of the solution

When Does a Plan-driven Approach Work Best?

When does a plan-driven approach work best? A traditional plan-driven model (what many people loosely call “Waterfall”)  tends to work best where:

  • There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
  • The organization is not really  well-prepared to implement an Agile approach and/or the project team is not trained in Agile

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

In addition, you may also be interested in the following articles related articles:

Agile Change Management – Why Is It important?

Why is Change Management for an Agile transformation so important? Implementing an Agile transformation can require a big shift in thinking and possibly also require changing a well-established corporate culture for many companies.  That is not an easy thing to do and it requires some skill and planning to do it successfully.

The Need for Change Management in an Agile Transformation

In general many companies need to move from an excessive emphasis on planning and control to a more flexible and adaptive approach with more emphasis on creativity and innovation in a very uncertain environment.  That requires:

  • Developing a spirit of trust and partnership among all parts of the organization at every level
  • Breaking down organizational barriers that might prevent a collaborative, cross-functional approach
  • Developing a clear, unifying vision for the organization that creates a common purpose that is well-aligned with the company’s business objectives

Why Is Change Management Difficult?

Those are not easy things to accomplish and creating lasting organizational change is difficult.  People resist change and will naturally revert back to the old, comfortable way of doing things if the change management effort is not successful.

Agile Change Management

Kotter’s Change Management Principles

The best source on this is John Kotter’s book “Leading Change”. Kotter identifies eight errors that companies make in change management initiatives:

1. Allowing Too Much Complacency

This probably could be better stated…it isn’t necessarily a matter of “allowing too much complacency”. The real issue is that if there isn’t a feeling of urgency for making a significant change, it will be difficult to get support for making the change.

2. Failing to Create a Sufficiently Powerful Guiding Coalition”

Overall leadership is extremely important – all the key leaders have to be on board with making a broad-based, cross-functional change and providing the guiding leadership to make it happen.

3. Underestimating the Power of Vision

A clear vision is needed for what the organization will look like after the change is complete. If there is no vision, it will be difficult to guide the change in the right direction.

4. Under-communicating the Vision

Major change is usually impossible unless most employees are willing to help, often to the point of making short-term sacrifices. But people will not make sacrifices, even if they are unhappy with the status quo, unless they think the potential benefits of change are attractive and unless they really believe that a transformation is possible.”

5. Permitting Obstacles to Block the New Vision

The important points that Kotter brings up are:

  • Implementation of any kind of major change requires action from a large number of people
  • New initiatives fail when employees, even though they embrace a new vision, feel dis empowered by huge obstacles in their paths
  • Occasionally, roadblocks are only in peoples’ heads – In many cases, the blockers are very real

6. Failing to Create Short-Term Wins

Many times the best approach is to not take on too much at once but focus on some short-term wins that show progress.

7. Declaring Victory Too Soon

  • People can be tempted to declare victory in a major change effort with the first major performance improvement
  • While celebrating a win is fine, any suggestion that the job is mostly done is generally a terrible mistake
  • Until changes sink down into the company culture(3-10 years) new approaches are fragile and subject to regression

8. Neglecting to Anchor Changes Firmly in the Corporate Culture

Culture and values are extremely important – if people are simply mechanically implementing the change without any real change in corporate culture and values to support it, the change may be somewhat fragile and not long-lasting.

Three Most Critical Principles

All eight of the issues that Kotter has defined are important, but from my experience, there are three that are most critical that most frequently derail an Agile transformation.  These are:

1. No Burning Platform

This is based on Kotter’s first error “Not Creating a Sense of Urgency”.  There needs to be something that creates some urgency about making a change because maintaining the current situation is very painful and untenable.The phrase “burning platform” originated with a fire on an oil-drilling platform off the coast of the United Kingdom some years ago.  The phrase can have several contexts –

  • One context was that there were serious safety issues with the platform that were not addressed until the platform caught fire because there didn’t seem to be a sufficiently urgent need to address them.

  • Another context was that once the platform was on fire, there was an urgent need for the employees to do something to save their own lives – staying on the platform at that point was an untenable situation.

2. No Vision for the Future

This is based on Kotter’s third error “Underestimating the Power of Vision”.  Taking the time to define a vision for an Agile transformation is extremely important – many people make the mistake of using a one-size-fits-all approach to force-fit a company to some kind of “textbook” model.The best approach is to fit the model to the company’s business and a pure, top-to-bottom Agile approach may or may not be the best fit.  It may require more of a hybrid approach to achieve that kind of alignment, at least in the short-term.

3. Failing to Show Short-term Progress

This is based on Kotter’s sixth error “Failing to create short-term wins”.  There are always naysayers and skeptics who will remain on the sidelines waiting to see if the change is likely to be successful before they jump on the bandwagon.  That is why it is important to get started and demonstrate progress as quickly as possible.  From an Agile perspective, it is important to set clearly-defined and measurable goals that show progress and regularly communicate that progress to everyone involved.

Overall Summary

Implementing Agile successfully at an enterprise-level many times requires a significant transformation. That can be a difficult thing to do and it requires some understanding of change management to do it successfully. It is actually very similar to a business process reengineering project.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is Agile? How Would You Define Agile? What Does Agile Mean?

How do you define Agile? I’ve seen a lot of discussions where people have attempted to answer the question of “What is Agile?” with very different answers. 

Define Agile

Do You Really Mean Scrum?

First, there’s a lot of confusion about Agile and Scrum. Scrum is so widely-used as an Agile approach that when many people say “Agile”, they’re really talking about Scrum.

  • Agile is a general philosophy
  • Scrum is a specific Agile approach

Check out this article on What Is Scrum? What Is Agile? for more on that.

Feeling the Elephant

I’m sure that you could find at least 100 definitions of what “Agile” is on the Internet. It’s like the old fable of “The Blind Men Feeling the Elephant”:

“It was six men of Indostan
    To learning much inclined,
Who went to see the Elephant
    (Though all of them were blind),
That each by observation
    Might satisfy his mind[18]”

Each man came away with a different opinion depending on which part of the elephant he touched:

“Each in his own opinion concludes that the elephant is like a wall, snake, spear, tree, fan or rope, depending upon where they had touched”

Different Views of Agile

The way people define Agile is somewhat similar.  Depending on which part you touch, you may come away with a different impression of what Agile is:

  • Many people will define Agile in terms of how it is done. For example, many people will say that it is defined by the Agile Manifesto.  Here are a couple of examples of that:

“Agile is a set of methods and frameworks that embody the principles  and values of the Agile Manifesto”

“Agile is a term used to describe approaches to software development emphasizing incremental delivery, team collaboration, continual planning, and continual learning. The term “Agile” was coined in 2001 in the Agile Manifesto.”

  • Some people will say that it is just a mindset or way of thinking.  Here’s an example of that.

“Being ‘Agile Is a mindset. It’s about finding the right thing to build, faster (and not just building things faster)”

  • Some people will define it by comparing it to “Waterfall” to tell you what it is not.  Here’s an example of that:

“Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.”

None of those definitions are incorrect, but it’s like “feeling the elephant”; they don’t really get to the real essence of what the “elephant” is, in my opinion.

How Do You Define Agile?

Personally, I like the definition that is published by the Agile Alliance:

“The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”

I think that is a better definition because it gets to what I consider the real essence of what Agile is.

“Agile is best suited for situations that have some level of uncertainty where creativity and innovation are important to maximize the business value of the solution as opposed to other situations with lower levels of uncertainty where planning and control to achieve predictability are more important.” (My own definition)

What Problems Does Agile Solve?

We should acknowledge that Agile is not a solution to every problem you might have. One way to define it is in terms of what problems it is useful for. 

  • If you accept that Agile is not a solution to every problem you might have, the first thing you would want to know is “what problems is it useful for?” 
  • You don’t need to get too far into the mechanics of how to do it until you’ve determined that it is a useful solution to the problem you’re trying to solve.

There is an interesting observation you might draw from this – people get very immersed in the mechanics of how to do Agile and that’s how they define it.  Isn’t it more important to know what problems it’s useful for solving before you get into the details of how to use it?

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

How Do You Apply Agile to Non-Software Projects? Agile Book Publishing

Many people have asked about “Applying Agile to non-software projects”.  I’ve done a lot of that myself in using an Agile book publishing approach for publishing five books. I’ve also used similar techniques in designing and developing numerous online training courses. I thought I would summarize some of the techniques I’ve learned from doing Agile Book Publishing over the years.

Agile Common-Sense Principles

Here are some common-sense principles I’ve learned from using an Agile book publishing approach for publishing five books:

1. Just Get Started

One of the most important principles I’ve learned is “just get started”.  When you’re faced with writing a book or developing a major online training course, it can be a daunting experience. Just getting started is sometimes the hardest part:

  • We’re not sure how the final result is going to come out
  • We’re not certain how the final result will be structured – what should come first, etc.
  • We don’t want to produce something that is going to be a failure

You have to stop worrying about all of that and just get started.  I think of an Agile book publishing effort like developing a fine art sculpture.  You start with a lump of clay and you just keep molding and shaping it until it becomes a work-of-art.

How Do You Apply Agile Techniques to Non-Software Projects?

If you never get started, it will remain just a lump of clay.

  • It takes some courage and confidence in yourself to do this.  You’ve got to have courage and confidence that if you just get started, that somehow the final result is going to come out OK if you keep working at it
  • It also takes patience and commitment because you may have to go through a large number of iterations to get something useful out of it.  You may even have to throw something completely away and start over again

2. Use an Incremental and Iterative Approach

Many people don’t understand the difference between the words “incremental” and “iterative”. An Agile book publishing approach involves both:

  • “Incremental” means that you break up a solution into pieces and develop one piece (increment) at a time
  • “Iterative” means that if you’re not sure what a given piece should be, you develop something and then continue to refine that piece until you meet the customer’s expectations

Both of those are important:

Incremental Approach

Using an incremental approach is very important.  In any large effort like writing a book or developing an online course, its best to break it up into “bite-sized pieces.  If you try to take on too much at once, you’ll never finish it.  The effort to write a book can easily take well over a year and it’s easy to get discouraged in that period of time that you will never finish if you don’t see progress in the work.

Iterative Approach

Taking an iterative approach is also important.  A close corollary to “Just Get Started” is “Don’t Expect Perfection”.  A major reason for not getting started sometimes is that we’re afraid to produce something that is less than perfect. 

  • We have to accept that whatever we produce on the first iteration is certainly not going to be perfect. The final result may not be perfect either. 
  • Get something done quickly and then continue to refine it as needed to meet customer expectations.
  • There’s also a saying in Agile that is used a lot called “just barely good enough”. 
  • We shouldn’t try to “gold-plate” or over-design something. It should satisfy the need to provide value to the customer and nothing more.  Keep it simple!

3. Know  Your Customers and Listen to Them

When I first started writing books, I had a lot of people who helped me.  I had a network of people on the Internet who provided me with lots of great feedback and inputs.  I would write a chapter or two of the book and put it out to my network for feedback and comments.  Part of doing that successfully is recognizing that you “don’t know what you don’t know”.  You have to be humble, listen to other people, and respect their needs and interests.  If you think that you know it all, you probably won’t be very successful.

In the online training I develop, I get lots of feedback and inputs from students and I listen to it and take action.  As a result of that feedback, I have continuously improved all of my courses.

4. Refactor Your Work As You Go Along

I’ve done a fair amount of software development in my career and I’ve learned a lot from it. 

  • I’ve learned the value of having clean and well-organized software because I have had to support a lot of the software I’ve developed
  • Organization and flow of the material is particularly important in books and online training as well
  • As a result, it is essential to take time to go back and clean-up your work as necessary as you go along
  • When I first write something, I get it done quickly but I may have to rewrite it and reorganize it 5-6 times before I’m satisfied with it

5. Work at a Sustainable Pace and Do a Little at a Time

When you’re doing a long project like writing a book, working at a sustainable pace is very important.  That is especially true if it requires a lot of creativity and innovation.

  • You can easily get burned out by trying to do too much too quickly and when that happens, your creativity can go downhill quickly. 
  • Sometimes you need to put it down, walk away from it for a while, and come back when you’re refreshed to start work again.

Agile Book Publishing – Overall Summary

I think all of this is just good, common-sense things to do – why do people have trouble doing this? 

  • I think many people think of Agile as Scrum and also think about doing it mechanically. They aren’t sure how they would go about applying a Scrum process to this kind of effort
  • Agile is not just Scrum – it is a way of thinking. We need to understand the principles behind Agile. Don’t just do it mechanically and “by-the-book”. Take the time to interpret how it applies to your current situation and adapt it as necessary

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

For another example of applying Agile to non-software projects, check out this article:

https://managedagile.com/4782-2/