Featured post

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 http://agileisfailing.com 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.

Setting up Your Programs for Success

With all the conversations about SAFe, you would think programs were a new idea. Actually, they have been used for many decades to manage very large efforts. This article discusses lessons learned from the past about how to set up a program at the beginning so it will run more smoothly throughout.

A program is one kind of construct to organize and coordinate the work of a large number of people on the same deliverable. Other constructs include value streams, products, product families/lines, and the open source model (community ownership of software with rules and governance). I have heard of programs as small as 40 people contained within one company and I have been personally involved with programs involving hundreds of people, sometimes across several companies or countries. Programs are used to manage big efforts.

Programs were developed in the defense industry to manage efforts such as putting a man on the moon, creating a new submarine, or creating an overall battlefield management system. Programs were adopted in commercial enterprises to manage efforts such as SAP implementations or creating a new tractor. Creating a mobile app does not require a program.

Programs are used to manage large complex efforts. A key technique to managing complexity is to structure the work in such a way as to get rid of as much complexity as possible. Simplify as much as possible, then manage the rest.

When planning your program, assign work to individual teams in such a way as to reduce or remove dependencies between teams. Each team should work as independently as possible. There should be little or no dependencies based on time, code, functionality or any other factor.

You can achieve this independence by assigning complete independent work packages (for example use case, user story, subsystem, component, or task) to each team. If the work packages are truly independent, you should not have very many cases where multiple teams need to work in the same code base, nor should you care much about what order the work is completed.

Any points where the teams need to cooperate should be well defined using tools such as contracts, interfaces, services, or API’s. Test harnesses and stubs can be effectively used to keep the work of the various teams as independent as possible, allowing each team to test their own code even if code they need to use from another team does not yet exist.

Teams should NOT be set up around the SDLC, i.e. a requirements team, design team, coding team, and testing team. This creates unnecessary dependencies between teams such as the coding team is waiting on designs, the testing team is waiting for code, etc. Each team should be responsible for the complete life-cycle for the work package they are assigned.

You do have to plan coordination points for releases. Teams cannot work on whatever they please. Each team has to make a commitment to deliver certain functionality at a certain time with specified quality. This is a commitment to their co-workers on the other teams. There may be other work a team does as well, but there has to be a minimum set of code they complete by a specific scheduled date in order for everything to fit together. You have to carefully manage the teams so they deliver what they promised the other teams at the time they promised to deliver it. If you do a good job defining the integration points between teams and managing their work to complete on time, then integration of the work of the various teams should be fairly straight forward.

There has to be a program level management team whose job it is to create the appropriate work packages, set up the release schedule, assign the work to the teams, define the minimum each team is required to deliver to make the release, coordinate the work of the teams, remove obstacles between teams, and be the final arbiter in situations of disagreement. People managing the program may include architects (software, system, network, data, UI, business) as well as those in more traditional management roles. You may need people at the program level to create (or help create) code that coordinates the work between teams such as test harnesses, stubs, interfaces, services, or API’s.

While you can do a whole program with one release at the end, this is very high risk. Programs tend to be lengthy and much can change from beginning to end. It is much better to plan a series of releases with time scheduled to make any needed adjustments due to change or lessons learned.

In a well structured program, you do not have to care about how each team does their work. As long as the team delivers according to their contract, it does not matter if they are onshore, offshore, or vendor, or whether they use an Agile or Waterfall type of SDLC.

Finally, the key to a well-run program is monitoring the teams and their progress with appropriate metrics, regular meetings with a representative from each team to coordinate efforts, management by walking around when you can, and quick resolution of problems when they arise.

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.

Tips for Job Searches

While not specifically Scrum or Agile related, I know at any particular time many of you are likely looking for a job.  If that is you, read on.

I recently put together a workbook that steps you through using the Strengths Finder quiz to find keywords to use in your resume, LinkedIn profile, and cover letters. These keywords are your strengths, as well as being the search terms that recruiters use to find people for jobs.

Right click on the link to download the PDF.

Using Strengths Finder to Get the Job You Love

I hope you find this useful.

Geri

Who would win in a fight…

“Who would win in a fight betwen a Moose and a Bison?” says my then-six year old son after our visit to Yellowstone.

Being as this is the 768th question of that type that he’s asked in the last 5 minutes, I’ve had some practice answering.

“Which one is bigger?” I ask.

“The Moose.”

“Yes the moose is definitely taller.   Which one weighs more?”

“The Bison”

“Okay…well then the Bison probably wins the fight.  In animals, the heavier animal almost always wins a 1-on-1 fight.”

30 seconds later:  “Who would win in a fight between a Fox and a Bobcat?”

Rather than subjecting you further to 392 more conversations about animals, I’d like to talk about organizational survival strategies.   Interestingly, they seem to largely match up with animal kingdom survival strategies.

Essentially, animal survival strategies come down to one of the following:

Be big/tough enough that you’re hard to kill.
Be quick enough that the big killer can’t catch you.
Swarm, so that even if some of you die, you still succeed.
Have special skills (poison, shell, etc.)

Making a small nimble rabbit work with a turtle shell just isn’t going to work.

So what about organizations?

Some organizations are like hippos.  They’re just big.  Because they’re big, and strong, and tough…nothing much messes with them.

Other organizations are like rabbits.  They dance and dodge, bob and weave, and move quickly to handle issues.  But they have to, because they’re small.

Other organizations try lots and lots of things.  Most of them fail, and occasionally something works, often very well.

And still other organizations become unreasonably good at one or two things, and focus only on that.

What folks seem to have a big problem with is:   they want organizations to do things that the organization itself isn’t designed to do.   They want rabbit-like fast organizations to be highly resilient.    They want large, hippo-organizations to bob, weave and dance….and implement Agile type speeds.

Have we considered whether if you’ve got a hippo, asking it to dance (on land) is a rather absurd proposition.   If you get the hippo in a tutu, we should probably call that a win, and go home.

Six Sigma versus Business Analysis

Six Sigma Business Analysis
Purpose Remove defects created by a process Discover user needs and align with business objectives
Approach Remove variations in the process Feedback from users
Main Skill Set Statistics Analysis
Objections Forget to ask should we even do this, or is there a different, better approach. Most people are really bad at statistics. Removing all variation inhibits innovation and growth. Too often just an order taker or list maker. Analysis is not a common skill.

What’s your problem?

To Solve a problem, first figure out what problem you’re solving.

If you have a problem that centers around how to get something done fast and efficiently…note that speed is the essence of your problem.  Probably, speed trumps correctness, repeatability, and documentation.  So…do it fast.   The problem you’re solving demands you do it fast.

If you have a problem that centers around solving the same problem repeatedly, then recognize that repetition is the essence of yoru problem.  Don’t build a solution designed to be fast.  Build a solution where repeatability is the essence.

One of the major problems in modern software process is that no one is willing to admit what the central problem is that their process is designed to solve.   Hero is designed to solve small problems.  Commander is designed to solve problems of how to coordinate lots of people.   Agile is designed to solve problems around change.

What’s your problem?   If you can figure that out…you might be able to decide how to solve it.