Scrum is based on complex adaptive systems and emergent behavior

In the early days of Scrum we were steeped in complex adaptive systems theory and autonomous intelligent systems. This area of research is emerging in a new form called Ambient Intelligence (AmI) due to the proliferation of intelligent devices on the internet. This proliferation and the applications we use with them caused Wired Magazine to declare "The Web is dead" in September 2010.

Work in this area can help us understand Scrum better and ensure that basic collaboration mechanisms are in place to make Scrum work. The environment must be set up so that people have an incentive to help one another in order to optimize the whole, rather than optimizing their individual niche at the expense of the larger community. Failure to do this will prevent individuals and companies achieving the full benefits of Scrum.

ACM Transactions on Autonomous Adaptive Systems has many articles worth reading to understand the issues in more depth. In particular, the article below reviews much of the literature upon which Scrum is based and proposes a better approach to achieve cooperation among networked systems.

Cooperation through Self-Similar Social Networks
STUART M. ALLEN, GUALTIERO COLOMBO, and ROGER M. WHITAKER
Cardiff University
DOI = 10.1145/1671948.1671952 http://doi.acm.org/10.1145/1671948.1671952

We address the problem of cooperation in decentralized systems, specifically looking at interactions between independent pairs of peers where mutual exchange of resources (e.g., updating or sharing content) is required. In the absence of any enforcement mechanism or protocol, there is no incentive for one party to directly reciprocate during a transaction with another. Consequently, for such decentralized systems to function, protocols for self-organization need to explicitly promote cooperation in a manner where adherence to the protocol is incentivized.

In this article we introduce a new generic model to achieve this. The model is based on peers repeatedly interacting to build up and maintain a dynamic social network of others that they can trust based on similarity of cooperation. This mechanism effectively incentivizes unselfish behavior, where peers with higher levels of cooperation gain higher payoff.We examine the model’s behavior and robustness in detail. This includes the effect of peers self-adapting their cooperation level in response to maximizing their payoff, representing a Nash-equilibrium of the system. The study shows that the formation of a social network based on reflexive cooperation levels can be a highly effective and robust incentive mechanism for autonomous decentralized systems.

Categories and Subject Descriptors: I.2.11 [Artificial Intelligence]: Distributed Artificial Intelligence— Multiagent systems; C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Distributed networks

General Terms: Algorithms
Additional Key Words and Phrases: Cooperation, decentralized systems, self-organization
ACM Reference Format: Allen, S. M., Colombo, G., and Whitaker, R. M. 2010. Cooperation through self-similar social networks. ACM Trans. Autonom. Adapt. Syst. 5, 1, Article 4 (February 2010), 29 pages.

Nokia Test: Latest Version

The "Nokia Test" for Scrum teams was developed orginally by Bas Vodde at Nokia Siemens Networks in Finland. It has been updated several times and appears in it latest incarnation in Jeff Sutherland's Scrum Certification classes where he demonstrates that attending the class yields an average return on investment of 1033% for participants.

Links to all previous versions of the Nokia Test, the current scoring of the ScrumButt test, and the 1033% ROI calculations can be found in the attached presentation, "The ScrumButt Test: aka The Nokia Test."

Mike Beedle on the Early History of Scrum

I have been doing Scrum and Org Patterns since the fall of 1995 when I saved a large multi-million dollar project from failure at William Mercer in Deerfield, IL.  Completion of this project not only put the system in production, but avoided the company to pay a multi-million dollar penalty.   Eighty consultants; hundreds of employees; thousands of pages of documentation that included processes, procedures, requirements, design, testing; and hundreds of failed project plans, could not deliver what Scrum and Org Patterns delivered in 4 months with 10 people.  It was amazing.  It was magical.

