Thank you for joining us on this journey!
You may know that Net Objectives has joined with Disciplined Agile and is now part of the Project Management Institute. Here is the press release: https://www.pmi.org/about/press-media/press-releases/project-management-institute-announces-acquisition-of-flex-from-net-objectives
As part of this migration, Al is now blogging on ProjectManagement.com. Here is the address of his blog: https://www.projectmanagement.com/blogs/581099/Manifesting-Business-Agility
We invite you to join in following him on that site.
On 30 September, the Net Objectives Thoughts blog will be officially closed.
If you have any questions, please contact Al at firstname.lastname@example.org.
This blog was originally written in April, 2012
I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.
That said, I believe manifestos, by their very nature when they are effective, tend to be time dependent. In the case of the Agile manifesto, this is particularly so – it’s very success has created a vacuum. Continue reading “Agile Manifesto: Incredible Success and time to Move On”
The value stream is the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.
Value streams are what they are, you don’t specify them. There are several ways to change them, however, including changing:
- what goes into them
- how people collaborate
- the order of the work (e.g., test-first)
- how teams are organized, the size of the work done
- the amount of work being done by the people in the value stream
The idea is to remove handoffs, delays and handbacks in the value stream. Doing so will lower cycle times and increase process cycle efficiency resulting in quicker time to market and realization of value.
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.
Back in 2006, I would always incorporate value stream mapping into the training or engagement. Over the years, however, as Scrum teams have become predominant, I have found doing to to be of less value. Not because value stream mapping isn’t important – it is, but because people don’t seem to be able to do it well.
Continue reading “Handoffs, handbacks, holdups and multi-tasking- discovering impediments without value stream mapping”
I work with many organizations that are fairly chaotic and far from Agile. While I’ve led fairly involved transformations, there are four actions a development group that’s 50-300 in size can take, mostly on their own, that can have a great impact. These are:
- Use Minimum Business Increments (MBIs) to identify enhancements to make to the system
- Have an intake product backlog (even better to add service classes) where all work in the system can be seen
- Organize around product teams. These are teams that can develop the MBIs defined. You can then create Scrum-Kanban teams (8-12 people) if the product teams are too big.
- Do DevOps phase 1- create visibility between dev and ops so ops knows what coming and dev understands what ops needs. Work together even if you don’t take steps towards continuous integration and continuous deployment.
These straightforward steps can be done quickly. Even if you are planning on using an Agile at scale approach, taking these steps early will help prepare for that.
Many companies find themselves organized around projects that come to their development group from all directions. There often isn’t even a backlog to see what’s to be worked on. This results in teams working on multiple projects at a time, multitasking, waiting for others, and general chaos. Short projects take months.
One solution is to get all of the groups of interrelated teams together every 3 months to do a big room planning event. This is putting all of the work that needs to be done over the next 3 months in a backlog and having the teams spend a couple of days ina big room planning together how they will manage it.
While not truly Agile, it is definitely an improvement in many ways:
1) all work is now visible
2) dependencies have been mapped
3) teams are now collaborating with each other
But this is really an accommodation to the challenge of value streams (workflows) that cut back and forth across teams. A better approach is to create teams that can get the work done on their own. This may be larger than a standard Agile team (8-12 people). But it can be subdivided into smaller teams with few dependencies between them. This is a much easier problem to solve.
Chris Argyris clarified that there are two levels to learning, which he described as single-loop learning and double-loop learning. Here are his definitions:
- Single-loop learning: Learning that changes strategies of action (i.e. the how) in ways that leave the values of a theory of action unchanged (i.e. the why)
- Double-loop learning: Learning that results in a change in the values of theory-in-use (i.e. the why), as well as in its strategies and assumptions (i.e. the how)
Continue reading “Using Double Loop Learning on Key Scrum Concepts to Improve Scrum”
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”