Wednesday, May 12, 2004

Early History of Scrum: First Scrum Creates Component Model


At a meeting of the Microsoft Business Framework Advisory Council in Redmond last week, I was reminded once again that there is a lack of good component models in object design tools. The best one I have seen was created by the first software Scrum at Easel Corporation in 1993. There was a reasonable implementation of this in the Object Studio Smalltalk environment (now owned by Cincom) and in a testing product by Jeff McKenna. Other than that, elegant component design implementations are nowhere to be found.

A Zen Master was asked by a student if he should go study under a teacher who claimed to be enlightened. The Zen Master, a collector of rare wooden buddhas, paused and then exclaimed, "There are enlightened teachers everywhere ... but a good wooden buddha is hard to find."

There are patterns and object models everywhere, but a good component model is harder to find than a good wooden buddha!

--------------------------------------------------------------------------------
Object Management Group, Business Object Domain Task Force

Ensembles: A Component Design Pattern for Business Objects

June 4-6, 1995, San Jose, CA
Doc No: OMG TC Document CF/96-01-04
Doc. Date: 25 Jun 1995 - updated 1997, 2004 by request
--------------------------------------------------------------------------------

Abstract

Successful companies generate continuous innovation through knowledge generation using a Scrum product development process documented by Nonaka and Takeuchi in The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation. The SCRUM development process, an advanced software application development environment, surfaced the need for seamless integration of business process reengineering with radical innovations in the software development process.

The primary benefits of object technology are based on reusability of plug compatible components. Class libraries have had limited success in providing for reuse because the cost of finding classes, reading code, and understanding the logic often costs more than writing new classes from scratch. Furthermore, frameworks created from current class libraries usually cannot be upgraded after installation without bringing down the application because the notion of a component is not well defined and plug compatibility is not possible.

Business reengineering leads to specification of business processes which are best implemented as reusable, large-grained objects. These objects are dynamic, encapsulated, instance-based components that are orthogonal to the object system class hierarchy. The concept of an ensemble which has appeared infrequently in the computer science literature will be explained and a specific implementation, the S&M ensemble will be described. S&M ensembles are designed to be scalable, nested, and plug compatible components that can be physically generated as OLE/COM or Javabeans objects.

This work has stimulated the OMG Business Object Domain Task Force to develop an RFP for an infrastructure for business objects systems that spans application-specific domains. Standardization of a component-based infrastructure is a critical first step towards building reusable, interoperable, business object frameworks that are the future of corporate application development. Business process reengineering demands radical rengineering of our approach to software development and making plug-compatible, reusable, business object components a reality.

The OMG presentation on S&M Ensembles, a design pattern for rigorous component specification, has been updated for the Web and appeared as the lead article in SunExpert, January 1997, and WebApps, May/June 1997. It was published as part of a CRC Press Handbook on Object Technology as Business Objects and the Evolution of the Internet. For a draft of the original ensemble specification created by the first software Scrum see:

Sutherland, J. and McKenna, J. (1993) Ensembles. Easel Corporation

Saturday, May 01, 2004

SCRUM: Pigs and Chickens



Pig Snouts at bullysticks.com

Ken Schwaber started the pigs and chickens story in the early days of Scrum. The terminology is now under deep discussion in the newsgroups:

A chicken and a pig were brainstorming...

Chicken:
Let's start a restaurant!
Pig:
What would we call it?
Chicken:
Ham n' Eggs!
Pig:
No thanks. I'd be committed, but you'd only be involved!

The real issue for a Scrum is who is committed to the project and accountable for deliverables. The committed get to talk at the daily Scrum meeting. They are the pigs and their butts are on the line. We could call them contributors if we don't like pig terminology.

People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk. They are excess overhead for the meeting. They might be called eavesdroppers if you don't like chickens. Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others. Sorry to be political incorrect but others should come up with a euphemism that conveys the right balance between being "nice" and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team.

If you look at most corporate meetings you will see 50-80% excess overhead. These are the meetings that Scrum eliminates on day 1 if done properly.

Most of excess overhead will claim they need to know what is going on because it impacts their work in some way. They don't need to know what is going on in the Scrum. They need to be able to see a visual representation off the backlog that is updated daily, preferably automatically on the web. At the end of the Sprint, they get to go to a demo where they can see exactly what went on, can provide their input, and can influence the next Sprint. This is where they can provide a real contribution.

One of the biggest challenges Ken and I had in various companies where we worked together was stopping members of Scrum from going to any excess overhead corporate meetings because they were one of the biggest suckers of productivity from the team. People that like to go to these meetings are often seen in a Scrum whining about not completing their deliverables because they were at such meetings. A well running Scrum has an immune system which expels such people who don't deliver over time.

Maybe we should call them barnacles, because like barnacles on a ship, they will sink the ship if they accumulate. It is good to have some negative connotation in the terminology, no matter what we call it. People will not change their behavior if they do not feel an emotional impact.

All of this needs to be handled firmly, impartially, and impersonally. A good ScrumMaster handles this effectively, tactfully, and persistently. S/he effortlessly converts barnacles into real contributors.

On occasion, there are people who have their jobs on the line if the Scrum doesn't deliver. These people have sometimes been welcomed into Scrums during critical periods. They are usually line managers or product managers who have a contribution to make - clear reiteration of the business objective and real time comments on the potential business effect of decisions in the Scrum. It seems to work best if they speak only for a minute at the beginning or end of the Scrum and the Scrum feels free to assign them work, particularly assignments to eliminate bottlenecks that are impacting Scrum productivity. They are expected to report on such deliverables in the Scrum (particularly if they are the Senior VP of Engineering or the CTO).

We have some litmus tests here on how well the Scrum is doing:

1. Are their barnacles present? Bad, productivity is being impacted.
2. Is the Scrum acting to reform them or eliminate them? Good, the immune system is functioning.
3. If there is any management present, are they assigned tasks by the Scrum? Good, the Scrum is functioning autonomously.