There’s no need to re-describe Scrum. If you’re on a journey to discover Scrum, I welcome you. I advise you to learn more than Scrum and discover agile & lean.
I greatly recommend the collection of articles by Mike Cohn and Alistair Cockburn.
After attending a few presentations and after reading the small book “Scrum, a pocket guide”, I pleasantly appreciate Gunter’s writing on the topics of Agility and Scrum. I encourage you to read these articles and recommend that little book. It’s written honestly and offers transparent descriptions.
With this are a bunch of excerpts and links (all text is copy-paste of blogs):
Agile and Scrum, entwined and related
Agile and Scrum, actually, are not interchangeable synonyms, but two inseparable ingredients in a software development ecosystem, pure chemistry.
Agile are the principles to Scrum, Scrum is a foundation for agility.
The Scrum Stance
People employ empiricism to optimize the value of their work.
Agility via Scrum
Agility is a state, a way of being; of people and of organizations. It is not a process, it is not a method. It is a state from which emerges flexibility, openness for change and fast responses to market changes. Scrum has become the most important Agile framework, allowing people and organizations to achieve this state of Agility. Scrum brings the rules and principles to organizations and their people to grow into this state of flexibility.
To shift or not to shift (the software industry paradigm)
The software industry has for a long time been dominated by industrial views and beliefs. The universally accepted paradigm was in fact a copy-paste of old industrial routines and theories.
Although it was not widely and consciously admitted, but this did put the software industry in a serious crisis.
The House of Scrum
The house of Scrum offers an open view on the world, while protecting from rigid behavior. Its inhabitants remain flexible at all levels to better deal with uncertainty, and shape -not predict- the future. They sense, probe and adapt at all levels. Scrum drives building better software products, and faster. In 30 days, or less. But, most of all, it restores energy and work pleasure for all involved.
Scrum Values
Less known and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based.
Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.
Scrum values:
- Commitment
- Focus
- Openness
- Respect
- Courage
Yes, we do Scrum. And…
An article about doing Scrum and improving beyond Scrum. It also describes the Common adoption path of Scrum.
The Blending Philosophies of Lean and Agile
Beyond the clear similarities in Lean and Agile thinking, Agile has distinct practices that match the main Lean principles.
Maximizing Scrum
It’s not only about “scaling”. It’s about “maximizing”.
Enjoy the scaling effect of maximizing. If you run out of improvements, consider adding teams. Choose wisely where you want to invest in first.
Accountability is a quality of agile
In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.
Scrum foresees a clear accountability for each Scrum role:
- The Development Team is accountable for creating releasable Increments.
- The Product Owner is accountable for maximizing the value of the work.
- The Scrum Master is accountable for the understanding and application of Scrum.
These accountabilities are separated, yet all are needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem.
Done is a crucial part of Scrum, actually
Done Increments are THE way to achieve agility through the empiricism of Scrum.
The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.
The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.
Scrum, actually
Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty.
Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.
Releasable in Scrum, actually
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)
In Scrum, actually… releasable means all work done to release to the market. Instantly.
Agile and Scrum, actually
As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.
In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.
Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.
Meetings in Scrum, actually
Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.
In Scrum, actually… meetings are opportunities where people meet to change their mind.
Team size in Scrum, actually
Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.
In Scrum, actually… team size is a team decision.
Velocity in Scrum, actually
Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That in turn is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity.
In Scrum, actually… velocity makes most sense if a measure of a team’s capability to create releasable software.
Comments are closed.