What are the essential ingredients for “turning the ship around”? How can a struggling team be transformed to a winning one? The blog series starts with a look from a higher level.
Preface
We have been in the business of improving the performance of projects of various sizes for the past 18 years. For the first ten years, we practiced agile transformation, in most cases that meant introducing Scrum with additional agile practices such as unit testing, story mapping. With time we were asked to tackle more complex projects and we noticed that our approach had its limitations. Scrum in our perception did not scale too well and the question of discovery remained unanswered.
In 2010, we decided to intensively look for alternatives to “mainstream iterative agile a là Scrum”. In the years to follow, we studied Lean software development, Kanban and design thinking among others. Since then, we have mixed agile, Kanban/Lean and design thinking in our continuous improvement approach and that in an increasingly systematic way. Today, we can significantly improve projects with tens to hundreds of participants regardless of the chosen approach, be it scaled agile, hybrid or traditional.
In this and the blogs to follow, we would like to share our approach to continuous, evolutionary improvement.
Principally speaking
Before diving into the essentials, let’s pause for some more principal remarks.
People come first, always
Products are created by people and neither by processes nor methodologies. Respect for people ought to be at the foundation of our efforts at all times.
Because they can
Teams (or teams of teams) win because they can. The right changes will only enable people to realize their potential, a potential they already possessed.
Agile values
The two core agile values are customer value and a positive work atmosphere. Customer value should be the ultimate driver. A positive work atmosphere is an essential prerequisite for individual performance and for any learning to take place.
A Path to Success
Here comes the real stuff. The first sections are on agile discovery — the techniques that allow tackling “wicked” problems — when you operate in the absence of clear-cut, obvious solutions. The remaining sections (after Story Mapping) deal with agile delivery, the methods that allow teams to turn concepts into running software. This is what you do when you know what to do. We’ll expand on each of the topics in future blogs so we’ll keep it short today.
Agile Discovery
Outcomes over Outputs
Agile discovery techniques are essential when just churning out features, meeting requirements and maximizing output is not the answer. When you do not know for certain that requirement X will have result Y, you do need a different approach. This is where outcomes enter the game. An outcome is a goal but not just any. It is a desired, specific change in user behavior and it can be measured.
Lean UX canvas
Lean UX canvas is a perfect tool to get teams start thinking in terms of outcomes rather than outputs. Used early in the race it can set the tone for the approach the team is taking.
The Right Metrics
Outcomes need to be measured and the choice of the metric(s) matters. We believe in a very small number of metrics. And each of the metrics needs to challenge the team, so we use “stretch”, “shoot-for-the-moon” goals. This means that the team is not likely to reach the goal; the chance of making it being at about for instance 50-60%.
Testing Hypotheses
The Lean UX Canvas session helped to identify the (hidden) assumptions that features rely on. These assumptions need to be testet early on. We use low-fidelity prototypes and UX lab sessions with structured user/customer interviews to get early feedback.
User Story Mapping
User Story Mapping is the technique to bridge agile discovery and agile delivery. User stories are aligned with outcomes and an incremental release strategy is developed. This feeds the product backlog the teams work on.
Agile Delivery
Once you decided on the features to implement, you need to deliver them efficiently and in high quality. To that end, we use a blend of Kanban and agile collaboration techniques. We’ll just mention the two main aspects today.
Manage the flow
To manage the flow we use Kanban; e.g., for identification and resolution of bottlenecks and blockers. Kanban is scale-free so if Scrum is not already present we definitely won’t add it. For multi-team projects we use Kanban as well for the inter-team coordination.
Agile collaboration techniques
Agile is not just iterative development a là Scrum. All the agile techniques that experienced coaches have in the past added to Scrum implementation are worth considering: user stories, refactoring, unit testing, pair programming, continuous integration to just mention a few. We always throw user stories into the mix early on. We do follow the user story process (far more than just “writing user stories”) and employ “Very Early Testing”. This gets us into the flow of performing many, small, incremental changes of high quality.
