What is Scrum ?

Thanks to our discussions in the agileprojectmanagement@yahoogroups discussion forum, many of my assumptions and understanding of Scrum has now been clarified formally.

For those of you who are not very clear of what Scrum is and what it is not, here is what I was given to understand of what Scrum is, by a CST on this forum. I am taking this at face value pending its endorsement by the official big wigs in the Scrum Alliance.

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

I do not believe that the Scrum Alliance is under the umbrella of the
Agile Alliance. Many members of the Scrum Alliance are members of the
Agile Alliance, of course, but it would be incorrect to say that scrum,
itself, as a process for Agile Software Development. As Ken has pointed
out, one of the major scrum teams mentioned in the "Enterprise and
Scrum" book (the transition team) does not have software as a product.
Of course, most of us see scrum as a good process for Agile Software
Development, but it is not only for that. The Scrum Alliance defines
"Scrum: A team-based framework to develop complex systems and products."
right on the front page.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@danube.com, 425-269-8628

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

Based on this, I am now very clear on many of the aspects of Scrum implementation as an Agile Software Development Methodology, in software development environments.

So far everyone in the Agile Community have been adopting Scrum as an Agile Software Development methodology within the ambit of Agile Values and Principles. What we are now learning implies that "Scrum can also be used in Agile Software Development while it was never designed exclusively for Agile Software Development"

