Scrum That Art of Doing Twice the Work in Half the Time Palm

Insights from the book 'Scrum: The Art of Doing Twice the Work in One-half the Time' by Jeff Sutherland.

Fourth dimension to Read: eight:26 minutes

Exercise you observe most projects starting time off smashing but cease up existence a total nightmare to manage midway through?

Thanks to Jeff Sutherland's book 'Scrum: The Art of Doing Twice the Piece of work in Half the Fourth dimension' I no longer have project nightmares.

The Problem with Near Projects

The traditional method of executing a project goes something like this:

• ane person is responsible for estimating and sequencing the activities needed to complete the project (makes assumptions for areas he/she is not an expert in)
• managers assign people to complete the activities
• the team sticks to the original program until the project is complete (management assumes the original gauge will remain relevant throughout the entire project life-cycle)
• any change is seen as a threat to the project
• boosted resources are spent trying to get the project back on rail, according to the original (outdated) plan

This rigid approach to project management can often create products the client doesn't actually need in the cease.  It delivers a product that is more then they actually require and toll more than money then they were willing to spend!

This traditional project direction method is chosen the 'Waterfall' method.  In the volume 'Scrum', author Jeff Sutherland reflects on his experience with the 'Waterfall' method:

"The process was slow, unpredictable, and frequently never resulted in a product that people wanted or would pay to purchase.  Delays of months or even years were endemic to the process.  The early step-past-pace plans, laid out in comforting detail in Gantt charts, reassured management that they were in control of the development process – but nigh without neglect, we would fall quickly backside schedule and disastrously overbudget." – Jeff Sutherland

The shortcomings of the 'Waterfall' method can exist explained by the shortcomings of the human mind.  Psychologists have found that nosotros all use irrational mental shortcuts from time to time and are not aware that nosotros are doing so.  Psychologists call these shortcuts 'cerebral fallacies'.  Here are a ii fallacies that the traditional 'Waterfall' method falls prey to:

one. Planning fallacy

The planning fallacy was first introduced past Daniel Kahneman and Amos Tversky in 1979. It states that we chronically underestimate the time it takes to complete something (fifty-fifty if we are enlightened of the phenomenon) because of our overconfidence in completing common tasks and our tendency to focus on a single isolated event without considering the influential factors.

A 1994 study called 'Exploring the planning fallacy: Why people underestimate their job completion times' asked 37 psychology students how long it would take them complete their thesis – identifying the all-time and worst-case scenarios.  At the finish of the study, researchers found that the actual completion dates occurred an average of 7 days after than the pupil's worst-case estimates.  Just 30% of students were able to stick to their original estimates.

We suffer from the planning fallacy whenever we estimate mid to big size projects.

"Estimates of work tin range from 400 percent beyond the time actually taken to 25 percent of the time taken. The low and high estimates differ past a factor of sixteen. As the projection progresses and more and more than gets settled, the estimates fall more and more into line with reality until at that place are no more estimates, just reality." – Jeff Sutherland

Therefore, a project programme is only useful if it can be refined in increments and updated according to the latest information we receive.

"The key is to refine the programme throughout the projection rather than practise it all up front end. Programme in simply enough detail to evangelize the next increase of value, and estimate the remainder of the project in larger chunks. In Scrum, at the end of each iteration you lot have something of value that you can see, touch, and prove to customers. You tin ask them: "Is this what you want? Does this solve at to the lowest degree a slice of your problem? Are we going in the right management?" And if the answer is no, change your plan." – Jeff Sutherland

It is important to program our projects.  Just we must ensure nosotros practise not 'over plan' our projects.

 "A good plan executed violently now is improve than a perfect programme executed next week" – General George S Patton Jr.

2. Sunken price fallacy

If we employ a big amount of time and resource to generate a project gauge we become overly attached to it.  This attachment causes us to defend an original gauge, get over budget trying to maintain information technology and disregard new information that conflicts with it.   When this occurs we are suffering from what psychologists call 'the sunken cost fallacy'.

"The sunk-cost fallacy keeps people for too long in poor jobs, unhappy marriages, and unpromising research projects. I accept frequently observed young scientists struggling to salvage a doomed project when they would be improve brash to drib it and starting time a new ane." – Daniel Kahneman, Nobel Economist and author of 'Thinking, Fast and Wearisome'

If our initial estimate is too detailed we forget the true intent of the project and make the 'plan' the priority.

