Scrum Log Jeff Sutherland

Scrum and Organizational Patterns

2013-05-20T08:29:00.000-04:00

In the early days of what we now know as Agile processes, Mike Beedle was influenced by the online description of Scrum, implemented the process in his own company, and led the effort to drive Scrum through the Pattern Languages of Programming Design conferences. This made Scrum the first (and only) formal organizational pattern that describes a complete Agile process. One of the patterns books contains the Scrum pattern:

M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed. Boston: Addison-Wesley, 1999, pp. 637-651.

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns. Click here for details of Jim's presentation on Scrum and patterns.

One of Scrum's design goals was to encapsulate best practices from 40 years of software development into a process that was simple enough for the average IT worker to use for development in less than 2 days of startup time. Jim's research shows that we did a good job of accomplishing that goal. You can download a copy of the original Scrum pattern language as it is part of a draft of "The Scrum Papers."

In recent years the Scrum Patterns Group has evolved a comprehensive set of patterns for Scrum that allow teams to try proven approaches that have worked in many companies. While the Scrum Guide provides the basic rules of Scrum, the patterns amplify the guide by showing teams how to solve problems in a specific context.

Scrum should be fast, easy, and fun. For many new Scrum Masters, it is slow, hard, and painful. Using proven patterns for starting up a new team or accelerating an existing team can rapidly eliminate a lot of Scrum Master headaches.

Story Points: Why are they better than hours?

2013-05-16T01:33:00.000-04:00

Traditional Estimation Funnel

Microsoft Story Point accuracy

Story points give more accurate estimates, they drastically reduce planning time, they more accurately predict release dates, and they help teams improve performance. Hours give worse estimates, introduce large amounts of waste into the system, handicap the Product Owner's release planning, and confuse the team about what process improvements really worked.

Interesting new research has become available. The Standish Group has updated their findings on project success rates based on analysis of the last decade of data with tens of thousands of data points. In addition, Microsoft has new research findings showing that agile estimation is astoundingly more accurate than traditional project estimation. See:

Scrum + Engineering Practices: Experiences of Three Microsoft Teams
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
IEEE Best Industry Paper award winner

Many people who have managed projects with hours have a hard time understanding why story points are better. They have failed to understand some fundamental data that has been published for over 60 years in the industry literature as well as the latest research.

First, let's look at the latest data on project failures. Failure rates are increasing for IT projects during the current disruption of the global financial system. The latest Standish group analysis shows that agile projects have three times the success rate of traditional projects. Jim Johnson now recommends agile practice be used universally on all projects.

In fact the latest Forrester Group research shows that:
Common Project Management Metrics Doom IT Departments to Failure

The venture capitalists I work with say they have never seen a correct GANTT chart in a board meeting. When they dig down into the problem they say none of their management teams knew the velocity of their teams before they implemented Scrum. Not knowing the velocity of production of the teams is the root cause of 100% failure of release plans to be accurate in their board meetings.

The stability of a user story is critical for planning. A three point story today is three points next year and is a measurable part of the product release for a Product Owner. The hours to do a story depend on who is doing it and what day that person is doing it. This changes every day. The GANTT chart assumes a fixed number of hours for some fictitious person (who often is not the person to implement) and assumes fixed dependencies (which are always changing). A study of 80 multimillion dollar projects at GSI Commerce (now owned by eBay) showed that the best experts in the company were totally incapable of estimating how much time a project would take by the people who actually implemented it.

You would think these data would cause people to change their behavior but many companies seem to prefer to continue to fail and be acquired or go bankrupt rather than improve their project management techniques.

Rand Corporation research in the 1940's showed clearly that humans are not good at estimating hours and practical experience repeatedly confirms the research. The recommended the Delphi approach to estimation which was adopted in software development as the Wide Band Delphi technique. The same technique is now embedded in the practice called Planning Poker for agile teams.

The management metric for project delivery needs to be a unit of production. Production is the precondition to revenue and companies say they are in business to grow revenue and margins (even though in project planning they often do the opposite). At least a venture capital group is clear that it is all about the money and money comes from velocity of production combined with quality of the product. Hours are expense and should be reduced or eliminated whenever possible.

The best data on individual developer performance comes from Yale University and has been reported previously on this blog. The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours (within a project) or 25 hours (across projects). For teams the difference is an order of magnitude greater. Larry Putnam's published data show that an hour for the most productive team turns into 2000 hours for the least productive team.

Hours completed tell the Product Owner nothing about how many features he can ship and when he can ship them.

The important metric is the number of story points the team can deliver per unit of calendar time. The points per sprint is the velocity. Therefore we estimate everything in points for the Product Owner so that he create a release roadmap based on team velocity and adjust the plan if velocity changes.

The way we do story point estimation gives better estimates than hourly estimates as they are more accurate and have less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80% allowing teams to do more estimation and tracking than a typical waterfall team. A telecom company noticed that estimated story points with planning poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

For a complete break down on the points vs. hours debate see Scrum Inc.'s webinar on the topic.

Why Should Agilists Care About Capitalization?

2013-05-02T14:29:00.000-04:00

Guest Blogger Vince Mills

In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. One large company’s confused finance department expenses all agile software development and capitalizes waterfall development; projects in this company that go agile see their headcounts cut by 50%. This discourages projects from going agile.

Scrum’s production experiment framework can align well with the principles of financial reporting. In this article, the author explains the basics of capitalization and expensing, and offers a financial framework for capitalizing agile projects that can be understood by both accountants and agile teams.

Software development is an investment in the long-term future. Some software development projects are not long-term investments; it depends on whether the software remains an asset. Agilists should learn proper capitalization and teach their colleagues. Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development correctly.

Companies can gain tax advantages by capitalizing software development; by deferring costs they typically offset more taxable revenue and gain more interest income.

Corporate agilists need to help finance departments capitalize agile software development properly. ScrumMasters and agile department heads who understand capitalization and depreciation can generate millions in tax savings. Responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.

Because recommended accounting practices ignore Agile, the article discusses how to classify costs as capital or operational expenses and gives guidance on how to make the transition from waterfall to Agile in a way that pleases management, accountants and auditors.

Making the case for agile capitalization will reduce your company’s tax burden, increase available funds for engineers, and make your auditors happy.

Hackathons: Developing Developers

2013-04-26T15:56:00.001-04:00

