Some people want to matrix their people into multiple projects, or having the same team do multiple projects simultaneously.  Although Scrum doesn’t explicitly say that these are “bad ideas”, they are.  They involve something that in Lean Development is called “task switching”, and it is part of a bigger Lean Principle called “Eliminate Waste”.  Although, there is not a formal historical connection from Scrum to Lean, we have to remember that many of the companies that were doing product development analyzed by Nonaka and Takeuchi in their seminal paper “The NEW new product development game”  (if you don’t have a copy of the paper get it here: http://www.enterprisescrum.com/publications/), like Honda, Canon, Fujitsu/Xerox, Panasonic had employed by the late 1970s and early 1980s, many consultants from Toyota that brought the Lean ideas to with them and apply them, not only to Production systems (as in Toyota Production Systems), but to Development.  In fact, that difference about what Production and Development, is what determines the scope of applicability for Scrum:  Scrum is a portable empirical process execution framework. (More of this stuff at http://www.enterprisescrum.com/enterprise-scrum  ).  But this is a fact:  you can reverse Scrum and see many Lean Principles at work.  For this reason, I say that Scrum is Lean (in the American Value and Effectiveness way).  Of course, Scrum is really Agile, as are other Agile methods, because it not only cares about Delivering Value (through efficiency and avoiding waste), but by Doing the Right Thing first (prioritizing the Product Backlog), but in addition it also has Customer Focus, Embracing Change, and Focus on Individuals and Interactions. 

If you do Scrum you must read the paper above “The NEW new product development game”  by Nonaka and Takeuchi, HBR, 1996.  I have read it no less than 10 times, and continue to search for inspiration on it.  It is required reading for everyone doing Scrum.  Find it here: http://www.enterprisescrum.com/publications/

We avoid waste in Scrum because we want to maximize the efficiency ratio of our Scrum implementation.  We define the efficiency ratio as: 

 Er = Sum of all Value Adding tasks/Sum of ALL tasks 

When there is little waste is closer to 1.  When there is a lot of waste (like in a typical CMM implementation), it is closer to zero.  Keep this mind when tweaking Scrum (or anything else really).

Having said that, there are a lot of other ways to avoid waste in Scrum:

• •       Partially Done Work – we try to move from Sprint to Sprint without it!
• •       Extra Processes – we avoid thick useless documents, bureaucracy and approvals for “talking to the right people”, for example
• •      
• •       Task Switching – we avoid working on “too many things” during a Sprint – 1) multiple-project by the same team, 2) individuals matrixed in multiple projects, 3) very many tasks by an individual within a project

Note to the managers in this list:  Matrix the least amount of people – matrix destroys efficiency because it involves “task switching” 

• •       Waiting – we avoid waiting  -- that’s why in Scrum we get feedback daily and have a ScrumMaster that resolves issues to minimize waiting time through the Daily Scrums
• •       Motion – we avoid “hand-offs”, phases and assembly lines  – instead we socialize knowledge to avoid moving things from one specialist to another one whenever we can
• •       Defects – we avoid defects – defects ruin our we test^4, unit, regression, system, acceptance to avoid defects

Defects are specially important because they control what we call the Correction Demand ratio, defined as: 

 Cd = Correction Demand (tasks or stories related to correction) /All of the Demand (Value and Correction) 

When this ratio is large, it can ruin your Sprint productivity by using too many cycles making corrections for previous Sprints.  That is why in Scrum we need to integrate and test everyday and we prefer continuous integration and layered automated testing.  A good measure, a fitness test of your software if you will, but certainly not the only “goodness measure”, is the percentage of completed acceptance tests for all PBIs and User Stories defined as:  

% completed acceptance = Sum of all acceptance tests that passed / Sum of all acceptance tests

But beyond waste, there are other Lean Principles, first documented in software by Mary and Tom Poppendieck, and these are some examples of how Scrum uses them:

