Author Archives: admin

Taking a Hiatus

Tom, Kyle, Mike, and I have been pursuing various projects lately and have not really had time to write on this blog. But there is a lot of great information here, so do feel free to browse around.

Tom is currently focused on his blog at Tom Meloche Blog

Geri is currently focused on her Agile Transformation blog at Agile is Dead (or is it?) and also working on publishing a series of Agile books for Executives. See Geri Schneider Winters site for information on her books and how to contact her.

Mike is currently focused on his blog at Mike Russell Blog

I am not finding an Agile blog for Kyle – I think he has been busy with his employer’s Agile transformation and so is not posting externally right now 🙂

Launch of Geri’s Latest Book

Did you get your free Bonus Materials for my new book “Why Agile is Failing at Large Companies (and what you can do so it won’t fail at yours)”?

Visit the book website at and click the BONUS Materials link on the upper right of the page.

You can also add your email to my notification list. You will get notices when I post new bonus material, hold webinars, speak in public, or publish another book.

Thanks to everyone who is supporting the launch of my book. I am most grateful.

How Your Waterfall Project Can Be More Agile

5 Practices to Make Any Project More Agile

A core foundational concept in Agile is to get feedback from real users early enough to be able to address any issues that arise.  In traditional Waterfall, we assume we can do enough work up front that there will be no issues at the end, but reality shows that this almost never happens. Instead, at the very end of the project, we do User Acceptance Testing and discover issues that we either rush to patch or we plan a follow up project to address them.

Even if your project cannot adopt an Agile methodology, there is a better way to do Waterfall that still lets you take advantage of all the experience you have doing Waterfall projects and requires very little change within your organization.

There are 5 practices we strongly recommend because they can be done by any project following any kind of methodology. We have in practice with real projects seen them dramatically improve the results of Waterfall projects, and in fact have found historical evidence that some of these practices were recommended in the past for Waterfall efforts. These 5 practices are:

  • Divide the work into increments
  • Plan, estimate, and prioritize each increment
  • Synchronize work including vendors
  • Demo each increment
  • Retrospective each increment

This is what as known as Incremental Waterfall with the addition of the Agile practices of work synchronization, demonstrations of progress, and multiple retrospectives. For Waterfall projects, these practices should not require much change to current processes. Some of the phase gates may need to be passed each increment, such as detailed requirements or design each increment, so some additional time should be allowed for in the schedule. The time is made up later when better quality leads to shorter test cycles and involvement of users means much less (if any) late rework. Big picture work such as overall planning, high level requirements, architecture, and solution selection can be done at the beginning because they are common across all increments and typically do not change much throughout the project lifetime.

In general the approach for a Waterfall project will be a relatively short up front planning, requirements, and architecture phase followed by a set of increments for implementation. Each increment will include the work of detailed planning, requirements, design, implementation, and testing. The complete release process may take place at each increment if desired, or may be delayed until the end of the project.

Each practice is described in more detail below.

Divide the work into increments

An increment is a working subset of the overall solution. This practice would mean examining a project to determine the best way to divide it into 2 or more incremental deliveries of working solution. Note that these deliveries do not have to be general availability, but rather could be collected in a holding area until the whole solution is complete. But each increment will go through a full test cycle including especially user acceptance testing.

The criteria for determining what goes into each increment should include business value (the most valuable work should be done earliest), risk (we should use feedback from real users to drive out risk as early as possible), and the ability to deliver a working subset of the overall solution (minimum viable product). This practice by itself has dramatically improved traditional Waterfall projects by providing feedback well before the end of the project.

In fact, this practice was proposed for Waterfall projects in 1970 by Dr. Winston W. Royce based on his previous long time experience with large Waterfall projects (Managing the Development of Large Software Systems, Proceedings IEEE Wescon August 1970, pages 1-9). His experience and research showed that there would almost always need to be at least a second increment of a Waterfall project to refine the solution based on lessons learned, and so teams should just plan for it. We see the same realization at most of our large customers, where large Waterfall projects have typically been followed by another improvement or fix-it project. We are suggesting to formalize this practice with multiple planned increments of any software project.

Plan, estimate, and prioritize each increment

No matter the length of the increment, the detailed work planning, refining of estimates, and prioritizing of work should happen not long before the start of the increment, instead of doing all of it up front for the whole project. This allows the flexibility to take advantage of lessons learned in one increment to apply to the planning for subsequent increments. It is also a good time to review project metrics to verify the work is going according to plan, and allows a planned time to make adjustments as needed rather than waiting for the end of the project to discover there are issues.

We expect high level planning at the start of the project for all except the most innovative and fast-changing work (which by nature cannot be planned much in advance). This practice is to wait to do detailed planning until just before you need it so that the plans are the most accurate based on the information you have to date. This practice avoids spending time doing detailed work that is likely to be changed later in the project. The less well-understood the work is, the more important this practice becomes.

