Ken Schwaber & Jeff Sutherland created the Scrum Agile Framework based on The New New Product Development Game (TNNPDG) & empirical process control.
In the 20+ years since Scrum’s ascension, other useful methods – Flow, Theory of Constraints, Kanban and Lean Management have come to the forefront. In addition, while Scrum was designed for single product teams, Scrum is now being used in product teams that must collaborate with others as well as in IT organizations. In addition, empirical process control, a major tenet of Scrum, is not consistent with the systems-thinking or learning methods of Flow, Lean and ToC.
The “New Scrum Game” is the result of taking insights from TNNPDG and the aforementioned methods and creating a team-level framework that can be used for teams at any scale and both for product and IT. By going back to the source and incorporating new thinking (Flow, Lean) while discarding outdated thinking (empirical process control) a better Scrum is created.
This “New Scrum Game” already exists in the combination of Disciplined Agile Delivery and FLEX’s Team-Agility. It’s not a variation of Ken and Jeff’s Scrum, it’s simply a modern version of the Scrum Hirotaka Takeuchi and Ikujiro Nonaka (authors of TNNPDG) had in mind.
This post continues my series on Getting Back to the Original Scrum.
Scrum is founded on empirical process control theory, or empiricism. Empirical process control means to try something, see what happens and adjust your actions based on this feedback.
There is no model (theory) underneath these practices. That is, you don’t make predictions based on an underlying theory you just see what happens (inspect) and then adapt to this feedback. This is why Scrum requires performing a Sprint to be able to see your impediments.
Continue reading “Why empirical process control is insufficient to do Scrum well”
This post continues my series on Getting Back to the Original Scrum.
Ken Schwaber and Jeff Sutherland captured several key concepts of what The New New Product Development Game (TNNPDG) suggested how product development teams should work. I believe these core roles, practices, events and rules are the core reason that Scrum works. These include:
Continue reading “How Scrum’s core is useful and incorporates the essence of Agile”
This post begins my series on Getting Back to the Original Scrum.
I understand why people think I don’t like Scrum. I have been struggling with this myself. I have used Scrum for almost 2 decades with great results. But I teach it differently and base it on a different model than the Scrum Guide.
I’ve been realizing what I love about Scrum comes from The New New Product Development Game and what I don’t comes from its redefinition.
Continue reading “Getting back to the original Scrum”
This begins a new blog series called FLEX Coaches Corner. I have just started Adopting FLEX online. Each lesson has a ‘coaches corner’ where I present coaching tips for participants. Each week I’ll put one of these out on Net Objectives Thoughts and collect them as Coaches Clinic.
We are told people always resist it, but this is an over-simplification. Consider this excerpt from A Simpler Way. Margaret Wheatley & Myron Kellner-Rogers
Continue reading “How do people react to change?”
Agile is a great ideal. It feels good. It is a call to liberation. We should never lose this. But we must also remember Millard Fuller’s observation “It is easier to act your way into a new way of thinking than think your way into a new way of acting.”
This means working together will get you to trust and respect faster than saying to trust and respect each other will get you to working together. The latter is a nice thought but doesn’t work with divergent roles and values.
Continue reading “Step 2: Shift from Agile at the team to business agility”
“We cannot solve our problems with the same thinking we used when we created them” Einstein
The team focus of 2001 is no longer viable. Early adopters could adopt Scrum without regards to the bigger picture. The key was having a cross-functional team that Scrum and XP were designed for.
But as soon as Agile spread beyond one team, it ran into challenges. Team dynamics are different from organizational dynamics. Scrum ran into problems because forming cross-functional teams required committing someone who was needed on several teams to one team. Agilists didn’t have methods that solved this problem.
Continue reading “Step 1: Acknowledge the need to move from a team focus to systems thinking”
For a movement that’s about quick delivery, continuous learning, innovation & flexibility, Agile has lost its way.
Organizations with good minded people who see better ways to do things are faced with massive delays to get started because Agile has become a huge endeavor – an anti-thesis of Agile. Agile would say “start and learn.”
Continue reading “How did Agile become so unagile”
“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.
Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)
ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.
The benefits of ATDD are
- improved collaboration
- clear acceptance criteria
- prepared for automated testing
- improved developer-tester communication
- reduced time for feedback
- agreement on requirements
- improved code quality
It’s one of the best steps towards building the right thing in the right way.
For more information see:
Benefits of Acceptance Test-Driven Development using Behavior-Driven Development
How to Start with ATDD using BDD
The following is an excerpt from the chapter Adopting SAFe at Small Scale in Al Shalloway’s new book – Achieving Agility at Small to Mid-Scale
The Challenge of Essential SAFe
SAFe proponents suggest Essential SAFe be used for small companies. The reason for this is that small companies don’t need the complexity that full SAFe entails. But even small companies have the issue of taking their strategies to fulfillment. This means that the concepts of strategies, epics, solutions, capabilities, and MVPs are still needed. The challenge, of course, is that these are defined at the levels above Essential SAFe.
Most small companies adopting SAFe are mostly attracted to:
- the program increment and its planning event
- the role of the release train engineer (RTE) to coordinate teams
- having teams work in cadence with synchronization
These can be used as the cornerstone of their SAFe adoption. However, a simple Agile Product Management approach that takes the company from strategy to realization of value is still required.
See chapter above for more.