• •       Eliminate waste - many examples in Scrum (as stated above)
• •       Amplify Learning – User Story Workshop, Planning Poker, Buy the Future, Release Planning, Sprint Planning, Sprint Review, Daily Scrums, Retrospective, Scrum Board, Burndown
• •       Decide as late as possible – Prioritizing the Backlog, Architectural scan, normal Agile development
• •       Deliver as fast as possible – this is JIT (just-in-time) for software or other process requiring empirical management, Sprints, Releases
• •       Empower the team – Scrum teams are always self-organized whenever possible
• •       Built integrity in – organizing User Stories in epics and themes, using architectural and design patterns
• •       See the whole – User Story Workshop, Planning Poker, Buy the Future, Release Planning, Sprint Planning, Sprint Review, Daily Scrums, Retrospective, Scrum Board, Burndown 

I hope this helps you see not only “waste” but to apply other Lean Principles to your Enterprise Scrum implementation,

Mike Beedle

Enterprise Scrum

http://www.enterprisescrum.com

Let's translate this question into a tradeoff question:  should we prefer the stability of the team provided by a good ScrumMaster, or should we opt for a marginal speed given by the SM taking some development tasks, and if so how many.

In my experience, the right answer, depends on the environment.  In some environments the SM can perform tasks, in some others is too risky.

For example, if the development team is developing applications with a complex architecture in a challenging domain, doing work through multiple Scrum cells some of them which might be distributed, with a set of fast changing set technologies, a highly political environment, and working with a “little trained” PO  – I would not recommend having a “coding SM”.  It would be too risky.   However, if the team is working on a single cell co-located Scrum cell with small or medium complexity, average technology complexity and/or change, and a reasonable PO, I might be much more inclined to have a SM that is also developing some code – but with the understanding that their SM responsibilities always have higher priority.

But what exactly do we trade off?

We can answer this question by looking at the responsibilities of the SM:

PROCESS:  Responsible for the entire Scrum process - Leader and motivator about doing Scrum:  

•       ensures Artifact quality

•       helps and coaches Roles to do their job: product owner,  customer, developers

•       ordering of activities, meetings, time-boxes

•       sets up, conducts and facilitates ALL meetings

•       ensures Engineering practices are followed

•       Ensures the Team has a good social context, a good environment, and it is SWARMING!

•       Enforces ALL rules

•       Promotes ALL values: transparency, honesty, courage

•       Insurance for “doing things right.  Intervene only if necessary!

TEAM: Flips between Coach, a Watchdog, a Mentor and a Project Manager, Rep to Management

•       Recommends or finds initial members of team

•       Responsible for team balance:  how many BAs, developers, testers, etc. of what kind?

•       The Scrum Master is responsible for setting the team up for success

•       Removing the barriers between development and the customer so the customer or the user directly drives development

•       Ensuring team actually did what they said they would do: checking testing reports, etc.

•       Balancing the team workload – e.g. pass work to early finishers

•       Shielding the team from outside disturbances

•       Removing Impediments and resolving issues

•       Promoting creativity, collaboration and knowledge sharing

•       Improving the lives of the development team e.g. flexible hours, flexible days, payback for heroics, etc.

•       Improving the productivity of the development team in any way possible: training, tools, system-level things

•       Improving the engineering practices and tools so each increment of functionality is potentially shippable

•       Promote team pride

•       Organizes Celebrations after releases or sometimes after Sprints

CUSTOMER: Teaches the customer how to maximize ROI and meet their objectives through Scrum

PO: Responsible for training and keeping ongoing communication with Product Owner (good PB!)

ADMIN: Maintaining the Sprint Backlog and producing Sprint Burndowns

•       Posting the Sprint Burndown as Visible Status:  Wall, Wiki, email, etc.

•       Ensuring Scrum Board gets updated

•        

MANAGEMENT: representative to team for management

MULTI-TEAM: Participating in the Scrum of Scrums such that both how their team affects other teams, and how other teams affects his team are understood, if no other team member is available

•       Coordinating participation of their team in either the “big room” Sprint Planning Meeting, or in a staggered Sprint Planning Meeting understanding dependencies, or coordinating with architects when they exist

•       Coordinating participation in the Sprint Review Meeting, both independently and with the rest of the multi-team, the latter is specially important in releases to production where many dependencies exist

•       Coordinating with integration Sprints when they exist

•       Coordinating integration issues with other Teams

•       Working with their team or theme PO and with the CPO (chief product owner), to ensure their teams can choose portions of the Product Backlog (usually though themes)