Synchronize work including vendors

Everyone involved with the project should regularly synchronize their work, including a representative from each vendor. This synchronization can take the form of a daily standup. In some cases, that may be more frequent than needed, but this synchronization should take place at least weekly. Synchronization should be often enough to remove the risk of unnecessary delays due to unknown work blockages.

Note that this is not meant to be a long status meeting, but is rather a 15 minute or less structured ceremony where each person just states what he or she has recently completed, what work he or she is working on now, and anything preventing (blocking) the person from completing his or her work. The most important information to come from this meeting is typically the blockages. The work blockages can be addressed after the synchronization meeting.

It is very important that the vendor representatives be included. A big problem when working with vendors is lack of visibility into what they are working on. Communication can be difficult already when working with another company, so anything we can do to promote regular, meaningful communication will improve (sometimes greatly) the work we do with vendors. Our customers who have worked this way with vendor representatives report a uniformly better experience than just handing work “over the wall” and expecting everything to be fine.

Demo each increment

At least once per increment, the working solution is demonstrated to at least the project sponsor and stakeholders. By far the better choice is to have real end users also attend the demonstration. This demonstration has two purposes: it provides a real deadline when work has to be finished so that it can be demonstrated, and it provides an early opportunity for users to provide feedback on whether or not the solution meets their needs.

Note that this does not replace formal user acceptance testing, but rather is a demonstration of progress and an opportunity for feedback well before the end of a project. Instead of providing status through reports showing perhaps 85% of requirements are completed (for example), we demonstrate working solutions as a measure of progress. If the solution is not complete enough to be demonstrated, we count it as zero percent complete.

We treat solutions as zero complete or 100% percent complete and do not try to determine an increment in between. This is because with any kind of knowledge work, it is not actually possible to truly determine how much is left to do. We can only know how much has been done. We all know of cases where the solution was 90% complete but that last 10% took 90% of the resources. We prevent that in this practice by only counting a 100% solution as complete and anything else as zero.

The demonstration provides a good opportunity to review the progress of the project to get an idea of whether it is on schedule, ahead, or behind. The outcome of the demonstration is that either the work to date is acceptable as is, or defects or change requests are created to fix problems that are detected at the demonstration. The work to fix the defects or change requests can be planned into subsequent increments of the project so that these problems do not exist in the released version of the product.

Retrospective each increment

Most companies have some kind of retrospective or lessons learned at the end of a project. Unfortunately, that is too late to do any kind of good for that team. Instead, at the end of each increment, the team will review the past increment, and in a non-judgmental way discuss what went really well, what did not go so well, and what they will do in the next increment to improve as a team.

We suggest the team start the retrospective by reciting a statement such as “We acknowledge that everyone has done the best job they were able to do in the circumstances that existed during this increment” and suggest the team end the retrospective with expressions of gratitude and thanks to other members of the team or even people outside the team who helped in some special way (it is nice to let those people know in person that they did a great job if they do not happen to be at the retrospective). This helps set a non-judgmental tone to the ceremony. The most important thing is to avoid blaming and finger pointing, to make the ceremony constructive.

The outcome of the retrospective is a small set of specific action items the team will take to improve the coming increment. We recommend starting with just 1 or 2 action items so as to not overwhelm the team with improvement work while they are focused on delivering a product. Often the outcome of the retrospective are suggestions that become habits over time, as the team incorporates better and more efficient ways of working together.

Lean Startup Ideas for Mitigating Business Risk

All businesses exist to deliver the right product or service to market, at the right time, for the right cost. All business risk fundamentally puts one of these items in jeopardy, and so our fundamental business risks are:

  1. Failure to deliver the right product or service

  2. Failure to deliver the product or service at the right time

  3. Failure to deliver the product or service for the right return on investment (ROI)

  4. For companies in regulated industries we also have failure to comply with all laws and regulations

These risks are fundamental to business, and do not change based on the processes or procedures used to create or deliver the products or services. All risks we identify that are specific to processes or procedures must address one of these fundamental business risks.

For example, business continuity procedures help some companies, such as those that deliver SaaS or hot line support, ensure that they deliver the product or service at the right time. In this case, business continuity procedures are extremely important for staying in business because delivering the service at the right time means the service is available all the time.

In addition, we should consider the cost of controlling that risk versus the effect it has on the business risk. Controls that have a small impact on the fundamental business risks should either not be used or should be very inexpensive to implement.

As one example, many companies say they have a risk of project failure, which they define as going over schedule, over budget, or both. I have worked for a number of companies who delivered every project on time and on budget, and their products failed on some or all of the fundamental business risks. I have worked for a number of other companies who did not always deliver their projects on time or budget, but did in fact deliver the right product to market at the right time for a very nice return on investment. In these cases I observed, the risk of project failure did not have a strong correlation to a fundamental business risk. Controlling for project risk only weakly controlled for business risk.