Next weekend the sponsor AngleHack and two student groups at UCLA are throwing a huge hackathon. LAHacks will bring together students and alumni from Southern California’s premier technical schools in hopes of fostering a more cohesive start-up community. It seems that So Cal is struggling to create the same kind of start-up magic that Boston, New York City, and the San Francisco Bay area have achieved.

Hackathons are becoming more popular and are a Scrum Pattern for good reason. First, they bring people together in a creative and voluntary environment. This encourages people to bond over activities of their choice, helping team members to form stable relationships, which can lead to better team performance and collaboration.

Second, they produce interesting results. Facebook has been throwing hackathons since 2007. These all-night coding sessions have produced many valuable features for the social media giant including the Like Button, Timeline and Chat.

Third, if used strategically, Hackathons can slow development down a bit, allowing the organization to deal with constraints in other divisions.

But most importantly, they help developers merge their personal interests with their company’s financial interest. Hackathons give workers the opportunity to have a meaningful relationship with their employer by giving them the autonomy to master features and products that they enjoy while creating value for their company. Research shows again and again that mastery, autonomy and contributing to a community motivates people much more than higher salaries. Hackathons allow workers to help their company and colleagues, plus they aid in recruiting and retaining a motivated workforce.

Scrum Inc. recommends that companies throw hackathons regularly to free people up to be more creative and interactive. The value of hackathons is hard to quantify but one quick look at Google, which allows their employees to work on personal projects 20% of the time shows that when a company emphasizes creativity, awesome things happen.

-- Joel Riddle

Why Hours Don't Work

2013-04-19T12:09:00.000-04:00

There has been a lot of debate within the business world about the merits of time sheets. Some think tracking hours is an important metric while others feel that they are a waste of time. In the Scrum community there is a similar debate: should the team use points or hours when estimating backlog items?

Scrum Inc. recommends using points because hours are problematic on a number of levels. One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output. We use a variety of examples to illustrate this, but two recent news headlines drive the points home, so to speak.

The first story surfaced several weeks ago and involves the big law firm, DLA Piper. In an effort to collect fees, the firm sued a client. The client refuted the billing. During the ensuing discovery process a number of incriminating e-mails surfaced revealed the lawyers on the project overstaffed and had the team performing gratuitous tasks:

“Now Vince has random people working full time on random research projects in standard ‘churn that bill, baby!’ mode... That bill shall know no limits.”

The second example involves healthcare. This week a case study released in The Journal of the American Medical Association showed how medical errors actually increased one hospital group’s bottom line. A mistake like forgetting to remove a gauze pad from a patient during surgery results in further interventions and longer hospital stays, forcing insurers to cover costs created by the hospital’s own mistakes.

Much of the outrage involving these stories focuses on ethical lapses. Let’s not forget bloating time sheets is not only is it unethical, it is poor business.

If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill. The business value is in serving the client’s needs, not in wasteful or fabricated services. For the hospital group business value is derived from healing people and not from long hospital stays and unnecessary surgeries. This is why many efforts to reign in healthcare costs focus on quality of outcome rather than quantity of care given.

Both industries have business models that measure input (billable hours or number of services provided) rather than outcome and both professions are currently in crisis. Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.

Let’s not forget that time is finite, another problem with estimating in hours. After all, there is a reason lawyers and doctors sometimes work upwards of 100 hours a week. If their business models incentivized quality of outcome, doctors and lawyers could simply improve their efficiency, make the same amount of money working a lot less.

Work less! Estimate in points.

Learn more about how using Points can vastly improve your Scrum in our April Webinar.

-- Joel Riddle

Nativity Scene: How Scrum was Born!

2013-04-16T02:41:00.000-04:00

IROBOT's Genghis Khan now in the Smithsonian

I joined Easel Corporation in 1993 as VP of Object Technology after spending 4 years as President of Object Databases, a startup surrounded by the MIT campus in a building which housed some of the first successful AI companies.

My mind was steeped in artificial intelligence, neural networks, and artificial life. If you read some of the resources on Luis Rocha's page on Evolutionary Sytems and Artificial Life you can generate the same mind set.

I leased some of my space to a robotics professor at MIT, Rodney Brooks, for a company now known as IROBOT Corporation. Brooks was promoting his subsumption architecture where a bunch of independent dumb things were harnessed together so that feedback interactions made them smart, and sensors allowed them to use reality as an external database, rather than having an internal datastore.

Prof. Brooks viewed the old AI model of trying to create an internal model of reality and computing off that simulation as a failed AI strategy that had never worked and would never work. You cannot make a plan of reality because there are too many datapoints, too many interactions, and too many unforseen side effects. This is most obviously true when you launch an autonomous robot into an unknown environment.

The woman I believe will one day be known as the primieval robot mother by future intelligent robots was also working in my offices giving these robots what looked like emotional behavior. Conflicting lower level goals were harnessed to produce higher goal seeking behavior. The robots were running in and around my desk during my daily work. I asked IROBOT to bring Ghenghis Khan to an adult education course that I was running with my wife (the minister of a local Unitarian Church) where they laid the robot on the floor with eight or more dangling legs flopping loosely. Each leg segment had a microprocessor and their were multiple processors on its spine and so forth. They inserted a blank neural network chip into a side panel and turned it on.

The robot begain flailing like a infant, then started wobbling and rolling upright, staggered until it could move forward, and then walked drunkenly across the room like a toddler. It was so humanlike in its response that it evoked the "Oh, isn't it cute!" response in all the women in the room. We had just watched the first robot learn how to walk.

That demo forever changed the way the people in that room thought about robots, people, and life even though most of them knew little about software or computers.

This concept of a harness to help coordinate independent processors via feedback loops, while having the feedback be reality-based from real data coming from the environment is central to human groups achieving higher level behavior than any individual can achieve on their own. Maximizing communication of essential information between group members actually powers up this higher level behavior.

Around the same time, a paper by Christopher Langdon was published out of the Santa Fe Insitute mathematically demonstrating that evolution proceeds most quickly as a system is made flexible to the edge of chaos. This demonstrated that confusion and struggle was essential to emerging peak performance (of people, or software architectures, both of which are journeys though an evolutionary design space). It also showed clearly why waterfall projects slow down as you add people, methodologies, roles, meetings, and reports.

