Category Archives: Uncategorized

Applying Agile to Non-software Projects

I’ve had a lot of requests from my students to provide some case studies that show how to apply Agile to non-software projects so here is one I recently completed from my own experience. This was a house remodeling project which may seem simple and trivial; but believe me, it was not.

How Do You Apply Agile to Non-Software Projects?

Agile can be applied to some extent 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. It can require a considerable amount of skill to interpret Agile principles and values in a broad context to figure out how to apply them to projects that don’t necessarily fit the mold of a typical software project.


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

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”)
  • All of the work in this project was done by multiple outside contractors
  • In spite of these difficulties, a major challenge was to try to manage the costs and schedule of this project within reasonable levels

Contractor Selection

The first task was to select a contractor (or contractors) to do the work. Here are the choices I was faced with:

  • 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 and 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” was much less widely-known but offered much more flexibility and willingness to work with us to come up with a design that was customized to meet our needs. They would also take overall responsibility for managing the overall solution.
  • Contractor “C” offered the most flexibility to meet our needs but was actually two different contractors so it was not really possible for either of them to take overall responsibility for the overall solution
    • Contractor “C1” did the demolition and prep work including electrical and plumbing to prepare the new kitchen
    • Contractor “C2” provided the kitchen cabinets and counter-tops and installed them after the initial demolition and prep work had been completed
    • Following the installation of the cabinets and counter-tops, Contractor “C1” returned to do the finish work which included final installation of new lighting fixtures and repainting of the entire area

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 but offered the most flexibility to meet our needs
  • Contractor “B” was a compromise between those two extremes. The advantage that they had over Contractor “C” was that they were a single contractor who would take overall responsibility for the solution but their costs were considerably higher than Contractor “C”

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. I was apprehensive about splitting the work between two different contractors and the workload that would put on me but these two contractors had a history of working together successfully on other similar projects and I had a good feeling about these individuals that I could trust and partner with them to manage the overall solution. That was a key difference:

  • In a relationship with contractor “A”, I would have relied on a very clear and well-defined contract to deliver the solution but I would have little or no flexibility to make changes (That’s what many people might call “Waterfall”)
  • In a relationship with Contractor “C”, there was a statement of work but it was understood to be flexible and subject to change and much of 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?

There were a lot of difficulties associated with managing this effort:

  • 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, there had to be changes to the rest of the house 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. I can’t tell you how many different kinds of granite counter-tops and how many different floor tiles we looked at before making a final selection; and how many times what I thought was 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 and being caught in the middle between a very demanding stakeholder on the one hand and contractors on the other hand 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

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

Here’s a picture of what the finished kitchen looked like plus a couple of pictures taken during the work-in-progress leading up to finishing the kitchen:

Overall Conclusions and Lessons Learned

Agile principles and values can be applied to some extent to almost any project but it requires some skill to interpret these principles and perhaps combine them with traditional project management practices. Here are some important lessons-learned from this effort:

  • The overall value that the project delivers is what is most important and “value” is determined by the key stakeholder. Naturally, cost and schedule goals are not unimportant and have some value but that is 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.

How Does This Apply to a Business Situation?

I know this is an unusual situation but I like to use unusual situations because I think it encourages “out-of-the-box” thinking rather than viewing standard, stereotypical Agile case studies. Here’s 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 and many businesses have significant supply chains that are critical to the success of their business. The traditional way of managing those contracts is to develop a firm, fixed-price contract and use a competitive process involving multiple bidders 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 and it is important to maximize the business value of the solution, a different approach is needed that is based on more of a collaborative partnership with a contractor to work together to maximize the value of the solution.
  • Trust – Developing that kind of relationship with contractors requires trust so naturally it will not be possible to develop that kind of relationship with just any contractor. That’s why it is important in business to have strong relationships with a selected number of contractors who can be regarded as close partners.
  • Risk Management – I took a significant amount of risk in this project going with contractors that I thought were the highest risk from a project management perspective but that risk paid off in terms of the overall quality of the solution. I think 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 – This project was completed amazingly fast once the work was started and that was largely due to the fact that I empowered the contractors to get the job done the best way they knew how and didn’t attempt to micro-manage what they were doing. Conventional project management might attempt to more directly manage the work being done

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

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?

What’s the Issue?

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.

Planning Fundamentals

Let’s review some fundamentals about planning. We can learn a lot about how the military does planning. 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.

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

The words “Agile” and “Waterfall” are two of the most loosely-used words in the English language. People use those words as if both “Agile” and “Waterfall” are specific and well-defined methodologies that can be easily compared and they are not:

  • “Agile” is not a methodology – “Agile” is actually a range of different approaches – Kanban and Scrum are both Agile methodologies (or frameworks) but they are very different. Kanban is more adaptive than Scrum and Scrum is more plan-driven than Kanban. Both approaches are very flexible and can be adapted to a range of different circumstances.
  • When people talk about “Waterfall”, they are generally not talking about the specific “Waterfall” process that was defined by Dr. Winston Royce in the 1970’s. As it is typically used, in practice, the word “Waterfall” really means any plan-driven methodology that is not totally agile. For example what about the Rational Unified Process (RUP)? That’s an iterative process but many people might include that in the realm of “Waterfall”.

Overall Summary

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

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

Agile Project Management for Executives

I have just released a new online training course called “Agile Project Management for Executives”. (It is actually an existing course that has been significantly redesigned)

Agile Project Management for Executives

The Agile Bandwagon

In many areas, “Agile” is becoming a hot new buzz word and everyone wants to jump on the “Agile bandwagon” without necessarily fully understanding why they’re getting into it and exactly what they expect to get out of it. 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

Course Summary

