Webinar summary: Seven Agile adoption problems with LeSS solutions
Over the last few months I have been speaking in Sydney, Auckland and Wellington about Large-Scale Scrum (LeSS). I'll be speaking about this in Melbourne too on August 19. An angle on this topic that I find particular relevant for just about anyone involved in Agile adoption is to discuss the organisational problems that LeSS seeks to solve together with the principles and patterns that have proven effective in solving them.
I recently recorded a webinar about this with Equinox IT who are Scrum WithStyle's long-standing training partner in New Zealand. So long-standing that I've actually been delivering Scrum training 3-4 times per year through Equinox IT for 6 years now!
We're delighted to share this material to you in three complimentary formats:
If you are not ready to watch a 45min video right now, here is a short summary verson of it.
Water-Scrum-Fall refers to the situation in which the Scrum team is contained within a misaligned waterfall wrapper. Most organisations were not designed with Agile or Lean in mind. The reality is that our organisational structures have been defined during a time when a sequential waterfall-style approach was the prevalent model. These structures still dominate the design of many of our organisations today and, as a result, while the development team may be producing working software for internal review in regular Sprints, the Waterfall wrapper means that the overall project or programme retains large batches and releases to users infrequently (many months) which greatly limits business agility.
When we apply Systems Thinking, it becomes clear that our organisation, as a system, has certain finite performance characteristics. As we look to achieve the characteristic of greater agility from our organisation, we need a different organisational system to achieve these different performance characteristics. LeSS provides a blueprint for this different organisational system by scaling Scrum patterns up to the large using small batches to deliver benefits from every sprint, providing shorter feedback loops, including with real customers, that raise visibility and help us to continuously improve both the product and the process.
2: Dependency Hell
Dependency hell characterises what organisations often experience when ownership of components is given to separate component teams. For example, a mobile front-end team, a content management system (CMS) team and a search team. In this situation, value-adding features of a large product typically cut across the different components to deliver a given feature or piece of value. The dependencies between teams can quickly become complicated and management of dependencies between such component teams adds substantial overheads. Organisations typically respond by introducing multiple management and co-ordination roles to manage the dependencies.
As an alternative, Large-Scale Scrum structures teams around value-adding feature sets. ‘Feature teams’ learn to work across the multiple components required to deliver certain features end-to-end. As a result, dependency issues are pushed from planning time to integration time, where the focus can be put on continuous integration to identify and resolve component change clashes between teams. This greatly reduces the dependencies between teams, the costs of managing these and the cycle time with which value-adding features can be added and iterated on.
3: Release Rigidity
Teams who release shippable product every sprint, say 25 releases a year, will achieve significantly more learning, greater benefit realisation and more business agility than teams who release shippable product just a couple of times a year (or once per quarter). Producing a Potentially Shippable Product Increment is the intent of Scrum and producing working software in short cycles is an Agile principle. LeSS accompanied by agile technical practices enable organisations to deliver releasable product increments frequently (e.g. every two weeks) even when many teams are making constant changes.
4: The Contract Game
The ‘contract game’ is a description of the internal relationship that most organisations setup between business and I.T. (or Product Management and R&D in a product-centric organisation). The Agile value of Customer Collaboration over Contract Negotiation does not only relate to contracts with external parties.
Internal contracts often focus on locking down the scope and dates early in a project or release cycle when the information needed to do so is particularly limited and of poor quality. Once the business succeeds in getting the development organisation to agree to as ambitious a scope and date as can be negotiated, the responsibility to deliver is shifted from the business to the development group to fulfil that contract. The business then loses visibility, control and the ability to make well informed trade-off decisions to avoid waste and maximise the value for money given the improved information that emerges through iterative incremental development. This relationship between the Business and I.T. can be described as transactional rather than collaborative.
Given expectations to remain 'on schedule' to meet the date and scope agreement embodied in the internal contract, I.T. delivery teams and their management are incentivised to hide the reality of progress to the business. Furthermore, when under stress to deliver all the scope that the development group was pressured to agree to earlier when knowledge was low, development teams find themselves with no choice but to silently take shortcuts that compromise the internal quality of the product. This comes at the expense of the long-term maintainability and sustainability of the product. This reduction in quality and accumulation of technical debt is not transparent to the business. Since Scrum is based on empirical process control which, requires as a precondition transparency so that ongoing decisions are based on reality, this undermines the Scrum approach.
The competing pressures tend to escalate in the form of a blame game between the business and the development group; a competitive environment when the Agile values suggest that we should be striving for collaboration and partnership style of relationship.
Consistent with the Agile manifesto, LeSS emphasises customer collaboration over contract negotiation. With LeSS, the business gets involved in steering development through a Product Owner who has the authority to make well-informed trade-off decisions to maximise business value across the whole customer-valued product. This creates a direct, collaborative relationship between the business person (who bears the external demand pressure of the market or business objective) and the Agile development teams. This business person no longer feels the need to sign up I.T. to a date and scope contract as they have the steering wheel themselves and steer development directly. Clearly this is a better result than the relationship being intermediated by a contract that incentivises unhealthy behaviours and relationships within the organisation.
5: Skills Bottlenecks
Moving to feature teams can be a challenge when a team does not have sufficient skills to carry out the work on each component that they need to change to deliver a feature. In LeSS, when a team can use specialist skills, they fully exploit those skills. When accessing specialist skills from another team becomes a constraint however, the team breaks the constraint and moves forward to work on that component acknowledging that they may deliver slower as they learn the required skill. In doing so, teams continue to focus on the highest value at all times and avoid introducing dependencies and delays. An underlying principle is that learning and skills acquisition such as this, are a valuable investment toward increasing flexibility and overall throughput in the future.
6: Lack of cross-team learning
If disparate Scrum teams don’t keep aligned and learn from each other it can lead to a new form of knowledge silos and problematic variance. Large-Scale Scrum enables collaboration and learning across teams through a number of cross-team interactions. Examples include ‘big room backlog refinement’, ‘trade show' or ‘science fair sprint reviews’ and 'overall retrospectives' that investigate the bigger picture organisational dynamics. These can be great ways to get rich dialogue flowing about the product and encourage cross-team learning.
7: Lack of design and architectural alignment
Organisations are often concerned about how to achieve architectural and design alignment at scale. By using LeSS, feature teams use cross-team design workshops and can do cross-team collaborative documentation of the design every few sprints as it evolves. By enabling interactive cross-team modelling, design problems, options and solutions are open to collaboration across all teams.
This illustrates how alignment can be achieved without centralising decision making to an individual architect. Also how, as the Agile manifesto suggests, "The best architectures, requirements, and designs emerge from self-organising teams."
The problems that LeSS is designed to solve are not necessarily those that other scaling frameworks are designed to solve. The Scaled Agile Framework (SAFe) for instance does not emphasise or provide patterns for convincingly solving the above problems in a way that is well aligned with Agile principles. If you are familiar with SAFe and have a perspective on this, I would be interested in hearing from you.
For further information about LeSS, see the excellent Large-Scale Scrum Website at less.works.