•       Coordinating with their individual teams on dependencies or modified work found at the Scrum of Scrums

So from the risk management perspective having a SM working for the Scrum team protects the productivity and stability of the entire team.

If a SM can do all of the above while “developing code”, more power to him or her, but my advice would be to not compromise the above high-priority tasks for a marginal velocity increase that may compromise the work of everyone in the team instead,

- Mike Beedle  

Enterprise Scrum Inc.

Dear friends,

Since we are Agile by practicing many agile methods, it might important for us to know what Agile really is and where it came from.  As it turns out, there was an Agile in business 10 years before agile in software ever existed.  No, it is not the "origin of agile in software" or even the only relevant historical reference -- it is only part of the story, yet, it is the only other thing we called "agile" before "agile software development".

There was a lot of parallel development between the business and the software concepts of Agile, that is they developed almost independentlly, but Agile in software was definitely named Agile because of the already existing Agile concepts in business that defined both Production and Development processes with it -- and that itself was a fortunate coincidence.  As it turns out, they do have a lot in common.

But in fact, we do know there is a historical connection from Scrum itself, since some of the Lean techniques were used there for development in the early 1980s and Agile in business evolved from Lean.  Agile Manufacturing and Development from the business perspective is, or at least was seen as the next step after Lean in the evolution of production and development methodologies.

 I have heard several people in the software space over the last 10 years suggest that we should use the same concepts in the Agile Manifesto www.agilemanifesto.org for business purposes – and they are right, except the application of these principles to businesses had already happened nearly 10 years before we wrote the Agile Manifesto.  In fact, the first “Agile” conference was:

• First Annual Agile Manufacturing Enterprise Conference in Orlando, Florida, December 1991

Almost ten years before the Agile Manifesto in software. I teach this history and both the business and software Agile principles at my Scrum courses (CSM, CSPO, CSD, Enterprise Scrum, ScrumStartup) – it is important to understand previous art and the true origin of things.

To understand what Agile is from a business perspective and in what context it was invented in 1991 and 1992, I invite all of you to read the seminal paper on the subject – where Agile was first defined at:

21st Century Manufacturing Enterprise Strategy, Roger Nagel, Iacocca Institute, Lehigh University, 1992

http://www.enterprisescrum.com/publications/

However, be aware there are hundreds of papers and several books written on the subject since then.  This publication also resulted in the creation of the Agile Manufacturing  Enterprise  Forum, still in existence today, as far as I know.

Here are the companies which executives participated in the creation of the concept:  Air Products  & Chemicals, AT&T, Boeing  Helicopters, Chrysler Motors  Corporation, FMC  Corporation, General  Electric Aircraft  Engines, General  Motors Technology  Center, IBM  Corporation, Kingsbury  Corporation, Motorola  Corporation, Naval  Industrial  Resources  Support Activity  Center, Texas  Instruments, TRW  Space  & Defense  Sector, Westinghouse  Electric  Corporation  Systems & Technology  Center, Westinghouse  Electronic  Systems  Group.

Over the early 90s period (1991-1994), I consulted for 3 of those corporations, so I had in-depth knowledge about this effort from very early on, and in fact produced several publications with the name Agile:

Enterprise Architecture Patterns: Building Blocks of the Agile Company, SIGS, New York, (1998)

cOOherentBPR: A pattern language to build agile organizations, PLoP '97 Proceedings, Tech. Report #wucs-97-34, Washington University (1997).

Here are some of my favorites quotes from the paper:

“The  Agile Manufacturing Enterprise  Forum  seeks nothing  less  than  the revival  of American  competitiveness through  the  adoption  of agile  manufacturing  strategies.”

“The  fact that all of the world's leading manufacturers  have to build a new infrastructure  to make the transition  from mass production to  agile manufacturing  provides a  unique opportunity for U.S. industry to regain the leadership it lost in the 1970s and  '80s.”

“Those nations  that  focus now on speeding the transition to agile manufacturing will become the strongest competitors in the global marketplace.”

“Rapid  product creation,  development  and modification  in  an  agile  manufacturing  enterprise is made  possible  by:

(1)  the  routine formation  of inter-disciplinary  project  teams, able  to  develop product  designs and  manufacturing  process  specifications  concurrently

