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.