Category: Scrum

Scrum Believes in Self Managed Team. That means, the team has the autonomy to organize itself to best complete the work items. Scrum has a completely different attitude to the conventional approach in that it explicitly puts the responsibility of solving problems into the hands of a self-managing team. There is no provision for someone to “make sure” it all goes OK, there is no “safety net” should things start “going wrong”. Scrum believes that the most appropriate people to solve a problem are those who need to deal with it.

• A key part of self Managed team is that, whatever the solution/design/approach the team comes up with, it is more likely to take into account local issues and current, relevant knowledge that it is more likely to work. This also has an added benefit in that, when things get hard, the team are much more committed to making things work as it is their decision/solution etc. They will find ways for it to work, whereas if it were someone else’s decision they would be less motivated and may say something like “I didn’t think it would work, but it’s some one else’s problem”
• Previously even a supposedly “empowered team” had a project manager to fall back on, someone who would carry the can if things went wrong (and perhaps take the glory if things went well) and so, when the crunch came, they knew the responsibility would be taken up by someone else.
• The vast majority of problems (or opportunities) facing our companies and teams today are complex ones. Everything we come up against, or ideas we come up with involve ever-increasing levels of complexity that usually cannot be solved by one person’s mind. Therefore we need to harness the motivated minds of a team where the value of the whole is greater than the sum of the parts.
• There is nowhere to hide in a self Managed team, everyone is responsible for the performance of everyone. No individual team member is held accountable.
• Self Managed team can greatly increase productivity, motivation and satisfaction for all concerned. This, coupled with more suitable deliverables is a true win:win scenario. However, in order for the benefits of self-organization to take root and bear fruit, we need a conducive environment for it to flourish. We need to have a culture of “all information is good information”, an understanding that “everyone did the best they could given the circumstances”. What matters is the project success rather than individual success.

Note – earlier version of Scrum Guide mentioned the term “self Oragnized”

The Matrix above shows the context of Product vs Teams.

• When we define a Product – here we define a Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts.
• Scaling means there are multiple teams working on a Product (Value Stream). Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope of Scrum.
• “One Team – Many Product” quadrant is for Staff Pools who do heterogenous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

SCRUM ONLY DEFINES ONE TEAM, ONE PRODUCT CONTEXT. SCRUM LEAVES IT TO SCALING FRAMEWORKS TO DEFINE SCALING AND PORTFOLIO MANAGEMENT FRAMEWORKS TO DEFINE PORTFOLIOS.

Scrum is a Process Framework. The word Framework means “MINIMUM SUPPORTING STRUCTURE”. Scrum does not define any details related to tools, techniques, implementation details or does not give specific recommendations on how to deliver complex work. Scrum defines the following

• 3 Roles – Scrum Master, Product Owner and Development Team
• 3 Artifacts – Product Backlog, Sprint Backlog and Increment
• 5 Events – Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective and the Sprint

Beyond the minimum, Scrum gives flexibility to add things to the framework as the Scrum Team desires to. For example, there could be a mid-Sprint Review, there could be an additional Demo meeting to the PO, User Story could be used as a technique to represent scope, Automation tool such as Selenium could be used to implement regression test automation etc.

What is a Method?

Method is much more than a framework. Method may contain a framework of its own, but may also includes :

• Tools and Techniques
• Detailed Processes
• Detailed Guidance
• Templates
• Document Formats
• Organizational structures
• etc

Example of a method is Extreme Programming

A Metaphor of Framework vs Method

A Framework – Essential supporting structure – a Empty Photo Frame with a Glass

a

A Method – Details, Tools Techniques – An Photoframe along with the Photo which gives all details

a

There are two types of process control

• Defined Process Control – Plan driven way of doing things. Where the target (goal) is known, one can create a Plan and execute the plan.
• Empirical Process Control – Goal driven way of doing things. In this type of problem, the solution or requirements or both are unknown. So, one has to take decisions on something which has already happened. So, the decisions have to be taken on trial and error way. Try something, see if it works, if it doesn’t work then try it another way. Too much of upfront planning is of no use in this type of process control

In Scrum, decisions are made based on Empirical Process control. In Scrum we try observation and experimentation rather than on detailed upfront planning.

Transparency

 Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture.

Inspection

 Inspection in Scrum is depicted through:

• Use of a common Scrumboard and other information radiators
• Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog , and Conduct Release Planning processes.
• Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

Adaptation

 Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.

A Metaphor on Empirical and Defined Process Control

Scrum is an iterative and incremental Agile product development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach”. Scrum enables the creation of self-organizing teams by encouraging collaboration of all team members, and verbal communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum is founded on Empirical Process Control Theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum Employs an iterative, incremental approach to optimize predictability and control Risk.