(2)  extending  the  concept of design  to the  entire  projected  life cycle  of a product,  from initial specifications  to  its  eventual  disposal

(3)  the availability  of  scientific  knowledge  of  the manufacturing  process,  and  of computers capable  of accurately  simulating product performance  characteristics,  and  of modeling  the entire manufacturing  process

(4) modular, flexible,  reconfigurable,  affordable  production  processes  and  equipment

(5)  the  ability  to  obtain  relevant  information  quickly,  to  share  it  with  project  members distributed  throughout  a  firm  and  in  different  firms,  and  to  link  that  information  directly  to production  machinery

(6)  modular  product  design  incorporating  reconfigurability  and  upgradability  leading  to extremely  long product  lifetimes.”

“The  flexibility,  superior process  knowledge  base,  and  focus on customer  satisfaction  of agile manufacturing  will  require  assimilation  of  social  values  into  the  managerial  decision-making process.”

In addition, the whole Agile initiative since 1991 was about going beyond efficiency and lean, which were already fashionable in the late 80s, into the other tenets of Agile Manufacturing, which Goldman et al. define to be in their book " Agile Competitors and Virtual Organizations - Strategies for Enriching the Customer" as:

1.valuing human knowledge and skills;

2.delivering value to the customer;

3.forming virtual partnerships.

4.being ready for change;

This is in sharp contrast with the Agile Manifesto main statements:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

It was a coincidence and complete parallel development, as I stated before, but they in fact have a one-to-one correspondence:

1.valuing human knowledge and skills -->> Individuals and interactions over processes and tools

2.delivering value to the customer -->> Working software over comprehensive documentation

3.forming virtual partnerships -->> Customer collaboration over contract negotiation

4.being ready for change -->> Responding to change over following a plan

I teach this in all my Scrum classes as well – how close the two Agiles really are.

2. More Interesting Papers

At the Enterprise Scrum website you will find several other seminal papers on either Agile or Scrum:

Borland Software Craftsmanship: A New Look at Process, Quality and Productivity, J. O. Coplien, AT&T Bell Laboratories, 1994

“The project capitalized on its small size by centering development activities around daily meetings where architecture, design, and interface issues were socialized.”

SCRUM Development Process, K. Schwaber, 1996

“Rugby student William Webb Ellis, 17, inaugurates a new game whose rules will be codified in 1839. Playing soccer for the 256-year-old college in East Warwickshire, Ellis sees that the clock is running out with his team behind so he scoops up the ball and runs with it in defiance of the rules.”

“Backlog: Product functionality requirements that are not adequately addressed by the current product release.  Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items.”

“The delivered product is flexible. Its content is determined by environment variables, including time, competition, cost, or functionality. The deliverable determinants are market intelligence, customer contact, and the skill of developers. Frequent adjustments to deliverable content occur during the project in response to environment. The deliverable can be determined anytime during the project.”

“Categorizing the systems development methods as empirical is critical to the effective management of the systems development process.”

SCRUM: An extension pattern language for hyperproductive software development, Beedle, Devos, Sharon, Schwaber, Sutherland, 1996

“The patterns of the SCRUM development method are presented as an extension pattern language to the existing organizational pattern languages.  In the last few years, the SCRUM development method has rapidly gained recognition as an effective tool to hyper-productive software development.  However, when SCRUM patterns are combined with other existing organizational patterns, they lead to highly adaptive, yet well-structured software development organizations”

The New New Product Development Game - Nonaka and Takeuchi, HBR, 1986

“Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.  rather than moving in defined, highly structure stages, the process is born out of the team members' interplay.”

“Moving the Scrum downfield -- From the interviews with organization members from the CEO to young engineers, we learned that leading companies show six characteristics in managing their new product development processes: 1. Built-in instability, 2. self-organizing project teams, 3. overlapping development phases, 4. multi-learning, 5. Subtle control, 6 organization transfer of learning”

Scrum History, Jeff Sutherland, 2004

“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.”

“On this fertile ground, the Takeuchi and Nonaka paper in 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 (only after daily meetings started), and Scrum was born.”

Happy reading and best luck with you Enterprise Scrum implementations!

- Mike Beedle

Enterprise Scrum Inc.