The ideas of Scrum were first introduced to me by Jeff Sutherland, in his many articles to the OTUG community, and his personal correspondences with me.  His main idea about Scrum was to create a team that would resemble artificial life, a robot, or an adaptive system, that would adapt and learn through “social intelligence”.   I was intrigued because I have a Ph. D. in Physics, and my master’s thesis was about chaotic and non-linear systems.  Our first conversations were about creating a team at the edge of chaos, etc.  A few weeks after that, he introduced me to Ken Schwaber, and Ken pointed to me to his OOPSLA paper on Scrum and to his Scrum pages at his Advanced Development Methods web site.  Around the same time, I became familiar with the ideas of Org Patterns, via the work of Jim Coplien, Neil Harrison, and Brendan Cain:  1) Borland Software Craftsmanship: A New Look at Process, Quality and Productivity, 2) A Generative Development-Process Pattern Language, and the many articles written to the org-patterns and patterns-discussion lists since 1995. 

Both directions pointed to the same end game:  creating a hyper-productive team that worked as an adaptive system at the edge of chaos through patterns.   I was just very lucky to try both simultaneously in an emergency situation.  I was pre-conditioned to accept these ideas, because at the time I was a practitioner of BPR (business process reengineering), the Michael Hammer style, that basically called for that kind of hyper-productive environment, without really telling you how to get there, and by my academic training as mentioned before.

My life has never been the same since that project at Mercer.   Scrum and Org Patterns have truly changed my life for the better.   Since 1996, I have exclusively used Scrum and Org Patterns to deliver software to a vast and diverse range of industries: Financials, Healthcare, Government, Manufacturing, Technology, Services, Transportation, etc.), ranging from single teams, all the way to dozens of inter-dependent teams with a common base architecture.  I have developed software using Scrum and Org Patterns for my companies or for my clients in record speeds, under budget, with record customer satisfaction, and with great pleasure for the developers involved – that’s what our largest client, the US Department of Defense, for example, says about our software.  My companies have introduced Scrum to thousands of people and hundreds of companies, providing products, development, training, consulting, mentoring, and coaching:

From 1996 - 1999, I co-owned Framework Technologies Inc., where we brought the power of Scrum and Design Patterns to our clients:  Nike Securities, Bank of America, Lincoln Reinsurance, Motorola, etc.

From 1999 - 2003, I owned e-Architects Inc., where we bring the power of Scrum, Design Patterns and Architecture principles to our clients:  All-State, Caremark, State of Illinois, Orbit, Northwest Bank, Persistence Software, etc.

From 2000 – today, I co-own New Governance Inc., where we delivered our compliance management software products, to nearly 4000 sites:  Citigroup, The Hartford, CIGNA, DOD, BCBS, etc.

From 2008 – today, I own Quant Traders Inc., where we deliver sophisticated quant trading products and services to our clients.

From 2010 – today, I own Enterprise Scrum Inc. that exclusively teaches, mentors, coaches and implements Scrum in enterprise environments.

I am the co-author of the first Scrum book, Agile Software Development with Scrum, the co-author of the first Scrum paper published in a book, SCRUM: An extension pattern language for hyperproductive software development, a co-author of the Agile Manifesto:  http://www.agilemanifesto.org, and the co-author of the upcoming Scrum Pattern Language book which will give direction to the future of Scrum...

Michael A. Beedle Ph. D.

CEO

Enterprise Scrum Inc.

Haegwan Kim interviews Jeff Sutherland

 Law of Success 2.0

To Make The World A Better Place Where All Human Beings Can Achieve Success

For first part of the interview click here ...


Conclusion:
HK: Time moves on, so I want to have few questions about success. What is the definition of your success as an engineer?

