content top

Scrum Inc @ Agile2014

Scrum: The Art of Doing Twice the Work in Half the TimeCatch Jeff and Alex at Agile2014 as they present our thoughts on Scrum at Scale and Leveraging Business Value in your backlog. Jeff will also be signing a limited number of advance copies of his new book Scrum: The Art of Doing Twice the Work in Half the Time. Meet us at the VersionOne booth for your chance to win a copy. Pre-order now and we’ll send you a free copy of the first chapter to whet your appetite.


Scrum at Scale

Alex Brown and Jeff Sutherland will present Scrum Inc.’s modular framework for scaling Scrum, and we want your patterns! Share with us how your team has met the goals for any module, and help us grow the Agile community’s understanding of Scrum at scale. All submitted patterns will be publicly posted and refined as we continue to explore Scrum at the enterprise level.

The framework creates loosely coupled modules that act as the skeleton to which the muscle of different practices is connected. Each module is defined by “goals” (what needs to be accomplished) “inputs” (information from another part of the organization) and “outputs” (what the module produces). The details of how these defining inputs and outputs are fulfilled is left up to the implementing team.

Submit your pattern and share your module configuration with the community. 

Download it: Slides | Infographic

Watch it: @Agile2014 or on demand (online course!)


Leveraging Business Value

Methods for Estimating Business Value Agile2014

Calculating business value effectively and using that insight to prioritize the Product Backlog is one of the most important things an organization can do to drive higher profits and achieve a competitive advantage using Scrum. This is because the Scrum framework helps you to deliver product features independently, allowing you to focus on delivering high value functionality first.

Teams that forego a disciplined approach to calculating business value are leaving money on the table. Yet many scrum teams do just that; they measure velocity effectively as a way to improve team productivity over time, but rely on very soft qualitative methods to determine backlog order.

This session will explain the sources of business value to different organizations, present a spectrum of methods for calculating business value that range from quick and simple to precise and quantitative, and illustrate the expanded capabilities this quantitative approach provides the Product Owner.

Download it: NPV per Point Template  | Presentation Slides

Watch it: @Agile2014 or on demand (online course!)


Read More

Points vs Hours

Points vs Hours

Estimation is a fundamental building block in Scrum. Without it Product Owners and Scrum Masters will struggle with securing a release date and showing velocity improvement. When adopting Scrum the tendency is to continue approximating in time. Unfortunately, reams of research shows that humans are inherently horrible at estimating in time. It turns out when we estimate jobs by how long they will take us to complete we have an error rate of 400%. 

So, how should we estimate? If we use relative sizing (small, medium, large,) our error rate drops to a more reasonable 50%.  This is why Scrum Inc.’s recommends to estimate the amount of effort it takes get a job done in points. Story points give more exact estimates, drastically reduce planning time and more accurately predict release dates. And, without points, calculating Velocity is impossible. Without Velocity, there is no way for a Team to inspect and adapt and continuously improve, which is the essence of Scrum. 

If your Team is still estimating in hours, stop and watch the online course below.

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

Traditional estimation results in what is quite brilliantly termed “The Cone of Uncertainty.”  The graph shows that beginning estimates of work can range from 400 percent beyond the time actually taken to 25 percent of the time taken. The low and high estimates

Cone of Uncertaintydiffer by a factor of sixteen. As the project progresses and more and more gets settled, the estimates fall more and more into line with reality until there are no more estimates, only reality.

It is often framed as a debate of Points vs Hours, but in reality there is no debate. Estimating in Points is still estimation, an educated guess, but it gives far more accurate, predictable, and stable estimates. Estimating in hours will simply result in estimates that are so far off the mark as to be useless. There are reasons why traditional software projects so often come in late and over-budget. The insistence on estimating in hours instead of Points is a major factor.

 

Reason 1: Humans are Bad at Estimating in Hours

Humans have been able to measure time for millennia but until about 150 years ago (when clocks became more accurate and widely available) measuring time in anything more precise than days was all but unheard of. Essentially, humanity has evolved over hundreds of thousands of years not using hours and, as a result, is bad at estimating in them.