While Agile has huge potential benefits for a business, it’s important to not get carried away with some of the hype that exists about Agile and 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 and includes assessment tools and planning tools to help you develop a very effective Agile Project Management approach that is very well-aligned with your business.

Intended Audience

There are three potential audiences for this course:

  1. Senior-level Executives – The first audience is senior-level executives who are interested in making their business more agile and want to 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 in order to provide more effective leadership for the initiatives that they are responsible for
  3. Product Owners – The final audience is for Agile Product Owners who need to better understand how to effectively perform the Agile Product Owner role.  The Product Owner role in Agile is not well-understood and most of the people who might be selected to perform that role are not well-prepared for what it requires

Why Is This Course Unique and Important?

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

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, when I got my CSPO (Certified Scrum Product Owner) certification more than five years ago, the course was heavily focused on the “mechanics” of how to do Scrum and didn’t really directly address the role of the Product Owner as a business decision-maker at all.

  • 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 and it objectively presents Agile and traditional plan-driven project management approaches as complementary to each other rather than competitive.
  • 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 that provides a very in-depth understanding of Agile from a business perspective

This course is also designed to complement all of my Agile Project Management courses. The idea being that implementation of Agile at an enterprise-level requires a collaborative partnership between a business executive and a senior-level Agile Project Manager based on a mutual understanding of how an Agile approach might apply to their business.

Special Discount Offer

I’m anxious to have a limited number of people review this course and provide feedback and inputs. For that reason, I am offering a special discount offer to a limited number of people who are willing to to be a “beta tester” for this new course for only $10 (Normal list price is $195). If you’re interested in beta testing the course and providing feedback, please click on the link below:

Register for course for only $10

This is a very limited offer. Please don’t register for this course unless you are sincerely interested in learning and providing feedback and inputs.

What Are the Critical Skills of a Product Owner?

I recently participated in an online discussion on the question of “What are the Critical Skills of a Product Owner?” I think this is a very good question because the role of a Product Owner is not very well understood and the actual role that a Product Owner might play 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 the Product Owner?
Business chart.

What Does the Scrum Guide Say?

The role of the Product Owner is relatively well-defined in the Scrum Guide; however the Scrum Guide recognizes that how it is done might vary 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 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

At one extreme are product-oriented companies that are in the business of selling products to external customers. In those companies, a Product Owner might have the full responsibilities of a Product Manager including profit-and-loss responsibility for the product being developed. 

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 and 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”.

  • He/she has some attributes of a Business Analyst in representing the requirements of the business for the solution being developed but it is much more than an ordinary Business Analyst in that a Product Owner has decision-making responsibility on the requirements where a normal Business Analyst does not have that kind of decision-making authority. 
  • He/she also has some attributes of a Project Manager since he/she is responsible for the successful completion of the project but that responsibility is also much more than a normal Project Manager in that a Project Manager is normally only responsible for delivering defined requirements and doe not typically have responsibility for the overall business success of the project. 

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

  • Some “Business Analyst” skills 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
  • Some “Project Management” skills to make good risk-based decisions on managing the project to make it successful from an overall business perspective (not simply meeting defined requirements)

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

How Do You Choose the Best Methodology to Fit a Project?

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

How do you choose the best methodology for a project?

What’s the Best Approach for Projects?

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

  • Some project managers will try to use a traditional plan-driven methodology for a project (what many people loosely call “Waterfall”) because it is the only thing that they know and it has been so widely-accepted as the way to do project management
  • Many other people have the misconception that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” and will attempt to force-fit a project to one of those extremes

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” as many people seem to think.  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

How Do You Choose the Best Approach?

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

    1. Level of Uncertainty – 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 can create an environment that is not conducive to changes which will make it difficult to maximize the value of the solution in an uncertain environment
      • In today’s competitive environment, creativity and innovation can be very important to create very competitive business solutions and an approach with a heavy emphasis on planning and control can stifle creativity and innovation
    2. Customer Relationship – 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 from:
      • A contractual style of relationship 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 what his/her expectations are and expects the project team to do whatever is necessary to meet those expectations with limited participation by the customer.
      • A collaborative style of relationship where there is a shared responsibility for the success of the project between the project team and the customer and the customer takes an active role in helping to define the direction of the project as it is in progress

      Naturally,  the contractual style of relationship is well-suited to a project with a relatively low level of uncertainty where it is 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.

      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 but 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 and establish 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 This 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 that is oriented around planning and control to achieve predictability over project costs and schedules is not necessarily the best approach for all projects.

A project should be focused on producing value for the customer, 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.  There have been many projects that have met their cost and schedule goals but failed to deliver an acceptable level of business value.  “Value” can be a very elusive goal but, in any case, it’s what the customer thinks that “value” is that counts.

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

Many people have asked “How do you apply Agile techniques to non-software projects?”.  I’ve done a lot of that myself in writing and publishing five books and designing and developing numerous online training courses so I thought I would summarize some of the techniques I’ve learned for doing that over the years.

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 and 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 this kind of 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

Use an Incremental and Iterative Approach

Many people don’t understand the difference between the words “incremental” and “iterative”:

  • “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 and 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 unless there is additional value in adding to the solution.  Keep it simple!

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 today, I get lots of feedback and inputs from students and I listen to it and take action.  As an example, I got some inputs from one of my students that one of my courses on preparing for PMI-ACP certification shouldn’t be a mandatory part of my overall Agile Project Management curriculum because some people didn’t care about getting the PMI-ACP certification.  As a result of that feedback, I split that course into two courses.

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

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

When you’re doing a long project like writing a book that can take well over a year and requires a lot of creativity and innovation, working at a sustainable pace is very important.  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.

Why Do People Have Trouble With This?

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 and 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 and we need to understand the principles behind it rather than attempting to follow a well-defined process and doing it mechanically and “by-the-book”.