On this fertile ground, the Takeuchi and Nonaka paper in the Harvard Business Review provided a name, a metaphor, and a proof point for product development, the Coplien paper on the Borland Quattro Product kicked the team into daily meetings, and daily meetings combined with time boxing and reality based input (real software that works) started the process working. The team kicked into a hyperproductive state in March of 1994 (only after daily meetings started), and Scrum was born.

Scrum & Big Data

2013-04-10T18:12:00.000-04:00

I’ve been reading Viktor Mayer-Schoenberger and Kenneth Cukier’s stimulating new book Big Data: A Revolution That Will Transform How We Live, Work and Think. The premise of the book is, now that civilization has the tools to both collect and analyze huge amounts data, correlation is far more telling than causality. Meaning, that when dealing with billions of data point rather than hundreds, knowing the what, rather than why is good enough.

One example the authors use frequently is how Google was able to comb its massive trove of search queries on common flu symptoms to discover where the 2009 H1N1 flu epidemic was spreading.

The CDC was doing the same thing using traditional sampling techniques. Google’s method was more accurate and in real-time (two weeks ahead of the CDC survey,) a huge advantage in controlling the outbreak. Thanks to Google, the CDC learned thewhat (ironically the where in this case) but not the why (which H1N1 carrier was the vector.) And that was good enough to help stem the spread of the virus.

Despite the messiness of Google’s data, it was far more effective because of its size. Big data analysis was made possible by easy access to Google’s search engine (3 billion searches a day,) large servers to store the information and clever algorithms to sort the data into something meaningful.

A corner stone of Scrum is its ability to measure work output i.e. Velocity. As the authors ofBig Data point out, much of human knowledge is based on the ability to measure a given phenomenon. Once we can measure it, we can start to manipulate the input and determine if we’ve improved something by the resulting output. (Doing this again and again is continuous improvement, the impetus of Scrum.)

Because Scrum has made work measureable in more accurate ways than ever before, we could digitalize the metrics and create a huge searchable data set. For example, Microsoft has had over 3000 Scrum team members for several years. Imagine the possible insights if all that data were pooled and subjected to smart algorithms. Or, if companies that build and maintain virtual Scrum boards started storing all Sprint data from every client using their tools.

Perhaps we could see that adding a new team member results in a temporary drop in productivity but an overall long-term gain. Managers could hold off adding a team member before a key product release. Or perhaps the data might show that teams were more productive when working only 6 hours a day instead of eight. The possibilities are really exciting.

By using big data techniques, no longer would thought leaders in the Scrum community have to conduct case studies or theorize about what might create a process improvement. Nor would Scrum Masters need to tweak their process and wait until the end of the Sprint to see what the results were. Rather, they could simply query the data set and get an answer immediately.

Big Data is a big deal.

-- Joel Riddle

Know the Scrum Basics: Get Your Velocity Right

2013-03-15T13:39:00.000-04:00

This month, Scrum Inc.’s monthly webinar focuses on fundamentals and correcting bad Scrum habits. While a majority of us feel like we get the basics right, Scrum Inc. surveys and independent polls find that while most Teams understand the basics, many skip at least one key practice.

Most commonly, respondents indicate that their teams don’t calculate Velocity. Without Velocity, there is no way to measure improvement, have transparency and visibility into your process or properly plan a Sprint or a release.

How it Works

Break work into small tasks. Give these tasks, called User Stories, a point value by estimating their relative sizes. (Relative size is important because studies show that humans are incredibly poor at estimating jobs in hours.)

During Sprint Planning, the Scrum Master plays dealer in a game of planning poker. The Scrum Master starts the game by taking a User Story and having all members of Team chose a card with a number they believe relates the relative size of the task. The Scrum Master counts to three and all Team members reveal their cards simultaneously. The Team members with the lowest and highest cards debate the reasons for their choices and then the team plays another round. The process repeats until a consensus is reached. Continue the game until the all tasks have a point value.

During the Sprint, as each task is moved to done, the Scrum Master can plot the points over the length of the Sprint. At the end of the Sprint all the points added together is the Velocity.

As the Team completes more and more Sprints, the Scrum Master can compare how much the Team has improved. Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint.

Remember, just because the team has gotten better at implementing any given story, the point value you should remain the same. If the Team starts to estimate stories at lower values because they have incurred substantially more experience and the stories seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work.

Teams shouldn’t obsess about how many points something is worth. Estimating points is just an exercise to help quickly evaluate relative effort. The important thing is that you are consistent and that the entire team has a common understanding of their system for sizing.

Whether you are new to Scrum or a long time practitioner, getting the basics right will definitely improve your Velocity. On Tuesday, March 26^th we will be exploring Velocity, Retrospectives, Backlog Grooming and the rest of the Scrum Fundamentals. Please join us.

-- Joel Riddle & Christine Hegarty

Be Critical, Scrum and Feedback

2013-03-11T17:02:00.000-04:00

There was an interesting radio piece on American Public Media’s Market Place the other day. Host Kai Ryssdal talked with Stephan J. Dubnar of Freakonomics fame about what the latest academic research on feedback tells us.

Here’s how it breaks down: to get people to commit, positive feedback is shown to be really helpful. So if you have a new Team member, the Team and the Scrum Master should see substantial improvement in that new member’s commitment by focusing comments on what that team member is doing well.

However, once that Team member is fully on board, a Scrum Master would see diminishing returns from continued positive feedback. To get increased performance at this point, critical feedback is the only game in town. Basically, if you want improvement out of a committed Team, you have to point out what they are doing wrong and help them find a better way to complete their tasks.

The other interesting finding is that the more expertise someone has, the more they tend to filter out positive feedback. So if you have a great coder with 20 years experience, giving him or her props isn’t going to do much.

You can read all the research the story was based on here.

-- Joel Riddle

Call for Papers: Agile and Lean Organizations, HICSS 2014

2013-03-06T20:23:00.003-05:00

Now in its 47th year, the Hawaii International Conference on System Sciences (HICSS) is one of the longest-standing continuously running scientific conferences. This conference brings together researchers in an aloha-friendly atmosphere conducive to free exchange of scientific ideas. The next conference will be held January 6 through 9, 2014 at the Hilton Waikoloa Village on the Big Island.