I recall a blog of mine titled "Scrum in not Agile" more thant 2 years ago that was frowned upon by the Agile guys ( http://scrumtales.blogspot.com/ :19th March 2007 ) Now it looks like afterall it was not so much out of the context.

With this, as a veteran member of the Agile Community I feel that the Scrum Alliance, for the sake of their own credibility, should clearly communicate this to their potential audience and may need to clearly spell out different approaches for implementing Scrum in the following varied contexts.

This also reinfornces my belief that we need to have separate versions of Scrum for the following contexts. Using a single generic approach in the practice of Scrum in all contexts may spell disaster.

1. Scrum for Agile Software Development (as in xp@Scrum)
2. Scrum for Agile Product Development (as suggessted in Ken's book on it)
3. Scrum for the Product Production Industry (sequential process or waterfall - as in manufacturing and construction industry) in line with what we are planning for FScrum
4. Scrum for Research and Development (as in Jim's Adaptive Systems Development)
5. Scrum for the Creative Industry (Advertising, Hollywood and other industry involved in Commercial Arts) that engages a true iterative empirical approach.
6. Scrum for PM BOK ( I know of this initiative by the Scrum Alliance to co-opt Scrum with PMI, IPMA and other project management associations worldwide )

This further reinforces my belief that working to develop an FScrum - a version of Scrum for the waterfall types, may not be invain.

I am aware that Scrum was created to be truly "ADAPTIVE" and it reflects in the evolving "Values and Principles" of the Scrum Community, who have been "EVOLVING" Scrum in line with changing market and economic considerations, over the years, for the benefit of all.

Clarifying the need for FScrum

Thanks to some great discussions on other sites, I realize that I have to clarify why I thought there was a need for something like FScrum.

Scrum is currently under the Agile Umbrella and is labelled very much an Agile Methodology. Hence in its implementation, we cannot voilate or be in conflict with the Agile Values and the Agile Principles clearly mandated by the Agile Alliance.

Therefore implemting Scrum as an Agile Methodology in a predictive (fixed scope, fixed time, fixed cost and fixed quality) plan-driven, defined process enviroment with traditional management structure (supervision and control) is a definite no-no, will be very hypocritical and treated as anti-Agile.

If we can use Scrum outside the Agile Values and Principles, in such contexts as illustrated above, and still be acceptable as in order by the Scrum Alliance, then we do not need FScrum.

However in such a scenario we may need to clearly distinguish between Agile Scrum and non-Agile Scrum. This is what I was trying to formalize and call FScrum (Formal Scrum) or Scrum for Waterfall.

Further to make this work in formal (non-agile) environments, we may need to modify Scrum Principles slightly so that it is in sync with "Waterfall" culture. Scrum Practices however (Roles, Ceremonies, Artefacts) can remain the same but "who does what and how" may need to change a little so suit a "Waterfall" environment.

VISION for FScrum - Brainstorming

Let's first try to build a VISION for our "FScrum", its potential Features, Advantages and Benefits, so we are able to clarify our own expectations from it. I am using this space to brainstorm, speculate, collaborate and learn to create a right VISION for FScrum, so we can architect its design correctly to enable it accomplish its goals and expectations correctly.

Needs Analysis - Why do we need FScrum

Organizations are looking for something like Scrum to help them improve in a Traditional Management Environment. When I say Traditional Management environment, it is where we have clear management structure and hierarcies, defined roles, responsibilities in the organization and is functioning in an environment of formal supervision and control systems.

Now these organizations cannot suddenly invert their pyramid structure, change their management style into an environment of empowerment and servant leadership, change the way they work with customers with contracts, and create new recognition and reward systems to promote and nurture group accountability for those working in self-organizing cross-functional teams delivering value to customers, in an empirical process environment driven by feedback.

This is an Agile Culture IMPERATIVE to be able to harness the Agile Values and Principles and implement Agile Practices like as in Scrum. Without this Scrum cannot work.

So, we need to have something like Scrum, which is not necessarily Agile Scrum but a Scrum that can work in formal environments....so again the name FScrum looks good.

Here is our first list of expectations from FScrum :

1. Something that does not mandate empowerment and self-organizing teams becuase we work in a traditional hierarchial structure with supervision and control, and we cannot invert our organization structure.

2. Something that does not manadate empirical process environment as we have a defined process environment and cannot invert it.

3. Something that allows us to work with Fixed Scope Contracts with our Customers because that's they we work and that's the way our Customers want it. We cannot change the way we do our business with our customers.

4. Something that does not mandate active Customer Collaboration and Co-creation, because our customers are not inclined to give us iterative feedback during development. They wish to have a clearly defined and approved scope upfront, before the project is contracted. We cannot change this way of working, and if we do this, we will loose all our current customers.

5. We will be happy to build software incrementally and iteratively in time-boxed iterations, as long as the iterative nature of adaptive planning is targetted at internal process improvements for the outputs, but is not targetted to iterate changes in Scope by customers for improving outcomes. Scope is frozen in a contract. (note the two words used here...outputs and outcomes). Outputs are for internal benefit (improving efficiency, quality, cost, time) while outcomes are for the benefit of Customers (customer satisfaction, Value, ROI, effectiveness). We cannot do this in our current environment even if we wished to do so.

6. We need something like Scrum that can address all our issues accross our entire Product Design, Development, Integration and Maintenance life-cycles. We are engaged in building large Mission Critical products for a wide range of our Customers that needs to be maintained and serviced for a long Product Life period. They are complex products with multiple technologies and interfaces operating in a complex IT environment of legacy and new applications. Hence they have be meticulously engineering for scalability, compatability, performance and compliance to industry and domain strandards. Therefore the scope, architecture and design of our products are centrally controlled and managed by core Product Engineering Teams and Product Managers very formally to ensure the overall integrity of its sub-systems. They are large and hence need many large teams working to develop it in a distributed and off-shored environments spread out worldwide. Agile Scrum cannot work as it does not scale up to large non-collocated teams in an off-shore product development environment nor was it designed to do so.

7. We still want to improve the way we do what we do. We also feel that there could be many ways to do it and find that some of the Principles and Practices in Scrum, Lean, TOC, CCPM, SixSigma can still be harnessed to our advantage, to help us improve within our own organizational contraints and limitations.

Can we think out of the box and build a process-innovation framework that can help us do better in our situation.

YES, WE CAN.

Scrum for Waterfall

Many Software Product Development Organizations working in a traditional plan-driven and process-driven environment are not able to apply Scrum in its right spirit.

Scrum is an adaptive management framework that is used only in iterative development, in the face of volatile and evolving requirements accompanied by high degree of unpredictabilities in the development scenario.

It is based on an empirical process approach that helps empowered self-organizing cross-functional teams "inspect and adapt" to fast changing situations in the development environments, achieved through a high degree of collaboration with their customers. Trust and Tansparency is an imperative in Scrum environments.

If Scrum is applied in a predictive, traditional management structure, it becomes counter-productive. Many times, when Scrum is implemented upside down in such contexts it causes such projects to move from "frying pan to fire". This is referred to as "Flaccid Scrum" or in Ken Schwaber's own term "ScrumBut".

On this blog-site we are trying to evolve a set of practices that can help deliver "Waterfall Organizations" similar kind of benefits that Agile organizations reap from methodologies like Scrum.

We wish to evolve a new variant of Scrum for the "waterfall" organization by drawing upon from the best of the paradigms in Agile, Lean, Six-sigma, TOC/CCPM and the likes, as appropriate, practical and feasible for such organizations using watefall as their main software product development approach.

We like to call this FScrum to mean, "Scrum for Waterfall"