Rather than using a null reference when an object is absent, create an object which implements the expected interface but whose methods have no behavior.
Many of the behavioral design patterns such as State and Strategy allow implementation to vary without specializing clients. Often when a behavior or algorithm has many different versions, one of those versions may be to have no behavior at all. To avoid putting special-case conditional code, “if(!null)” for example, into clients, a Null Object can be used.
Continue reading “The Null Object”
Set up a structure that allows the addition of operations across a variety of classes without changing the classes.
Continue reading “The Visitor”
Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. (GoF)
Continue reading “The Memento”
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”
Use sharing to support large numbers of fine-grained objects efficiently. (GoF)
Continue reading “The Flyweight”
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.