If you've been doing innovative work or research on agile methods, here's an opportunity to present and collaborate with like-minded agilists, in a tropical setting. Submit your paper to the HICSS 2014 Agile and Lean Organizations minitrack by June 15, 2013.
Agile development methods promote iterative product releases and drive risk-reduction earlier in product development. Characteristics include: cross-functional teams, automated testing, continuous builds and deployment, pair-programming, bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test hypotheses and rapidly adapt to discoveries. Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction and customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient use of development staff.
In this minitrack, we seek research papers and experience reports that describe how agile development and lean product management interact with organizations, their structures, cultures and products:

What evidence-based guidance can we provide to leaders to help motivate, create and sustain agile/lean organizations? How do agile development and lean product management interact with product groups, departments, companies?
How do organizations restructure to support these philosophies and when they do not restructure, what happens?
What cultural requirements and/or training are needed for companies to maintain agile behavior?
How do organizations structure coaching, training, mentoring, Scrum Mastering?
How do they identify metrics, measure improvement, and improve?
How do markets respond to rapid iterations and end-user experimentation?"

Submission guidelines are available here. If you are interested in reviewing articles for the Agile and Lean Organizations mini-track, please contact Dan Greening at dan@senexrex.com
We're looking forward to seeing your submission, and seeing you at HICSS 2014 on the Big Island of Hawaii!

Mini-track chair Dan Greening is the Managing Partner of Senex Rex, a management and training firm. He helps international enterprises plan and manage sustainable agile transformations. He currently manages agile coaching at a large international software company. He previously led transformations at Citrix Online and Overstock.com. He developed portfolio management and finance strategies for agile projects. In previous lives, he was Principal Investigator for 3 NSF SBIR grants, created three product startups, worked at IBM Research, and delivered newspapers in the rural Midwest.

The Serenity of Flow

2013-03-04T16:04:00.000-05:00

The Certified Scrum Master class attendees were off and running on a self-organization exercise. The drill was simple: plan, build, and test as many paper airplanes as you can in 3 minutes.

I was busily preparing for the next class module when I gradually became aware of what was transpiring: “Twenty-four”, “Twenty-five”, “Twenty-six”… like the coxswain of an Olympic crew team, the Product Owner called out the production count. With heartbeat regularity, every two seconds another paper airplane floated gracefully across the room, nosed into the exact same spot on the projection screen and settled gently into a tidy pile on the floor.

Their product design? Standard. Their manufacturing process? Pretty conventional. But for 180 seconds in Munich, aptly-named “Team Front” achieved the perfect state of Flow that we wish for all our Scrum teams.

Congratulations to “Team Front” on their new world record! Pictured (from left to right) are: Oliver Heerdegen, Chris Holland, Todor Ganebovsky, Karla Korb, Thomas Bohne, Katrin Sulzbacher, Norbert Toth-Gati, and Klaus-Rüdiger Hase.

Flow is that transcendent state where, with very little explicit communication, team members mesh into perfect formation, each contributing equally and to their utmost toward a singularly shared goal. Eight individuals who had been complete strangers only hours before were working in complete unison as if they had trained together for years.

When the clock stopped, the tidy pile of planes had reached 32…shattering the previous Scrum record of 28.

We spend so much of our time in the Scrum community focused on the nuances of running Scrum: How do I manage teams across multiple locations? How do I balance a sustainable pace with Velocity? But sometimes it is important to take a step back and just appreciate the simple joy of achieving Flow.

-- Alex Brown

Wanna take a crack at breaking the record? Click here to take course with Jeff.

Is Your Family Agile?

2013-03-01T19:42:00.003-05:00

New York Times columnist and author Bruce Feiler has just published a new book titled: The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More. The secret it turns out is applying agile development to your household.

Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.

Scrum: savior of the modern American family? Watch and decide for yourself.

You can listen to an NPR review and an interview with Bruce Feiler here and here.

Wanna learn more about Agile and childhood? Click here for Scrum in schools.

-- Joel Riddle

Everyone Scrum!

2013-02-26T15:14:00.003-05:00

By Joel Riddle

Scrum is exploding across the industry according to the latest annual State of Agile Survey. Yesterday I talked to Robert Holler, CEO of VersionOne, a maker of agile tools and the sponsor of the survey. He believes the most dramatic number is a 14% increase in people planning to implement agile projects in the future. That forward-looking metric coincides with an increase in the number of companies scaling Scrum (a 15 point up-tick.) Why the bump?

Holler attributes this increase to a decade of compelling evidence. Scrum has consistently shown to mitigate risk, accelerate time to market and effectively manage change, and the message has gotten out. Go agile, or go under.

Given the typical lifetime adoption cycle of new technologies, Holler predicts this year and next will be a tipping point for agile methodologies. In another decade, agile will be completely mainstream.

What’s Your Impediment?

According to the survey, Scrum Masters should be spending a lot of time mentoring Product Owners (POs) and executives. Of the over four thousand respondents only one percent found POs to be Scrum savvy. Executives faired slightly better with a whopping two percent. (Find out why managers need Scrum in our webinar.)

Not a big surprise. At Scrum Inc., we consistently see POs struggling to grasp what the customer really wants and translating that vision into a product backlog. The PO needs to understand the business value of multiple product features; meet customers’ unknown needs and prioritize the work in order to maximize return on investment (ROI). Those skills are hard to find in one person and even harder to execute. POs can be a real lynch pin in Scrum. A company that doesn’t value its POs isn’t going to get the most out of agile.

Who’s the Boss?

Executives get a bad wrap, and no doubt many in the C-suite may not appreciate the self-organizing nature of Scrum. However, given the strong up-tick in companies adopting and scaling Scrum and the recent emergence of management metrics in the Scrum community, executives seem to have caught on. The survey found that executive buy-in is the number one factor to successful agile implementation.

We are the World

The best news for Scrum Inc. is that 72% of all agile practitioners use Scrum or a Scrum variant. Basically, if you are adopting an agile method and want to have a well trained and knowledge staff, go Scrum.

View the cool survey info graphic here.

2013-02-22T17:35:00.001-05:00

It’s important for Scrum Teams to re-evaluate their practices from time-to-time. Based on results from our online Self-Assessment, we know most of you are adhering to best practices and excelling.

Many teams do almost everything except for ‘that one thing.’ Leaving even one basic scrum principle out of the Team’s practice has a ripple effect on overall performance. That’s why this month we are getting back to basics!

METRICS