What humans are good at is estimating relative size. Research backs this up. At the outset of the Cold War, the Department of Defense, asked the RAND Corporation to forecast how modern technology would change warfare. (How long will it take for a country to develop a nuclear weapon?) RAND discovered that time-based estimates had large error rates and wide variability, and that humans were much better at estimating relative sizes, particularly those that follow the Fibonacci sequence. (The sequence is effective in estimation because the sum of the quantities of the larger number is equal to the ratio of the larger number to the smaller one. And, as the video to the left so aptly demonstrates, it is a pattern the human race has seen everywhere in the natural world since the beginning of time.)

A recent Microsoft study analyzing two Scrum teams (one estimating in hours, the other in points) showed similar results. The Team estimating in Points had an error rate of +/- 25%, whereas the team estimating in hours had an error rate as large as +/- 400% (denoted as the light grey line in the slide to your right.)

Another advantage of estimating relative size is that it is faster than trying to plan how many hours it will take to complete a job.

Reason 2: Using Hours Undermines Velocity

In Scrum, Velocity is used both to quickly project how much effort it takes to complete a job and as a metric to determine how a change in process effects productivity. (If output goes up, keep the process change, if not revert to the previous process.) If a Team measures in hours, it will be impossible to gauge output or measure productivity.

This is because hours measures input and Scrum is based on measuring output. For example, if it takes one team member an hour to complete a job and another team member two hours to complete the same job, the output (the job being completed) is the same despite the different amount of time put into the job. Estimation of output needs to be the same regardless of who is doing the work. Velocity measures the collective effort of the Team and not the input of an individual team member.

Reason 3: Time is Finite

There are only 40 hours in a typical workweek. If effort is measured in hours, a 5 member Team can never exceed 200 hours of work in a week. Hyper-Productive Scrum Teams increase output by 400% or more. In order to realize these gains when measuring in hours, every team member would have a 160-hour workweek. Not possible and definitely not a Sustainable Pace.

Improvement comes when the overall team becomes more efficient through improving both process and practices. If it once took a team member two hours to complete a job but now she can do it in one, her output has doubled but the time she put into the job has reduced by half. Measuring in hours would never capture her improvement.

As long as it is conceptually tied to time, Velocity will have no value.

Often, organizations are resistant to using points because management is concerned about Teams artificially inflating the amount of points it takes to get a job done. Why not just estimate a job at five points of effort rather than the three that it is actually worth, creating two points of inflation and artificially increasing Velocity?

Regardless of the validity of this concern, Teams are more likely to deflate point value.

For example, the team member who can now complete her job in one hour instead of two might be inclined to estimate that same job at a lower point value in a future Sprint Planning meeting because she feels like it takes her less effort now that she has improved productivity. This is point deflation. Her output is the same so the job should be estimated at the same point value.

However, both inflation and deflation can be measured and controlled using Scrum Management Metrics.

(Hours also suffer from inflationary pressures because they are often used to compare employee effort. Using a technique called Value Stream Mapping shows that few companies achieve process efficiency above 15% without focused effort. No employee wants to admit that out of a 40 hour work week they only accomplished 6 hours of actual work.)

Patterns:

 

Points

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Back to All Topics


Read More

eXtreme Manufacturing

eXtreme Manufacturing

The term eXtreme Manufacturing (XM) was coined by Team WIKISPEED, a non-profit car manufacturer, to describe how it manufactures automobiles combining the Scrum framework, Object-Oriented architecture and eXtreme Programming (XP). Blending these three practices, WIKISPEED invented a new manufacturing process that can shorten time-to-market, reduce labor costs and spur innovation.

eXtreme Manufacturing borrows the basic Agile principles from Scrum. First and foremost, it leverages small, cross-functional Teams, which have a Product Owner and Scrum Master. XM is structured around Sprints to help develop functionality in vertical slices that build overtime. Like Scrum, XM makes development transparent through tools like a Scrum board and a product backlog. It also borrows the concept of tracking process improvements by using Velocity. And, most importantly, it relies on the Lean concept of continuous improvement by employing Sprint Retrospectives and the Happiness Metric. Scrum provides the basic structure for XM.

In this hour long online course, Scrum inventor Jeff Sutherland and WikiSpeed founder Joe Justice discuss eXtreme Manufacturing and how you can implement test-driven hardware development using the Scrum framework. 

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

eXtreme Programming (XP) 