These two fallacies cause countless frustration when managing projects.

---

A New Mode

In the 90's, Japanese professors Hirotaka Takeuchi and Ikujiro Nonaka did extensive enquiry on some of the most effective companies in the world and found that they conducted projects in a radically different mode then the Waterfall method.

Jeff Sutherland, writer of 'Scrum: The Art of Doing Twice the Piece of work in Half the Fourth dimension', used Takeuchi and Nonaka'due south inquiry to develop a project management system called 'Scrum' in the early 1990's.  Since then companies like Google, Amazon, Salesforce.com, Toyota and the FBI have used Scrum and continue to use it.

"Scrum has its origins in the globe of software development. Now it'due south sweeping through myriad other places where work gets done. Various businesses are using it for everything from building rocket ships to managing payroll to expanding human being resource, and it's also popping up in everything from finance to investment, from entertainment to journalism. Scrum accelerates human being endeavor— it doesn't matter what that endeavour is." – Jeff Sutherland

Scrum can be used in almost every environs and on every blazon of project.  I've used Scrum on my engineering projects and I now apply information technology manage my website.

The seven Steps of a Scrum Project

Place the product possessor (visionary), Scrum main (squad facilitator) and a small team of 3 to 9 people that accept all the skills necessary to consummate a project phase.

(Scrum Sprint Checklist PDF – receive a condensed one-folio checklist of the Scrum method)