Know Your Velocity! Despite being the most fundamental metric, about half of all teams don’t know their Velocity. Without it, showing improvements to management is difficult and approximating a release date is impossible. Estimate your stories, keep a record of how many points you complete each sprint, and get your Velocity.

Use Points, not Hours. Because measuring productivity in hours is so imbedded in our work culture, lots of organizations think it makes sense. It doesn’t. Humans are very bad at measuring things in time. If you are using hours, your Velocity is probably skewed.

RITUALS

The big snag seems to be the Retrospective. Retrospectives can be hard because they reveal uncomfortable truths. Team members don’t want to identify key impediments because they are worried about offending someone. As a result, the one thing that can improve your next Sprint is never identified. Be honest because continuous improvement is the point. Learn more about Retrospectives here.

ROLES

Scrum Masters: remember you own the process. Your relationship with the team involves both support and rigor. Be supportive by removing impediments but be rigorous in your fundamentals. Hold Daily Stand-Up Meetings to 15 minutes, make sure the top priority is being worked on, and that things are moving to ‘done’. Be both empathetic and disciplined and remember: put the responsibility back on the Team.

The importance of PRODUCT OWNERS can’t be overstated. They represent the needs of the customer and communicate the vision to the Team and management. Product Owners must keep management involved or they will have difficulty translating leadership’s vision into business value for the customer, and well-prioritized and defined tasks for the team.

Product Owners, remember the responsibility of the project is yours. Make sure to talk regularly to team about the relative business value of the epics and stories. Engage your team in grooming the backlog and helping you clarify stories so that they include rigorous Definitions of Done. This will increase Velocity! (So will avoiding Product Owner common pitfalls!)

SHU-HA-RI

Scrum is based on the principal of Inspect and Adapt. If you are just getting started or are having a tough time showing improvement, get back to basics (Shu). Only then start tweaking Scrum so it works for your Team (Ha). Eventually some teams may reach Hyper-Productivity (Ri). Which state are you in?

Scrum Co-founder Dr. Jeff Sutherland will address these and other issues in his upcoming Webinar: Scrum Fundamentals: Back to basics. Sign-up here.

Work Less, Get More Done!

2013-02-13T16:01:00.002-05:00

There was a really interesting Op-Ed in Sunday’s New York Times by Tony Schwartz at The Energy Project. As any good Scrum Master knows, finding a sustainable pace for the team is incredibly important to increasing velocity.

At Scrum Inc., we talk about avoiding Muri aka STRESS because when people are stressed they do poor work. (Last year, Jeff wrote a blog postabout how eliminating overtime at his Venture Capital group increased Velocityby 160%.) We recommend that Teammembers don't work more than eight-hour days and that Scrum Masters avoid death marches. This isn't just out of kindness and respect for Team; it's because people get more work done if they aren't stressed out.

Swartz sites a number of studies:

Spending more hours at work often leads to less time for sleep and insufficient sleep takes a substantial toll on performance. In a study of nearly 400 employees, published last year, researchers found that sleeping too little — defined as less than six hours each night — was one of the best predictors of on-the-job burn-out. A recent Harvard study estimated that sleep deprivation costs American companies $63.2 billion a year in lost productivity . . .

In the 1950s, the researchers William Dement and Nathaniel Kleitman discovered that we sleep in cycles of roughly 90 minutes, moving from light to deep sleep and back out again. They named this pattern the Basic-Rest Activity Cycle or BRAC. A decade later, Professor Kleitman discovered that this cycle recapitulates itself during our waking lives.

The difference is that during the day we move from a state of alertness progressively into physiological fatigue approximately every 90 minutes. Our bodies regularly tell us to take a break, but we often override these signals and instead stoke ourselves up with caffeine, sugar and our own emergency reserves — the stress hormones adrenaline, noradrenaline and cortisol.

Working in 90-minute intervals turns out to be a prescription for maximizing productivity. Professor K. Anders Ericsson and his colleagues at Florida State University have studied elite performers, including musicians, athletes, actors and chess players. In each of these fields, Dr. Ericsson found that the best performers typically practice in uninterrupted sessions that last no more than 90 minutes. They begin in the morning, take a break between sessions, and rarely work for more than four and a half hours in any given day.

Taichi Ohno, the father of the Toyota Production System, referred to stress from overwork as unreasonableness. Check out Ohno’s other stress impediments at ScrumLaband read Schwarz’s entire Op-Ed here.

- Joel Riddle

Another Waterfall Disaster: Steve Denning for Forbes

2013-01-21T11:45:00.000-05:00

Reconciling Innovation With Control: The Air Force's $1.3 Billion Lesson In Agile

Steve Denning, Forbes 11 Dec 2012

What are we to make of the news that the Air Force recently canceled a six-year-old software modernization effort that had consumed $1.3 billion and produced nothing of value? Note, that’s $1.3 billion, not $1.3 million. And it’s not that the project produced less benefit than expected. It produced absolutely no benefits at all. The whole project has been canned.

The fiasco is described in the New York Times in an article by Randall Stross which notes that the Air Force’s effort began the project in 2006. It was “supposed to manage logistics using software from Oracle [ORCL].”

The Air Force awarded the $628 million contract to the Computer SciencesCorporation [CSC] to serve as lead system integrator; its job would be to “configure, deploy and conduct training and change management activities” before the launch.

The project had been “restructured” a number of times. When the Air Force realized that it would cost still another $1 billion just to achieve one-quarter of the capabilities originally planned that wouldn’t meet even minimal requirements—and that even then the system would not be ready before 2020—it gave up on the project entirely.

For Steve Dennings analysis click here ...

Scrum and Lean: Building Cars

2013-01-21T07:44:00.000-05:00

As we prepare for the joint Joe Justice/WikiSpeed Certified Scrum training in Redmond on 4-5 February, I'm reviewing the connection between Scrum and Lean.

We continue to meet with key staff of the Lean Enterprise Institute to discuss opportunities to work together. John Shook, LEI CEO, started the first Toyota plant in the United States. He and Steve Bell gave me the best book on Lean Product and Process Development and we agree that Takeuchi and Nonaka were looking at lean product development teams when they coined the term Scrum.

So it is interesting to look at the first lean product development team started by Taiichi Ohno, the inventor of the Toyota Product System. In his book, The Machine That Changed the World, Professor Womack tells the story:

