Why Scrum is not mandatory

Scrum vs PMOs

The organisations in Fortune 500 who adopted SCRUM returned a 40 times higher Shareholder Value than their competitors.

What is type of Management is Scrum and why is it better than classical Project Management? To clear that up with an image, lets look at exhibit A:

So, as we can see, in Classical Project Management, the scope is fixed and the costs and deadline do vary.

Comparison of Classic vs Modern Project

WATERFALL

SCRUM

Is that something you are willing to put up with, then Waterfall is the way to go for your project. However, you may still want to continue reading to find out what the benefits of empiricism vs belief is. Predictability of classical project management does not mean that these prediction based upon pure belief are turning out to be true, quite the contrary, in 99.9% of all cases the arising of oracle-like predictions are turning out to be false.

This is for a various of reasons. First it is academically proven that IBM's Function Point Analysis does not work, second, if every dimension of the Project Management triangle is fixed, the project can not be adapted to changing customer requirements, whereas Scrum can. Third, and this follows from the last point I made, FPA is not empirical since not all requirements of the project can be known before it has even started.

So, we will be way better of, if we stay with fixed costs and a fixed deadline, but introduce a variable scope as in Scrum. Furthermore, Scrum tries to fill the Project Management Gap by introducing the Product Vision, Product Goal and Release Planning, something most classical Projects do not address, so Scrum do let go of the Project Manager role, however that role is fullfilled by the Scrum Team and all accountabilities in a shared and self-organised fashion. This has the benefit that the responsibility and ownership of project outcome in Scrum is now partially shifted to the Development Team and therefore they have some skin in the game and are interested in success.

Now let's start our deep dive into the Scrum framework.

Agile Values

You probably heard of these before but I want to explain a bit on them and how to understand these Agile values.

People over processes

Create an environment where people can collaborate and communicate. Tools and processes are prone to slow adoption to fast and rapidly changing requirements

Software over documentation

Streamline documentation. Working software is the best indicator for success.

Customer collaboration over contract negotiation

Not only at te beginning or end of the project, but this results in only fullfiling contractual requirements, and not meeting expectations resulting in failure of the project.

Responding to change over following a plan

A planned waterfall project can't adapt to new or changing requirements, especially at later stages, missing opportunity of reacting to customer feedback resulting in a less successful product.

12 Agile Principles

(1) Highest priority is to satisfy the customer through early and continuous delivery of valuable software or product features

To receive feedback early-on and meet customer expectations.

(2) Welcome changing requirements, even late in development, to harness change for customer competitive advantage.

In classic PMO-driven projects changes are not welcome, because that would go against the plan and timeline.

(3) Deliver working Software frequently, weekly or monthly

Don't wait to release until each and every feature is developed but instead try to deliver as soon as possible, enabling the team to learn fast and improve the product.

(4) Business people and developers must work together throughout the project.

In classical projects driven by PMOs and Gantt-Charts business people are only involved in the requirements analysis phase. Agile implements continuous feedback loops in the project to be able to adapt and learn fast.

(5) Build the projects around motivated individuals. Give them the environment they need and support them to get the job done.

In an Agile project, the individuals are the most important factor for success and are able to even solve the most complex problems.

(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile strongly prefers forms of direct communication, such as face-to-face, in-person, human-based, eye-to-eye, voice-to-ear communication channels.

(7) Working software is the primary measure of progress.

In an Agile mindset it is not about sophisticated documentation or a very detailed product plan. A working software will satisfy the customer and is the measurement of success and progress.

(8) Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

To avoid peaks in development activity, Agile employs constant, iterative cycles of work phases focused on a common Goal, called Sprints.

(9) Continuous attention to technical excellence and good design enhances agility.

Agile sees Software development as a kind of craftsmanship instead of simply aiming to finish some tasks.

(10) Simplicity and the art of maximising the amount of work not done is essential.

Many products contain features that are not required or in use after the development. In Agile it is preferred to have a few features working very well, instead to have many features unused and difficult to maintain.

(11) The best architectures, requirements and designs emerge from self-organising teams

Self-managing teams do not wait for anyone to give them their work, i.e., a Project Manager. Every member of such a team feels responsible for a great product and therefore manage their timelines and tasks on their own.

(12) At regular intervals, the team reflects on how to become more effective, then times and adjusts its behaviour accordingly.

Avoids stress by inspecting interaction of the team and finds ways to become more effective.

Scrum Basics

Scrum helps teams and organisations to generate value through adaptive solutions for complex problems.

Accountabilities

Developers are committed to develop a piece of workable Software each Sprint.

resp. for Product Increment / Increment of value

Product Owner is accountable for maximising the value of the product and responsible for prioritising the work to be done by managing the product backlog.

resp. for Product Value and Priorisation of Work

Scrum Master is accountable for establishing Scrum as defined in the Scrum guide. Helps everyone understand Scrum theory and practice in the team and in the organisation

resp. for Establishment & Facilitation

Events

Sprint Planning

• Initiates the Sprint. The team lays out the work to be performed for the Sprint.
• Creates a plan for how the work will be done.
• Goal tells why the Sprint is valuable and can be communicated to stakeholders.

The commitment of the team in a Sprint is the Sprint Goal since 2020 revision of the Scrum Guide.

Daily

• 15-min time-boxed event for the Scrum Team.
• Inspect progress towards the Sprint Goal.
• Adapt Sprint Backlog as necessary.

Retrospective

• How the last Sprint went in regards to individuals, actions, processes, tools.
• Plan how to increase quality and effectiveness.

Review

• Inspect outcome of the Sprint.
• Determine future adaptations.
• Team presents outcome of their work to key stakeholders.
• Progress towards the product goal is discussed.

Artefacts

Product Backlog

• Single Source of work for the Scrum Team
• What is needed to improve the product
• Represented by an ordered list of items

Sprint Backlog

• Sprint Goal (Why?)
• Sprint Backlog Items (What?)
• Sprint Plan to produce one or more increments (How?)

Increment

• Usable functionality that represents value for the customer
• Multiple increments may be created during a Sprint
• Must be a usable piece of product
• Up to the Product Owner to decide if an increment is releasable
• It is not a must to release during the Sprint or after the review
• All increments must work together
• Prerequisites to the increments must be developed beforehand and it must work together with the previous work done by the team
• Sum of all increments in the Sprint is presented at the Review
• It is allowed to release increments before the Review given they meet the Definition of Done

Commitment: Definition of Done

• Is a formal definition of the state of an increment when it meets the quality measures required for the product
• When it can be released
• Provides transparency by creating a shared understanding of what work was completed as a part of the increment
• I.e. An increment is tested, security approvals are received, documentation adapted