Eight Steps to Improved Scrum

From the Manifesting Business Agility Blog
by
This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog

RSS

Recent Posts

Are You Working on Your Problems?

Dealing with Complexity by Creating a Bias For Simplicity

Using Inherent Simplicity to Guide Your Actions

Why to use the word capacity instead of resource when referring to people

Why Teams Should Have a Tailored Approach for Adopting Agile



Scrum can be a solid foundation for software development teams. In the 24 years since it’s creation, many concepts new to software developers have come forth. I believe classic Scrum can be greatly improved by adding 8 relatively straightforward concepts/agreements to it. Some of these steps are more of an attitude shift that actual work. Some of the steps have different degrees of adoption. In this case it is suggested that at least a beginning step is taken.

Eight Steps to Improvement

Step 1: Consider Scrum as an example of what can be done. Anything in it can be changed as long as the objective of what’s being replaced is still met. See how to improve or change your practices

Step 2: Use  flow theory to create a focus on finishing and to avoid handoffs, handbacks, and delays in workflow/feedback

Step 3: Base this new Scrum on Lean. Include systems-thinking to help you see the big picture and have explicit workflow to facilitate collaboration.

Step 4: Test-first to some extent relating both to requirements and development understanding and requirements to implementation.  Ask the questions:

Step 5: use Minimum Business Increments. While MVPs are in vogue, most companies are not making an investment to see if a new product is useful but rather are trying to create additional value for an existing product/service.

Step 6: include management in improving the process. Servant leadership is to the organization not to the team. See Toward Middle-Up-Down Management: Accelerating Information Creation

Step 7: Have everyone agree to the guardrails. The basic agreements are:

  • Work on items that will realize the greatest amount of business value across the enterprise.
  • Collaborate with each other in order to maximize the realization of business value across the enterprise.
  • Ensure that all work will be made visible.
  • Take the necessary steps to sustain or increase predictability.
  • Keep the work throughout the value stream within capacity.
  • Encourage everyone to strive for continuous improvement.

Step 8: Continuously improve by deepening your understanding of software development by using PDSA in your retros to improve your understanding of the challenges being faced

Posted on: November 17, 2019 04:09 PM | Permalink

Comments (11)

Please login or join to subscribe to this item
Thank you, Al. Do you think these steps are limited to software development?

@Andrew, not if you cut out step 8 ;-)

@Sante
I don't understand your comment. PDSA is not at all specialized to software development. It's origins is with Deming and was refined by Toyota.

@andrew - no. The concepts apply everywhere. Scrum, btw, is not limited to software development, but i think if you are doing SW development you should adjust to the needs of SW Dev.

Here's how to state it in a non-software perspective:

Step 1: Consider whatever process you're doing as an example of what can be done. Anything in it can be changed as long as the objective of what’s being replaced is still met.

Step 2: Use flow theory to create a focus on finishing and to avoid handoffs, handbacks, and delays in workflow/feedback

Step 3: Have your workflow be based on Lean. Include systems-thinking to help you see the big picture and have explicit workflow to facilitate collaboration.

Step 4: Validate-first to some extent relating both to requirements and development understanding and requirements to implementation. Ask the questions:

When given a requirement: how will I know I’ve done this?
When about to implement it: how will I test this?
Step 5: use Minimum Business Increments. While MVPs are in vogue, most companies are not making an investment to see if a new product is useful but rather are trying to create additional value for an existing product/service.

Step 6: include management in improving the process. Servant leadership is to the organization not to the team. See Toward Middle-Up-Down Management: Accelerating Information Creation

Step 7: Have everyone agree to the guardrails. The basic agreements are:

Work on items that will realize the greatest amount of business value across the enterprise.
Collaborate with each other in order to maximize the realization of business value across the enterprise.
Ensure that all work will be made visible.
Take the necessary steps to sustain or increase predictability.
Keep the work throughout the value stream within capacity.
Encourage everyone to strive for continuous improvement.
Step 8: Continuously improve by deepening your understanding of software development by usin PDSA in your retros to improve your understanding of the challenges being faced

Dear Al
Interesting this perspective of Improved Scrum

In your opinion can these 8 points be included in other project development approaches?

Of course. let's look at the intention of each:
1) don't demand particular practices
2) use flow
3) use lean
4) validate first
5) use MBIs
6) use middle up down management
7) use the guardrails
8) continuously improve

Dear Al
Just now I read your answer to Andrew.
Thanks for sharing

@Al, it's called humor/sarcasm, something many empiricists seem to lack. Andrew was asking if the 8 steps were limited to software development, and since you mentioned software development in step 8, I jokingly replied "not if you cut out step 8", which was suffixed by a wink ;-) emoticon, lending further evidence of the jovial nature of the reply. My comment had nothing to do with PDSA.

@Al - Thanks for taking the time to respond.

Yes, agree, Scrum can certainly be used outside of software development.

In fact, I am currently not in S/D at all at the moment. First time actually :) and interestingly, I do know recognize why those who are not in S/D always feel that when people talk about Scrum, it typically through the lens of S/D.

After reading through the steps again, aside from #8, I recognize you did abstract S/D out, though your opening statement through me off - "Scrum can be a solid foundation for software development teams. In the 24 years since it’s creation, many concepts new to software developers have come forth"

Thanks!

Thanks for sharing

Please Login/Register to leave a comment.

ADVERTISEMENTS

Where lipstick is concerned, the important thing is not color, but to accept God's final word on where your lips end.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors