This article which lists three high-ROI practices has been updated with new images and a few other minor fixes:
The Best Agile Practices to Implement Now
Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items. The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.
Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done. Scores therefore give a sequence to jobs. The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”. The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.
In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners. The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.
This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it. My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise. It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class. I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.
UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!
UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.
NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
Pre-requisites: None! No prior Scrum or Agile knowledge or experience required. However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.
Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.
Timing: This simulation takes at least 7 classroom hours. I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.
Materials Needed:
Room Setup: Round tables with 5 to 7 chairs at each table. Materials distributed to each table.
(with facilitator’s notes in red)
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
NOTE: Permission to use the Product Owner Simulation exercise and print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.
Product Backlog Items are ordered into a sequence in the Product Backlog in such a way that the Product Owner is able to maximize the return on investment (ROI) in the team. The very first PBI in the Product Backlog should be the one with the highest expected value considering the effort to build the PBI. There are many ways to calculate this expected value including Return on Investment (ROI), Net Income After Taxes (NIAT), Net Present Value (NPV), etc. The Scrum Team members should be free to ask why one PBI is prioritized higher than another, and the Product Owner should be able to give a reasonable answer. Since the entire Scrum Team is accountable for its work, it is in the best interest of all members of the team to use expected value, so that both the Scrum team and the customer will be committed to the work that is currently being worked on and the upcoming work in the future Sprints. If we don’t order the PBIs by expected value, then the Product Owner is likely to prioritize them based on dates, feelings, urgency, or other less valuable methods. These other prioritization methods will diminish the trust of the team in the Product Owner and may lead to morale problems.
Recently, I had an interesting discussion with a companion about Agile Processes and the need for corporations, communities or groups to change their approach to planning and doing work. We were discussing using OpenAgile as a Framework.
The person I was talking to told me that their group (Artists) were already used to and embraced the idea of shared responsibility, self-organization, mutual respect and open discussion to get things done. OpenAgile (as well as Scrum) require open communication and truthfulness to be effective tools for self-organization.
My friend then told me how it made sense in the Art Community but it would be hard for Financially minded people to believe in what Agile was about and that it would be even harder for financially oriented educators (ie: Universities and Colleges) to change their minds about teaching Agile processes as a primary part of the education system.
Then it struck me.
For many people, they hear FIRST about the need to share work, how the organization changes, how people are treated better and all the usual comments.
I realized I need to change my approach with these types of people to first discuss how agile processes work to benefit Business Value and Quality. My 15 second elevator speech should start with these ideas and not the other way around.
I don’t know of any business leader, financial manager, non-profit CEO or educator that would think it to be a bad idea if I said to them “Listen, I would like to show you a way to do the most valuable things first, with exceptional quality while at the same time consistently getting better at it. Oh, and as a by-product, you will also have more engaged, long-term staff. What do you say ?”.
We must admit that OpenAgile (or any other Agile process) is not a silver bullet to be used everywhere for all groups. I have however found that after teaching about iterative work and the IDEA of Business Value and Return on Investment, even a “non-agile” team can still benefit from some of the procedures or “routines” of a fixed cycle of learning and it’s heartbeat.
All of the new ways of doing things including culture shift, team based work, etc. would be unfortunate for a business without first remembering that the purpose is to provide Quality and at the same time provide the items that have the most VALUE to the organization.
Quality is an inherited part of the process of going Agile. As more discussion happens and all people in the team have input into the process, inevitably, you should end up with a better result. The customer has more direct input into the final product as it is being created, therefore helping to achieve a result that everyone is happy with.
The real goal to business is this Quality, and the way to get there is all these things that Agile asks us to do, through a continual process of learning.
Business Value. This means different things to many people. Where you are using OpenAgile, Scrum, XP, Pomodoro, remember, the goal of all of these is to work on the tasks that will provide the company or organization to most Business Benefit First.
When coupled with the idea of Return on Investment, the reasons are just far too compelling to an organization to ignore. After all, no organization of any type can afford to exert effort with no return at all in the form of artifacts of some sort. Every organization is there to create some kind of result (value) in its’ chosen field.
Most organizations have many different opinions and reasons for considering one item more valuable than another. You will likely find that most people think ALL of their backlogged items are of equal value to a project or company.
The idea of doing work based on Return on Investment takes some of the emotion out of this process to allow work that is clearly more beneficial to the group to take precedence.
When a task is determined to be of lower value (not because of just value, but work for value) doesn’t make it into this cycle, it MAY well be classified as a higher Value for the next cycle, and therefore, it’s Return of Value / Work may be higher and bring it up the work scale through this process.
There are several ways to accomplish this. One of the easiest is by breaking the item to be done into smaller pieces. It’s Value will remain the same, but the work (effort) required to complete that smaller piece will be less. Therefore, the new smaller task will have a higher Return on Investment and be done sooner.
The idea is that true business value is what is provided first with many competing priorities. Most of us don’t have the ability to just add two or three more teams when more work comes along, so there needs to be some logical process to deal with this.
For my friend in the Arts who is wondering about the Financial Elite having a hard time doing a mental shift towards Agile processes instead of Waterfall processes, consider the conversation about Return on Investment and Quality of the Final product as your starting point. THEN let them know, “Oh ya. you’ll also end up with less turnover and happier employees”. :->
Mike Caspar
References :
OpenAgile – http://www.openagile.com
Scrum – http://www.scrumalliance.org
Pomodoro – http://www.pomodorotechnique.com
XP – http://www.extremeprogramming.org
One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?
Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.
First, let’s define cycle time. From iSixSigma we have:
Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:
So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.
Now let’s look at the steps that occur in an ideal agile environment:
So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.
The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.
A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).
The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.
This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.
This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.
Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.
But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size – the size of the iteration.
It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.
There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.
Improving cycle time can now be done in a few ways:
Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.
ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.
In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:
Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:
Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.
The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.
Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.
In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.
Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.
Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning – disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment – opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders – engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control – mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change – processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?
Work can often be divided up so that the smaller pieces are valuable on their own. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.
For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighborhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group’s goal of attracting new members.
In a business environment, iterative delivery allows for a much faster return on investment. The following diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:
One can see clearly from the diagrams that the non-agile delivery of value at the end of a project is also extremely risk prone and suseptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the agile iterative delivery situation, an endeavor can be cancelled at almost any time and it is likely that substantial value has already been delivered.
Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Either method of dividing work allows us to do the work in iterations.
Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, no matter what the endeavor.
At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.
Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.