JS: Well my definition of success has to do with making the world a better place. If I can make a contribution so that people are happier, better motivated, more successful then I’m successful. Scrum’s goal was based on work I have done with micro-enterprise lending. Professor Yunus in Bangladesh came up with a program where he’d give really poor people a little bit of money and they’d create their own business plans and then execute them. They eventually could boot strap themselves. Scrum was designed to do the same thing. Let’s give the team a little bit of capability and then let them figure out how to go really fast. So Scrum was designed to take development teams who were always late and under pressure and turn them into teams who were having a lot of fun, a lot of energy, building great products. And so the goal was actually to release the teams from their chains. They were under pressure from management; they were getting beat up all the time by management. I said to them, “You could live a better life. You could have a life where you’re innovating, where you’re having fun, where it’s a joy to come into work.” You can do it in a way that you can build so much software, you’d have five to ten times more software so you could do a lot more with a lot less work. It’s a much better life, and it empowers the people to take the initiative. That thrust is relevant to work, it’s relevant to politics, it’s relevant to the health and wellbeing of the people. That’s success. It’s to help people be great, that’s my goal. And Scrum is doing that for people. It’s amazing what’s happened. It’s a huge surprise to me. It works in every culture, it works in every country, and it works in every company. It’s just an amazing thing. And people have taken it and they’ve taken it there themselves. So it’s not me, it’s them doing it. So my success is that I’ve helped facilitate making that possible.

HK: Just mind-blowing. So your success is not about money.

JS: Here’s the secret and the core of real success. It comes from the heart, it comes from giving, it comes from expansively helping others. If you do that well you will have plenty of money. I don’t have any problems with money. I don’t have more money than Bill Gates, but I have enough money. Scrum has given me that. People all over the world want me to come and talk about Scrum everywhere all the time. Every time I need some money I just go someplace. People always want to hear about it.

HK: Can you give me your advice to be successful in general?

JS: Things today are built by teams. Obviously individuals are still a direct source of inspiration and innovation. But individuals can’t even execute really good ideas without building a really good team around them. So people need to learn to work with teams, that’s what Scrum is all about. They need to figure out how they can actually help people. We learned that in Silicon Valley. I spent some years working there and that’s affected Scrum as well. How do those companies in Silicon Valley get started? It’s always by a small team. It’s always with a great idea. It’s a world-changing idea. They are having fun at Google, and they have more money than they know what to do with. But it wasn’t for going after the money; it was actually a world changing idea and creating an environment where people could have a lot of fun executing it.

HK: Thank you so much for your time.

Estimation Accuracy: Extraneous information and anchoring effects

The Simula Lab in Norway has supported research on estimation error. Stein Grimstad's Ph.D. thesis on this topic has spawned several papers and references are provided below from the IEEE Digital Library in response to requests for sources.

In particular, irrelevant information in a specification will lead to larger estimates and telegraphing an expected size of an estimate will skew results (anchoring effect).


Avoiding Irrelevant and Misleading Information When Estimating Development Effort
Found in: IEEE Software
By Magne Jorgensen , Stein Grimstad
Issue Date:May 2008
pp. 78-83
Software development effort estimates are reported to be highly inaccurate and systematically overly optimistic. Empirical evidence suggests that this problem is caused to some extent by the influence of irrelevant and misleading information—for exam...