1. Create and Prioritize a Backlog (production possessor responsibility)
   • List everything that needs to exist completed past the team, for the entire project, in narrative format: who, what, why (who'll be getting value from it, what exactly do they need and why do they need it – "As an X, I want Y, then that I can practice Z").
     • make each item minor enough to estimate.
     • make each item independent of other items (items tin be considered "consummate" on their own).
     • ensure each item is 'testable' when completed (decide a testing method that you can use deem the item "consummate").
   • Rank the items in terms of their client value.
   • Items that can provide immediate value and with relatively very lilliputian risk should be at the top of the list (prioritize items based on how quickly they can be demonstrated and used to generate revenue).
2. Refine and Gauge Excess Items (team's responsibility)
   • As a team, assign a Fibonacci number to each particular: ane, ii, iii, 5, viii, xiii (a natural progression in nature that humans naturally detect easier to make comparisons with).
   • Outset with one of the hardest/well-nigh complex items and assign it a value of 13 (use a higher Fibonacci number, like 21, 34 or 55 for very large projects).  Make a relative comparing to this first particular when assigning values to all other items.
   • "Do not estimate the Excess in hours, because people are absolutely terrible at that" – Jeff Sutherland.
3. Bear a Sprint Planning Session (atomic number 82 by the Scrum master)
   • Establish a fixed dart duration for the project that is no longer than 4 weeks (most people run a 1 or ii week Sprints).
   • Accept the squad determine how many points they think they can complete during the first Sprint (after the first Sprint they will take a benchmark value to utilize for future Sprints – aiming for a few more points each successive Sprint).
   • Once the squad has committed to what they think they tin can finish in one Sprint, that's it.  It cannot be changed or added to.
4. Make Work Progress Visible (Scrum master's responsibility)
   • Create individual mail service-it notes for each dart item and put them in one of three columns: Practise, DOING, Washed.
   • Move an item to 'washed' straight after completing it.
   • Update the Burndown Chart at the showtime of each 24-hour interval (a graph with 'Sprint points' on the y-axis and 'Sprint days' on the x-centrality – starting with the total initial number of story points selected for the Dart)
     • The end result should be a steep downward slope that ends with zero points remaining on the final day of the Sprint.
5. Conduct Daily Stand up-up Scrum Meetings (atomic number 82 by the Scrum main)
   • Each day, at the same time, for no more than fifteen minutes, the team and the Scrum Master run across and answer iii questions:
     • What did we do yesterday to help the squad finish the Sprint?
     • What can we do today to help the team finish the Sprint?
     • What obstacles could slow down our progress?
6. Host a Sprint Demonstration (team's responsibility)
   • Invite all project stakeholders (customer, product owner, management, etc.).
   • Bear witness the results of what was completed during the last sprint.
   • Only show items that encounter the 'Definition of Done' (information technology does not need to be a complete production, but it should take at to the lowest degree ane functional feature).
7. Conduct a Sprint Retrospective Session (pb by the Scrum principal)
   • Assemble feedback and comments from the demonstration session.
   • Get the team together and take candid, solution-oriented discussion to answer the following questions:
     • What went well?
     • What could take been better?
     • How tin we improve the next Dart?

Echo steps 1-7 (briefly re-assessing steps ane & ii each sprint) until the customer is satisfied with the end result.

When you follow this method of piece of work you don't need to work as much.

Maxwell Curve chart from the book 'Scrum: The Fine art of Doing Twice the Work in Half the Time' by Jeff Sutherland (Affiliate 5)

Why Scrum Works

Scrum works great because information technology embraces the following truths:

Compounding Improvement

Thanks to daily standup meetings and retrospective sessions scheduled no longer than 1 month a Scrum projection continuously improves.  Each improvement is build upon the previous improvement.  When you better a project process in this fashion y'all experience compounding improvement (aka: exponential improvement).

Virtually people are unable to grasp the power of compounding (me included!).   We are all linear thinkers by nature.  If I told you to take 30 linear steps 1 meter at a time, how far would you lot go?  Easy, thirty meters.

Merely what if I told y'all to take xxx exponential 1-meter steps: 1m step + 2m footstep + 4m step, etc.  How far do you recall you lot would be able to get?

Taking 30 exponential steps you lot take your 1,000,000,000 meters away from where you started.  With 30 exponential steps you would circle the world 78,000 times.

By having brusque sprints and frequent demonstrations nosotros are able to harness the power of exponential improvement on our projects.

80/xx Product

In 1896, Italian economist Vilfredo Pareto found that most things follow an fourscore/twenty distribution – 80% of the land was owned by xx% of the population, 80% of the wealth was in the hands of 20% of people, eighty% of his peas grew from 20% of the pea pods.  The Pareto Principle has become known as the 'law of the vital few': the majority of the output comes from a vital few inputs.  Translated to our projects: the bulk of value we deliver comes from a vital few tasks.

Past finding and focusing on the xx% of available tasks on a given project for a given sprint we reduce the chances of working on something the client may not need.  The dart elapsing should just permit plenty time for 20% of the initial project activities to be completed earlier the next sit-in.

Compounding Value Chart from the book 'Scrum: The Fine art of Doing Twice the Work in Half the Time' past Jeff Sutherland (Chapter eight)

When you deliver 80% value later on each twenty% time duration you end up delivering 350% of the expected project value (assuming you perform five 20% sprints during the project life-cycle – 80% value x v sprints = 350% overall value).

Reduced Decision Fatigue

If you don't piece of work in sprints (doing frequent demonstrations and retrospective sessions), y'all're likely to waste a great deal of time doing things that are not essential to the project.  This will require you to accept actress time (overtime) to go the essential project components completed.

Working overtime leads to poor decision making.  Poor determination making leads to mistakes, which leads to more work.  It becomes a down spiral towards burn out.

"People who piece of work too many hours start making mistakes, which, as we've seen, can actually take more endeavor to gear up and so to create. Overworked employees get more distracted and begin distracting others. Soon they're making bad decisions." – CEO of Venture Uppercase business firm OpenView states as detailed in the book 'Scrum: Twice the work in the half the time'

Scrum validates results throughout the project lifecycle and ensures that very footling time is wasted doing activities that produce minimal value.  The system of Scrum forces y'all to be constructive with your fourth dimension and avoid overtime.  When you lot reduce overtime you reduce conclusion fatigue and the rework that results from decision fatigue.

Intrinsic Motivation

In the volume 'Bulldoze: The Surprising Truth About What Motivates U.s.', author Daniel Pinkish explains that people are driven past iii powerful intrinsic motivations: purpose, mastery and autonomy.  It turns out that intrinsic motivators terminal longer and are much more powerful than extrinsic motivators (i.e. more money).

Scrum taps into our 3 intrinsic motivators in the following style:

• Purpose: all team members establish and share a common goal to deliver the most value in the shortest amount of fourth dimension.
• Mastery: continual improvement combined with visual progress generates a sense of mastery.
• Autonomy: squad members focus on results instead of activities.

The TAKEAWAY

Utilize Scrum to brand your projects vastly more enjoyable, rewarding and efficient than traditional projection management methods.

What Now?

Plough your adjacent project into a Scrum project by following the 7 steps of Scrum (click here for a handy one-page Scrum Sprint Checklist PDF).

kirbywifemely.blogspot.com

Source: https://www.productivitygame.com/twice-the-work-half-the-time/

Share this post