What that tells me is instead of assuming that the project lifecycle is the problem, we should do a root cause analysis to determine the actual problem. Maybe we are running projects poorly. Or maybe we are failing in marketing and sales. We should find the real problem and invest in controls that have a strong correlation with product success.

What is a control? By definition a control is a process that reduces risk. Typically a control is a mitigation strategy that is formalized. Documents are not controls. Documents are also not evidence that a process was followed. We all know of delivery teams who did not follow a specified process but created the document that “proved” they did at the end of the project. I have seen many documents that were supposed to prove that a process was followed, that were merely copies from another effort. Many times, the project name was not changed throughout the document, nor the dates when the work was supposed to have been done.

A control is a process. Therefore, if you want to audit for the control, you have to audit the process. Most of the time, that will mean observing the process as it is being done. If all the auditors do is look for a document that says the process was done, then you have incurred cost with zero benefit. If your company is typical, your people never have enough time to do everything, so they will cut processes that are only audited by document and do the fastest job possible to produce the required documents. Since the process is most likely not being done, either the process is not necessary to control for risk or you have been lucky.

Given all that, what are associated risks and mitigations for the fundamental business risks? Below are some examples of possible risks and mitigations for the fundamental business risks listed above. The mitigations are heavily influenced by Agile and Lean Startup thinking, so may or may not be appropriate for your business.

Business risk: Failure to deliver the right product or service

Associated Risk Mitigation
Your market is not well-defined Leadership in the company should go through an exercise of defining the market for each product and service. They might be the same, they might be different. It is not good enough to say “Our market is men.” Or “Our market is middle-aged people.” It is almost certainly true that those markets are too big. Get specific.
You do not understand your market Company leadership should ideally be from your target market or have a close relationship with your target market. You can also use focus groups, advisory boards, and other techniques to get a better understanding, but there is no substitute for personal knowledge.
The product or service is poorly defined This is common early in product development, but must be mitigated before the product or service goes to market. The best mitigation is to do a little, test it with users, based on feedback do a little more, test again, and continue this until you have a viable product. Whatever prototyping you do, find the least expensive, fastest way to do it.
The users do not want the product or service The best mitigation is to get real users involved in developing the product or service. Not just one group of users (you end up developing something just for them), but bring in many different groups of users over time who represent the breadth of your market.

Business risk: Failure to deliver the product or service at the right time

Associated Risk Mitigation
You deliver too early Find real users who are connectors and recommenders. Get them involved in the development process. Encourage them to help prepare the market for the coming product.
You deliver too late Identify a minimum viable product. Develop that first, and keep it always ready to go. You can release that at any time if you have to quickly go to market and follow up with additional features later.
You deliver too often Solicit feedback from real users all the time – forums, blogs, Facebook page, etc. They will tell you if they are getting overwhelmed. When possible, track the use of the different product features. If you are delivering new features and no one is using them, you are probably delivering too often.
You deliver too infrequently The same as delivering too late, always have something new ready to go. Solicit feedback from real users all the time. They will tell you if they are tired of waiting for new features.

Business risk: Failure to deliver the product or service for the right return on investment (ROI)

Associated Risk Mitigation
The size of your market is smaller than you thought Discover if there is a broader market who can also make use of your product or service. Cut back on your product plans to match the size of your market.
Your market is not finding out about your product or does not see the value in it Assuming you have identified the right market and product, then along with traditional marketing, find connectors and recommenders, get them involved in developing your product, encourage them to recommend your product to others. Also, look for related products where you can piggyback your marketing efforts. Joint marketing with another company could be quite effective.
The cost of development was too high when compared to sales or other benefit received (low ROI) Identify the root cause. Were you overly ambitious compared to market demand? Then you need to cut back on your development efforts. Was the development process inefficient (heavy process, too many people, too many metrics, too many meetings, not enough experience in the development team)? Bring in someone to help improve your process. Was the failure in the sales team – not enough sales to recover the cost of development? Maybe you need more experienced sales people, or they need better training on the product and benefits, or they need coaching on sales techniques.

Business risk: Failure to comply with all laws and regulations

Associated Risk Mitigation
Discovery of non-compliance and the consequences of it (product removed from market, product reworked, fines, prosecution, restitution) Educate your workforce on the laws and regulations. Review product and service offerings with lawyers, regulators, and other experts as appropriate. Keep records of all recommendations by lawyers, regulators, and experts. Be aware when there are changes and have your product and service offerings reviewed for compliance with new laws and regulations. Be sure all product and service offerings are updated within the time frame allowed.

I hope this article has you thinking more about how to control for risk. Doing the same thing “everyone else” is doing may not be the right thing for your company. Go back to the fundamental risks and discover the best way for your company to reduce them.