Ohno, who visited Detroit repeatedly just after the war, thought this whole system was rife with muda, the Japanese term for waste than encompasses wasted effort, materials, and time. he reasoned that none of the specialists beyond the assembly worker was actually adding any value to the car. What's more, Ohno thought that assembly workers could probably do most of the functions of the specialists and do them much better because of their direct acquaintance with conditions of the line...

Back at Toyota City, Ohno began to experiment. The first step was to group workers into teams with a team leader rather than a foreman. The teams were given a set of assembly steps, their piece of the line, and told to work together on how best to perform the necessary operations. The team leader would do assembly tasks as well as coordinate the team, and , in particular, would fill in for any absent worker--concepts unheard of in mass -production plants.

Ohn next gave the team the job of housekeeping, minor tool repair, and quality-checking. Finally, as the last step, after the teams were running smoothly, he set time aside periodically for the team to suggest ways collectively to improve the process... This continuous, incremental improvement process, kaizen in Japanese, took place in collaboration with the industrial engineers, who still existed but in much smaller numbers.

Similar Scrum teams are used by Joe Justice for weekly builds of cars. It is clear that we have not only taken Scrum from the Japanese, but by testing it in thousands of software teams have added incremental value with the concept of weekly sprints, pair programming, test driven development, and other practices that allow production of new car prototypes faster than Toyota with globally distributed volunteer teams. In a couple of weeks we will watch the weekly car assembly at WikiSpeed in Redmond.

WIKISPEED, Scrum Inc, and Solutions IQ Team Up

2013-01-19T10:30:00.002-05:00

Here at Scrum Inc. we are really excited about this new class we're doing with Joe Justice on taking Scrum beyond just software.

Dear Agilistas,

Are you enjoying what Scrum Project Management is doing for your software delivery teams? How about sharing some of that awesome with your sales, marketing, and Public Relations staff! Your HR group! Your legal and finance teams! Especially hardware development and manufacturing managers!

Learn all about how the entire company can achieve 5-10x velocities with Jeff Sutherland, the co-creator of Scrum, and Joe Justice, the founder of Team WIKISPEED . February 4th, 5th, and 6th in Redmond, WA! http://bit.ly/WbA5lA

Perfect for portfolio managers, managers, and members of the high performing team we will launch with you February 6th! Jeff and Joe work with manufacturing, food service, merger and acquisition groups, legal teams, design groups, software delivery and testing groups, health care and government groups.

Jeff Sutherland is the co-creator of Scrum, the project management methods that now dominate fast-moving software companies. Joe Justice's Team WIKISPEED used Scrum to develop a 100 mpg car in just 3 months and now delivers social good initiatives world-wide.

Learn all about how it works on February 4th and 5th, then Launch your new high performing team with us February 6th!

Warmly,

Joe Justice and Jeff Sutherland
Scrum Inc and SolutionsIQ

THE WIKISPEED SGT01 is built by a distributed team of engineers, researchers, enthusiasts, and passionate supporters. We aim to deliver a mass-production, ultra-efficient, Comfortable Commuter Car, the C3. To finance the development of that car, we are looking for ten lucky homes for clones of our X Prize race car. These ultra-efficient, safe, durable cars are delivered with our Roadster aeroshell body module for stunning looks along with stunning fuel efficiency. These cars are not for everyone. They are road legal, but comfort and convenience stop there. Developed for the ultimate in speed and efficiency, they skip every amenity except an iPhone dock in the dash panel. They do not have a lockable trunk, roof, or cup holders. Step over the side crush structures and fixed door panels then sit down inside like a pure race car for the ultimate in light-weight and simplicity. Help us organically finance our ultra-efficient mass-production vehicles by bringing home one of our ten prototypes, and make the world a better place for everyone who follows.

Richard Hackman and Scrum

2013-01-13T10:30:00.000-05:00

A guest post from Jens Meydam (@jmeydam) on the death of Richard Hackman.

A few days ago, on January 8, a man passed away who may be considered one of the patron saints of Scrum, even though he had never heard of Scrum and few in the Scrum community know his name.

Richard Hackman

Richard Hackman was quite simply the most eminent and influential scholar of teamwork. Where others were content to publish plausible-sounding ideas and anecdotes, Hackman, whose first degree was in mathematics, conducted rigorous research for what seems like decades before writing his masterpiece, Leading Teams.

As one of his former students remembers:

"He took his task very seriously and he showed us all how important it was to be both rigorous and practical in the pursuit of knowledge that could affect how well groups perform and how they can uplift people's lives."

I first came across his name in a tweet by Bas Vodde, who seemed enthusiastic about Hackman's work. Since then I have read Leading Teams twice, as well as two sequels, one on senior management teams and one on intelligence teams (Hackman was advisor to the CIA). There is so much to learn from his work.

After the jump, I will just quote a few passages from Leading Teams. I encourage you to read the book; a few quotes are in no way a substitute. If you are familiar with Scrum you may agree that the parallels between how Hackman describes the role of team leaders and how we see the Scrum Master and the Product Owner role are striking. Hackman can also help us understand some of the deeper benefits of working in sprints. I have described this book to others as "Scrum, the Missing Manual". While Scrum is not the only way to create the enabling conditions Hackman writes about, it is certainly one way. I regret that I didn't try to get in touch with him. Now, sadly, it is too late.

Leading Teams - Setting the Stage For Great Performances (Hackman 2002)

Conditions For Team Effectiveness

To view team leadership as creating conditions that increase the chances that a team will evolve into an effective performing unit is somewhat unconventional. Both practicing managers and writers about management commonly view the actions of leaders as "causes" and the responses of teams as "effects." (31)

A Real Team
Compelling Direction
Enabling Structure
Supportive Context
Expert Coaching

The five conditions [...] are easy to remember. The challenge comes in developing an understanding of those conditions that is deep and nuanced enough to be useful in guiding action, and in devising strategies for creating them even in demanding or team-unfriendly organizational circumstances. People who are natural team leaders seem to know intuitively how to do these things. (ix)

Compelling Direction

Great direction fully engages team members' talents. It is not just that members work harder when what they are doing is important. It is more than that - it is that they pursue collective purposes using every scrap of knowledge, skill, and experience that the team can scoop up. (71)

To harvest the benefits of compelling direction, a team's purposes actually have to be challenging, clear, and consequential. Words alone do not suffice, not even if they are inspiring words personally delivered to the team by a charismatic leader. (72)