The Impact of Irrelevant Information on Estimates of Software Development Effort
Found in: 2007 Australian Software Engineering Conference (ASWEC'07)
By Stein Grimstad , Magne Jorgensen
Issue Date:April 2007
pp. 359-368
Combination of expert opinion is frequently used to

A framework for the analysis of software cost estimation accuracy
Found in: Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering (ISESE '06)
By Magne Jørgensen,Stein Grimstad
Issue Date:September 2006
pp. 58-65
Many software companies track and analyze project performance by measuring cost estimation accuracy. A high estimation error is frequently interpreted as poor estimation skills. This is not necessarily a correct interpretation.

The Clients' Impact on Effort Estimation Accuracy in Software Development Projects
Found in: 11th IEEE International Software Metrics Symposium (METRICS'05)
By Stein Grimstad , Magne Jorgensen , Kjetil Molokken-Ostvold
Issue Date:September 2005
pp. 3
This paper focuses on the clients' impact on estimation accuracy in software development projects. Client related factors contributing to effort overruns as well as factors preventing overruns are investigated. Based on a literature review and a survey of ...

Understanding of Estimation Accuracy in Software Development Projects
Found in: 11th IEEE International Software Metrics Symposium (METRICS'05)
By Stein Grimstad
Issue Date:September 2005
pp. 42

Agile 2008 - Money For Nothing

Scrum was designed for hyperproductive teams. If you can run at 5-10x your competitors velocity and quality you should generate 5-10x more revenue. Why do so few great Agile teams do this? Their business model sucks!

You gotta watch them how they do it on MTV. Otherwise you will be pushing refrigerators for the rest of your life. Money for Nothing and Your Change for Free was the theme of my presentation at Agile 2008. The right method of Agile contracting can double, triple, or quadruple your margins. Get rid of hourly billing. It just keeps you on the treadmill!

Gerry Kirk has a good writeup of my Agile 2008 presentation on his blog.

Money For Nothing: Deliver More Value For Your Client (And You)
Written by gerrykirk on August 19, 2008 – 3:19 pm

These are notes from Jeff Sutherland’s Agile 2008 presentation “Money For Nothing and Your Change For Free: Agile Contracts“. Jeff summarized his talk in this way:

“The “Money for Nothing” strategy works when customers want fixed price estimates for the entire contract up front. The Agile contract allows termination of the contract early when the value of features drops below an ROI criteria. The contract allows the customer to save 80% of their remaining funds by giving the Agile vendor 20% of the remaining contract value in return driving the margins of an Agile contractor from 15-20% up to 50-80%.”

From Scrum Butt to High Performing Team

Jeff began his presentation by talking about the Nokia Test For Scrum Certification, which Nokia uses to measure their team’s level of agility (see questions and scoring method in slide show below). Jeff had everyone in the room score their own team. I rated ifPeople in general at a 5 out of 10, which is just above the starting average. Anything 8 and under is in the ScrumButt category.

Why is this important? Teams that score high tend to be the high performing teams. They also generate much higher revenues, based on Jeff’s analysis:

* Great Scrum: 400% revenue increase
* Good Scrum: 300%
* Pretty good Scrum: 150% - 200%
* ScrumButt: 0 - 35%

Jeff also compared agile to waterfall teams, suggesting high performing agile teams can outperform waterfall teams by a 5-6x margin. The problem is, contracts that are time and materials don’t reward high performance. T&M is low risk and low margin, you only get paid for the hours you put in, even when you take far less time than your competitors. Fixed price contracts aren’t any better, with vendors trying to out-discount each other. Many vendors only making money if the project is late and over budget due to change requests and building functionality that users do not want.

HICSS 2011 Agile Papers - Need Reviewers!

We need good reviewer for a series of Agile papers submitted to the HICSS Conference. Reviews are due by 14 August. If you are interested, send email to jeff@scruminc.com and let me know which papers you would like to review. You must set up an account for yourself at the HICSS submission site before emailing me: https://precisionconference.com/~hicss/ 

Agile Development at ABC – What Went Wrong?

Abstract: Agile development methods continue to enjoy widespread use, with more and more companies transitioning to agile methods. Current literature suggests that most of those companies are successful in making the transition, but others are not so successful. This paper examines one such company – referred to within as the ‘ABC Company’ to maintain their privacy – and analyzes and discusses their struggles with implementing agile methods. In short, it appears that lack of firm leadership commitment to agile, absence of a clearly defined customer to provide clearly defined requirements or push for additional software capabilities, failure to provide adequate initial or ongoing training and support to the organization as a whole, and underestimating the change management requirements were contributing factors to ABC’s struggles with implementing agile methods. These conclusions were reached based on a series of interviews with company employees, review of the relevant literature, and comparisons with other similar case studies.

Management guidelines for Scrum agile software development process

Abstract: This paper explores critical issues and challenges that might arise in Scrum agile software development processes and provides management guidelines to help organizations avoid and overcome barriers in adopting the Scrum method as a future software development method. A qualitative research method design was used to capture the knowledge of practitioners and scrutinize the Scrum software development process in its natural settings. An in-depth case study was conducted in two organizations where the Scrum method was fully integrated in every aspect of two organizations’ software development processes. One organization provides large-scale and mission-critical applications and the other provides small- and medium-scale applications. Differences between two organizations provided useful contrasts for the data analysis.

Integrating Software Quality with Earned Value Management in Projects, Programs and Portfolio Management using AgileEVM Techniques

Abstract: Agile practices integrate software quality attributes into the development process. Earned Value Management (EVM) includes cost management while Agile processes do not. Integrating Agile and EVM provides a more comprehensive management capability for software development. Operating in an environment without integrating software quality puts entire portfolios and programs at high risk. Schedule slips from quality problems, such as late integration often become known when it is too late to react and resolve without significant impact.

AgileEVM is a robust integration of Agile and traditional earned value that integrates quality with cost, scope and schedule management. Because each item in a Scrum product backlog is sorted according to highest value, claiming done with established quality levels enables AgileEVM to truly measure outputs of value.

AgileEVM supports all 32 EVMS guidelines directly or relies on external systems like financial accounting. AgileEVM scales and can integrate multiple control accounts, including the portfolio level.

An Educational Testbed for the Computational Analysis of Collaboration in Early Stages of Software Development Processes

Abstract: Agile software development processes are widely adopted in software engineering projects. Their low organizational overhead and iterative nature make them ideal choices for small development teams. The application of those methods in software projects that require collaboration between multiple sub-teams, however, is a challenging task. Especially the initial phases of such projects are crucial for project success and a problem-free inception period generates a basis for efficient development later in the process.

We introduce a testbed that allows analyzing the collaboration processes during those early stages of software development within a low-risk, educational environment. Participants of a software engineering lecture form development teams of considerable size and develop real-life applications within a realistic, yet controlled, environment. By combining manual observations with the computational analysis of digital collaboration artifacts we are able to gain insights into distinctive patterns of collaboration activity and reason about their triggers within the process setup.

Supporting Scaling Agile with Portfolio Management: Case Paf.com

Abstract: This paper is a descriptive case study of how one company, Paf.com, introduced portfolio management to help support scaling agile software development. Paf.com had experienced problems with long time-to-market due to thrashing, which was caused by frequently changing priorities due to an ad-hoc prioritization process. Also, there was lack of visibility into projects entering and progressing in the development pipeline. No structured way of starting projects was enforced company-wide, and too many parallel projects got started. As a result of introducing a structured portfolio management process, the number of ongoing projects has dramatically reduced, from over 200 to 30. Listing all projects in priority order in the Paf.com backlog provides visibility into what is currently ongoing. The portfolio follow-up function provides progress data on the projects in the Paf.com backlog, which helps managers make more informed decisions, considering the whole portfolio.

Embracing or Constraining Change: An Exploration of Methodologies for Maintaining Software

Abstract: This study uses a grounded theory research method to explore how IT professionals define and select a methodology to maintain existing software. The findings contribute to a better understanding of how standard methodologies are applied in software practice and the critical factors used by professionals when choosing an appropriate methodology for software maintenance activities. This research underscores the need for incorporating the full software life cycle in information systems development research as well as highlighting the need for more comprehensive education in software methodologies.

Improving Trust in Information Systems Development Using Agile and Formal Practice

Abstract: This paper posits that Implementing a balanced portfolio of Agile and formal project practices will strongly support the cognitive trust-building processes necessary to promote good development and O&M decision making for information systems, programs, and projects. The mechanisms enhance decision making by moderating the potentially negative effects of executive, managerial, development team, and end user distrust. Research has shown that establishing and maintaining an environment of trust can be improved by using effective trust supporting and trust building practices in appropriate situations.

This paper argues for employing a set of trust building practices and processes from both formal and Agile methodologies that varies depending upon three factors: the need to develop a new or full replacement system, the experience of the user/purchasing organization with the development team, and the O&M status/working capabilities of the solution in use by the target organization.

Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft

Abstract: 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 Scrum burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in multiple ways. They have two engines that produce velocity--alignment of the team and team spirit. A hyperproductive team uses careful measurement of aspects of performance and prioritization to make slight adjustments in flight. Just as modern jet fighters are inherently unstable without computers to fine tune flight parameters, hyperproductive teams require daily adjustment based on key metrics. Careful attention to the metrics described--velocity, work capacity, focus factor, percentage of found work, percentage of adopted work, original commitment, final commitment, commitment accuracy, estimate accuracy, and target value contribution increase can develop and sustain hyperproductive teams.

Measuring the Impact of Scrum on Product Development at Adobe Systems

Abstract: Over the past several years scrum has grown to become the most commonly used product development method at Adobe Systems. Large desktop software products like Premiere Pro and After Effects, Platform tools like Adobe AIR, and Software as a Service products like Omniture SiteCatalyst are using scrum to become more effective at delivering the right solutions to customers with higher quality. This paper discusses the methods used to measure the impact scrum has had on these teams.

Towards the Understanding of Effective Agile Practices in Distributed Software Development: An Empirical Study

Abstract: Although the application of agile approaches in distributed development is expected to be beneficial, the mechanics of combining agile approaches with distributed development is not well understood. There has been little research to identify which agile practices are identified as effective in different distributed software development environments. This paper investigates effective agile development and management practices for distributed software development project success. We report on our initial efforts to identify to what extent these agile practices are related to project success in co-located, not colocated or in offshore/ outsourcing software development. Our analysis into effective agile practices agrees with existing experience reports although some agile practices surprisingly did not appear to be as effective as expected. We conclude with future research directions.

-----------------

HICSS-44 PAPERS FOR REVIEW - reviews due 14 Aug 2010

January 4-7, 2011

The Grand Hyatt Kauai Resort and Spa

Kaloa, Kauai, Hawaii

HICSS-44 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Track: Software Technology

Minitrack: Agile Software Development: Lean, Distributed, and Scalable

Co-Chairs: Jeff Sutherland and Gabrielle Benefield

Agile software development processes have been influenced by best practices in Japanese industry, particularly by lean product development principles implemented at companies like Honda and Toyota, and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at MIT.

This minitrack will focus on advancing the state of the art or presenting innovative ideas related to agile methods, individual practices and tools. Accepted papers will potentially enrich the body of knowledge and influence the framework of thought in the field by investigating Agile methods in a rigorous fashion.

The track is open to research papers on multiple aspects of agile methods, particularly those that bring best practices in knowledge management and lean development to scalable, distributed, and outsourced Scrum, eXtreme Programming (XP), and other agile practices.

Papers of interest include these topics:

*Research on existing or new methodologies and approaches: informal modeling techniques and practices, adapting/trimming existing methods, and new product/project planning techniques.

*Research on existing or new techniques or practices: pairing, war-rooms, test-first design, paper-based prototyping, early acceptance test driven development, exploratory testing, refactoring, or others.

*Research on special topics or tools: configuration and resource management, testing, project steering, user involvement, design for agility, virtual teams or others.

*Research on integrating ideas from other fields, e.g. interaction design, requirements engineering, cognitive science, organizational psychology, usability testing, software security, into agile processes.

*Research studies of development teams using ethnographic or social research techniques.

*Research on agile software engineering economics.

*Quantitative and qualitative studies of agile methods, practices, and tools.

*Research on agile compliance and cost benefits within CMMI, ISO 9000, and FDA certified development projects.

Papers are particularly relevant when agile processes are shown to produce quantitative and qualitative benefits across multiple implementations.

Jeff Sutherland

Scrum Training Institute

Boston, MA USA

jeff@scruminc.com

+1 617 606-3652

Gabrielle Benefield

Scrum Training Institute

London, UK

gbenefield@gmail.com