The Whys Underneath the Hows of Scrum
I know there is a lot of variability in how Scrum says to do things. That said, most of Scrum is defined by predetermined Hows.
Hows, are constraints. The essence of Scrum is defined by values and hows. The values are fine but if you don't have them there is no advice on getting them. Scrum defines its roles, events, artifacts, and rules with Hows. That is, how to do something, leaving out the what (intention) and why (motivation). Having some flexibility in the How doesn’t remove the constraint. And, of course, you can add things as long as they are consistent with and don’t replace any Scrum How.
The problem with being given Hows is that people focus on what they are familiar with when they are busy. They don’t look at other ways. So yes, while Scrum allows for constant contact with the customer, given the base How is feedback at the end of the sprint, most busy teams will be happy with that. They take the path of least resistance. Also, they are doing Scrum, which tends to bias them to do what’s in the guide.
This is human nature. It shouldn’t be ignored. But it is.
Providing a set of Hows has two advantages. They provide a clear set of rules within which to work. Most people need this. They also provide a simple starting point. But we must ask “are they the correct set of rules to be starting and working with?” The answer is “not always.” (Actually, the answer nowadays is "not usually").
After presenting the Hows of Scrum here, I present how to find a way to start with Scrum’s Hows and migrate into a better set of rules. All the while having a well-defined set to work from.
Here are the roles, events, artifacts, and rules of Scrum presented with a What and Why along with Scrum’s How. Note that for each How many other ways may be more appropriate to the team(s) yet, if done, would have you not be doing Scrum.
A point of clarification. Embedded in some of Scrum's roles, events, artifacts, and rules are some Whats. For example, do a retrospection. But by also providing the Hows, without the underlying Whys and Factors for Effective Value Streams , the focus in on How. And locks us into it. You cannot change a How without understanding the Why.
What: A set period of time within which to work to create focus and to get feedback.
Why: Focus will have us work on the most important items, and quick feedback will minimize waste
Alternatives to Scrum's How: Sprints, Daily Flow, and Cadence .
What: Have a team plan ahead so team members know what needs to be done.
Why: To align the team.
What: Keep team members informed about what’s going on and enable quick pivoting.
Why: Keeps the team aligned. Avoid staying on a bad path.
What: Review the work with the stakeholder value is being added before.
Why: Gets feedback on what’s been done and provide a path for pivoting. Keep customer informed.
What: See how well we did over a period of time.
Why: Improves both our workflow agreements, the quality of what we are building, and our model of understanding.
领英推荐
What: Have a mechanism to know what will be worked on next from a product / release point of view.
Why: This provides alignment to the people doing the work.
What: Provide clarity on what is being worked on over the time period planned.
Why: Creates clarity for individuals and for ways for them to align.
What: Build in increments of value.
Why: Constructing in small steps is a great way to get feedback and, if released, provide value.
When you have a foundation of Flow, Lean, and the Theory of constraints it’s straight forward to use the How that fits you team(s) and not be constrained by an arbitrary set of Hows.
How to have flexibility while starting as easily as Scrum.
Just start with the Hows of Scrum.
Use the Factors for Effective Value Streams to consider better practices for your situation as you run into problems. SeeKnow how to select a more effective practice for your situation to get more information on how to do this.
Note that this approach gets us an easy start while providing us with a way to improve.
Be aware that the metaphor of Scrum being training wheels is surprisingly accurate while exposing a major impediment of Scrum
The difficulty in learning to ride a bike is learning how to balance. Training wheels actually slow down learning how to balance because you don’t need to. A better, safer, easier, faster, more fun way is to remove the pedals on the bike. Have kids go on a very gentle sloping ground keep their feet near the ground and learn how to balance. When they lose balance merely put their feet down. They never fall. More fun. Quicker learning.
Scrum as training wheels is accurate. What we really need to learn is how to adapt. But we don’t allow for adaptation of the specified Scrum roles, event, artifacts, or rules. These are useful to start with. It makes for a simple start. But we never learn the equivalent of “balance” this way which is how do we improve our practices.
The irony of Scrum proponent's insistence that Scrum is like training wheels is that it implies at some point that you have to take the training wheels off. But they don't tell you how.
This is Amplio Team
I call the approach discussed here Amplio Team. It's based on Flow, Lean, The Theory of Constraints and Human Centered Development. It doesn't have any required practices but drivers from first principles.
How to do Amplio Team is part of the ACE Learning Journey and can also be learned in the free Amplio Community of Practice.
Over a six-month period, in addition to Amplio Team, you can learn more scope than what’s in Scrum@Scale, Disciplined Agile Value Stream Consultant, basic Kanban, and an integrated coaching workshop.
It is designed to enable you to learn at your own pace and is surprisingly affordable. Check it out.
?
?
?
?
International expert for agile multi-project management - helps companies to find the bottleneck - factors more projects in less time with the same costs
8 个月fits to my post ... i don't care about the how's ... it's just about Flow - and there just two Laws have to be fulfilled (like Physics) - Little's Law and Goldratt's Law ... ... if you understood both you can find the best Hows' you can imagine ... interstingly you can evaluate whether it's a good how - because if you know the two laws you also know the optimum!
What do you mean by “core”? Curious - I may be mis-assuming!