Enabling Structure

The evidence suggests that it is quite unlikely that members will establish norms that support active environmental scanning and strategy planning, or that they will explicitly set and enforce specific "must always do" and "must never do" constraints on team's task behaviors. Instead, the norms that members import or evolve are much more likely to focus on keeping interpersonal relations within the team and with clients smooth and conflict free, on keeping members' anxieties low, and on making sure that all inputs received are converted into outputs in a timely fashion with a minimum of fuss. [...] The two core norms are unnatural, and the behaviors they support often raise rather than lower anxieties within a work team. (112)

Is there an optimum team size [...]? A study conducted by Neil Vidmar and myself is at least suggestive of an answer. [...] the optimum group size was 4.6 members. That conclusion, of course, was just an exercise done on data from a not-very-important study, but it does remind us that most of the time, smaller really is better. (118)

Expert Coaching

[...] Gersick found that each of the groups she tracked developed a distinctive approach toward its task as soon as it commenced work, and stayed with that approach until almost exactly halfway between its first meeting and its project deadline. At the midpoint of their lives, all teams underwent a major transition. In a concentrated burst of changes, they dropped old patterns of behavior, reengaged with outside supervisors, and adopted new perspectives on their work. Following the midpoint transition, groups entered a period of focused task execution, which persisted until very near the project deadline, at which time a new set of issues having to do with termination processes arose and captured members' attention. (177-179)

People do not learn well when they are preoccupied, anxious, or hurried. [...] Team learning requires, at minimum, some protected time and at least a moderate level of collective safety, conditions that are hard to create when members are right in the middle of task execution. Because anxieties and arousal dissipate somewhat once a piece of work is finished, post performance periods offer an especially good time for coaching interventions aimed at helping members capture and internalize the lessons that can be learned from their work experiences. Even then, however, team members may be disinclined to exploit the learning opportunities that are available to them. (184)

Requirements for Product Owner: Common Pitfalls

2013-01-08T13:48:00.000-05:00

Recently during a leadership workshop an engineering manager complained that his Scrum teams deliver the product and that it was not what the customer wanted. He thought this was a problem with Scrum.

I pointed out that the Product Owner determines what is DONE at the end of a sprint and if it is not what the customer wants, the Product Owner should declare it NOT DONE. I suggested he might have a Product Owner problem. Scrum doesn't magically make your problems go away, it makes them clear and you know immediately where to look for responsibility.

The engineering manager confessed that they had underinvested in the Product Owner function. The Product Owners are not fully dedicated and are not doing the job. It only took about 5 seconds to diagnose the problems with his Scrum.

The majority of Scrum teams worldwide (and I survey multiple times every month in multiple countries) do not have good Product Backlog Items entering the sprint. In addition to cutting velocity at least in half (a minimum loss of about $75K per month per team), it leads to the customer not getting what they want. At OpenView Venture Partners we think we can hire a new manager and a new Product Owner for $75K a month, but I digress ...

An adequate Product Owner needs to meet these minimal requirements:

1. Knowledgeability
2. Availability
3. Decidability
4. Accountability

Knowledgeability

If the Product Owner does not know the market, the customer, the product, and the competition, the team will lose confidence in their leadership. This will lead to slow down and disagreement over priorities. It is not possible for a new Product Owner to know everything. They need help from management and the team to ramp up their capability. This needs to be built into their job description.

Availability

The best Chief Product Owner is often a business leader (like Steve Jobs). The Product Owner spends half the time working with the customer and the market and the other half working closely with the team. If the business leader has to be part-time, she or he needs a full-time Product Owner to do the day-to-day work. Failing to do this will lead to problems like the one described above. The customer will not like the result, and more work will need to be done. It is cheaper to hire a Product Owner than deal with the damage later.

Decidability

The Product Owner owns the final decision on the ordering of the Product Backlog. Failure to do this will cause priority conflicts and cut team velocity in half. It is cheaper to hire a new Product Owner than to let this happen.

This means the Product Owner needs the confidence of the stakeholders (and the team). If they don't have it, they can't do the job.

Accountability

The Product Owner owns the business plan and is accountable for driving revenue (or whatever value your organization is producing). It is not helpful for a hyperproductive team to deliver many features if the revenue per point is minimal. The Product Owner should be measured on revenue per point and how much the revenue per point is increasing over time.

The Scrum Inc. Product Owner regularly monitors metrics like revenue per point to better order the Product Backlog.

Very few Product Owners know their revenue per point. For this reason, at Scrum Inc. we have developed a management dashboard that shows sprint to sprint revenue per point. Just as the Scrum Master needs to know velocity sprint to sprint, the Product Owner needs to know revenue sprint to sprint. We will hold a webinar on this topic in February with a demo of our management dashboard.

Meanwhile, I strongly encourage all organizations with Product Owner issues to send their key people to our Certified Product Owner workshops in Boston at our venture group headquarters. At a minimum you might save $75K per team per month. The upside revenue would likely be much more than that.

This page has been translated to Serbo-Croatian by Anja Skrba

Scrum Goes Mainstream in France

2012-12-31T11:50:00.000-05:00

As Scrum enters the mainstream, Xebia France has become one of the leading Scrum coaching companies for French developers. What they have noticed is that as Scrum expands, the basic ideas become watered down. For example, their Scrum Master Academy Rule #2, is the the Agile Manifesto is not a developers Bill of Rights.

In fact, the Agile Manifesto is not about the rights of a developer, it is about professionalism. This means (1) increasing your ability to help the team to a higher level of performance, (2) getting bug free software by the end of every sprint, (3) involving the customer, or the Product Owner as the representative of the customer, in all key decisions about development that will affect the end user, and (4) embracing change as fast as the customer can change his or her mind.

The inability of new agile developers to understand the basics has created significant problems. For example, over half of "agile" teams do not have working software at the end of the sprint. Somehow, they are not reading or understanding the Agile Manifesto.

As Mike Cron, All Blacks Scrum coach, says, "In the old days we used to just smash into something, maybe without quite knowing what we were doing. Here we are trying to get good technique and understand everything we are doing." Scrum is just like golf, we have to learn how to swing. And it's not so much about the rules of the game, it is how you play the game.

There are many pitfalls of Scrum to the new developer, and Scrum Master Academy has developed some basic techniques to avoid most of these pitfalls. If you want to be on a winning team in France, take a look at the Scrum Master Academy.