Scrum has adopted many best practices from XP and so does XM. Writing Product Backlog Items in User Story form helps develop products from an end-user perspective. This is particularly useful because XM designs and builds product on a per/contract basis. This helps create more customer-centric products so building a product based on the perspective of the person who will be using the product increases value.

XM also borrows pairing from XP: two people work together on every job. This allows a small team to swarm on a particular task, while cross-training employees and building quality control into the manufacturing process. Pairing also reduces dependency on different skill sets.

XM uses Test Driven Development, or TDD, to dramatically speed up time-to-market and lower development costs. Team WIKISPEED for example used real-time crash test data to build a computer program that simulates an actual crash test. They were able to save millions of dollars in crash tests by simulating them each Sprint. After a number of Sprints accumulating data, WIKISPEED pays for another physical test. The new information is then used to up-date the computer simulation. This lowers material costs since WIKISPEED doesn’t have to destroy a car each time they want to test it and it reduces production costs because crash tests are expensive.

Object Oriented Architecture

Modularity allows for innovative design while building on iterative development. For example, Team WIKISPEED uses modularity for all its components. That allows the team to re-design the suspension system, speedometer or car body at any point and not have to tweak the chassis or dashboard to make the improved components fit. Modularity prevents engineering challenges from rippling through the entire design process. It also allows the team to swarm on the most important improvement without affecting the rest of the car.

Contract First Design: As manufacturing matures, more and more customers are insisting on custom designs. XM embraces customization before the manufacturing process even starts. For example, WIKISPEED takes only custom orders of its commuter cars and is able to easily meet each customer’s need because of the car’s modularity.

XM leverages Design Patterns in two ways: 1) by re-using mature designs with a proven track record and 2) by reducing complexity. Basically, XM doesn’t try to reinvent the wheel. The idea is to take advantage of established technology and techniques to reduce costs of designing specialty parts.

WIKISPEED has incorporated design patterns in a number of ways but there are two clear examples: modularity and inheritance. Modularity we mentioned above. By keeping the same interfaces between all the modules, the team can increase or reduce complexity in any given module without affecting another.

Inheritance is the idea of benefiting from established techniques and technology. WIKISPEED, in its quest to achieve 100mpg didn’t invent a new highbred engine; they used a very established, efficient engine (40mpg) and then reduced weight and aerodynamic drag to cut fuel consumption in half (80mpg.) Just by using less weight, a sleeker design and piggybacking on an established engine they achieved 80% of their goal. To get the remaining 20% they re-tooled some of the engine’s software to get the car to pulse-and-glide. Pulse-and-glide is a hyper-efficient driving technique that increases fuel efficiency. WIKISPEED just automated what is essentially a manual process. No fancy new engine, just good old fashion engineering.

Patterns: 

Happiness Metric

 

Scrumming the Scrum

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Scrum Inc. offers XM Build Parties for corporations and events. Participants build a car from the ground up in 60-minute Sprints. Guided by professional coaches, it’s an inspirational experience that leaves participants confident about conquering their work using Scrum. Because attendees apply the Scrum framework and eXteme Manufacturing to solve complex problems, build parties are a terrific way to win buy-in about agile practices.

Back to All Topics


Read More

Happiness Metric

Happiness Metric

The Happiness Metric is a simple, fast, and effective way of surfacing the kaizen, or process improvement, during the Sprint Retrospective. Everyone knows instinctively that happy people do higher quality work, delight customers, and contribute to a better workplace. More and more, talented people simply won’t work in command and control environments based on punishment and blame, they’d rather be happy.

Here’s the basic outline of how the Happiness Metric works. During the Sprint Retrospective each person on the Team answers just a few questions:

      1. On a scale from 1–5, how happy are you about your role?
      2. On the same scale, how happy are you about the company?
      3. Why do you feel that way?
      4. What one thing would make you happier in the next Sprint?

That’s it. It can be done in a just a few minutes. Every person on the team takes a turn, and it can spark quite insightful conversations. Together the Team usually comes up with a kaizen quite quickly. The method exposes what is most important to each Team member and what they think is most important for the company.

This one-hour online course with the Scrum co-creator Jeff Sutherland will show you in detail why maintaining your Team’s happiness is absolutely crucial to accelerating your Velocity

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

Patterns: 

Happiness Metric

 

Scrumming the Scrum

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Back to All Topics


Read More
content top