Continuous Improvement for a Perfect 10

2012-12-20T13:34:00.001-05:00

By Arline Sutherland

I remember sitting on the basement steps in the summer of 1976 watching Nadia Comaneci win the worlds first perfect 10 in the history of modern gymnastics. Her command of the whirling routine on the uneven bars was a marvel.

The announcers told us that she had scored a 10, but the scoreboards read 1.00! Turns out that Omega, the traditional Olympics scoreboard manufacturer, asked beforehand if the boards for gymnastics would need four digits., they were told that a perfect 10 was impossible.

As I watched that fourteen-year-old girl push the limits of how strong and graceful a human body can be, I thought, “I wonder how many times she has fallen as she tried something new? And how many times she got back up eager to try again.

The idea behind continuous improvement is that things aren’t as good as they could be, yet. Things can always be tweaked. Any process can be improved, if, one is willing to shine a light on every little thing, the good and the not so great. Laughter helps too.? And how many times her coach suggested that she do it just a little bit differently? And I wonder how they exulted when the new routine finally worked? They work together so she can win 10s!”

Take a page from the evolutionary process and make small changes rather than giant leaps. Evaluate. Did it move us in the right direction? What might? Make another change. Get feedback from stakeholders and customers. Inspect. Adapt.

In Scrum, it’s the Team, the people who are doing the work, who take responsibility for continually improving. It’s their process and they are the ones who know it best. What is working really well? Did that last tweak do the trick? What could be done better? And in Scrum, it's the Retrospective that provides the structure for ensuring this conversation takes place.

I suspect that after each 10, Nadia and her coach assessed every move she made, the hand twist that so delighted the crowd, how to stick that landing even more surely by lifting her head. And then, she did it again.

Want to take your team to the next level? Check out our new guide, 3 Steps for an Effective Retrospective.

Waterfall to Agile

2012-12-09T05:56:00.000-05:00

Ade Shokoya of agile.tv has written a good book on Waterfall to Agile. The added value starts in the preface:

As you know, the global economy is very volatile at the moment, and things aren't looking like they will get better any time soon. Across Europe and America unemployment is at an all-time high, and the predictions are that more people will lose their jobs over the coming years. However, as more and more organizations transition from Waterfall to Agile, those individuals with the knowledge and experience that will enable organizations to maximize the benefits they get from Agile practices (e.g. reduced development costs, quicker returns on investment, improved quality, and a greater competitive advantage) are the ones who will benefit from greater job security (at a time when people are struggling to hold onlto their jobs), get promoted quicker (at a time when people are being made redundant), and get paid more (at a time when wages are going down and people are struggling financially).

There are 451,176 Scrum job openings in the United States this morning and these new jobs are increasing at a rate of about 10,000 per month. After reading Waterfall to Agile, you might take a look at the Power of Scrum, attend a Certified Scrum Master training, and start interviewing for an agile position. Many people have told me it has changed their lives dramatically for the better.

Update: Excel Spreadsheet for Hyperproductive Scrum Teams

2012-12-07T12:03:00.001-05:00

In the years since the first paper on metrics for hyperproductive teams, I have been thinking about new ways to measure high-performing teams. Tune in to the webinar "Hyperproductive Metrics" for the latest metrics to guide teams on the path to hyperproductivity.

SCRUM METRICS FOR HYPERPRODUCTIVE TEAMS: HOW THEY FLY LIKE FIGHTER AIRCRAFT

Jeff Sutherland and Scott Downey

Agile 2010 Experience Report

Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in two ways. They have engines that produce velocity—alignment of the team, and team spirit. And they carefully measures aspects of performance to make slight adjustments in flight. Failing to constantly adjust the flight of the team can result in a hyperproductive crash into waterfall performance.

One hour discussion of a comprehensive, yet minimal set of team metrics used in an environment where hyperproductive teams are the norm, along with an Excel spreadsheet that can be used by any Scrum team to improve performance. Velocity, story completion by priority, work in progress, story acceptance rate by product owner, unplanned work, and trending accuracy of estimates all appear to be essential to determine the altitude, velocity, angle of attack, and attitude of a hyperproductive team. Slight adjustment of these parameters on a daily basis keeps the team on target. Half hour questions and discussion on using the Excel spreadsheet to improve team performance.

Download Scott Downey's Excel Spreadsheet for your Scrum team.

Tipping Point: Get Agile or Get Outsourced

2012-12-02T08:23:00.001-05:00

In the past six months, Scrum jobs on simplyhired.com have increased from 20,000 to 420,000. Despite this tsunami of Scrum job offerings, many of the traditional project leaders and senior IT staff I talk with are still resisting the inevitable and they fail to see the handwriting on the wall.

It is now U.S. law that all DOD contracts are Agile. Maybe you will go to jail in the future for not being agile if you do work for the government.

The Gartner 2012 advisory on application development to all IT senior management is:

Business users are losing patience with old-school IT culture. Relationships are tense and resentful. Legacy systems and practices impede agility. Bottom line - GET AGILE
Adopt a product perspective.
Say goodbye to waterfall.
Improve cross-competency collaboration.
Launch a deep usability discipline.
Start a technical debt management program.

The business user agile revolt is causing traditional IT budgets to be cut by 90% over the next decade as business users take control of the money.

The latest Gartner advisory shows what is likely to happen:

In two years, Gartner Inc. Research Vice President Brian Prentice predicts, the percentage of technology spending by the business -- outside of the control of IT -- will reach 35 percent.

Moreover, by the end of this decade Gartner is predicting businesses will control a whopping 90 percent of technology spend...

Consumerization and Cloud

The shift of technology spending from IT to the business units is driven by a number of factors, but according to Gartner, is mostly driven by:

Consumerization – expectations by users and the business for their systems and applications to look and perform like consumer offerings versus the perceived limited solutions being offered by core IT.
BYOD - users purchasing their own work tablets, laptops and other devices.
Cloud Computing – where the business procure their own infrastructure, platforms and software as a service.

The role of IT is clearly evolving, where for technology system purchases like marketing automation, CRM, HR and even supply chain management, IT departments are brought in to support the integration of these systems into the enterprise systems, but IT is not leading the purchase project.

An indepth analysis of why management needs to move quickly to Agile is available in the new book Ken Schwaber and I have published recently - Software in 30 Days.