Share this
by Mindi Clews on 16 July 2015
While agile development approaches are being used widely in New Zealand, it is clear that few organisations have prevailed in using these approaches consistently across teams to the extent that they truly achieve business agility. Organisations often find that inhibitors to business agility become more visible and more painful during Agile adoption. The root cause of many of these problems relate to the organisational context around the project, programme or Agile development effort.
Two weeks ago I facilitated an Equinox IT webinar delivered by Rowan Bunning on the topic: Overcome common agile problems using Large Scale Scrum. Rowan is our training partner for Scrum-based courses and Australia’s first Certified Scrum Practitioner and Certified Scrum Trainer. He is also a Certified Large-Scale Scrum Practitioner.
During the webinar Rowan presented 7 Agile development problems that organisations often face and he showed how Large-Scale Scrum (LeSS) can help overcome those problems. In this article I summarise the key problems and takeaways from that webinar with Rowan.
What is Large-Scale Scrum?
LeSS is a framework for scaling Scrum practices and patterns outside of a single project team to deliver value across 2 to 8 teams working on the same product. LeSS Huge is a second LeSS framework that does the same except for products requiring 8 teams or more. LeSS is based on 10 plus years of real-world experiments in the Scrum community. The main contributors who have undertaken and documented these experiments and codified the learning into principles, guides and a framework are Craig Larman and Bas Vodde.
LeSS focuses on different teams working together collaboratively on combined sprints to deliver a shippable product. A fuller description of LeSS can be found on our earlier blog post Using Large-Scale Scrum for scaling Agile development.
Overcoming common Agile problems using Large-Scale Scrum:
Problem 1: Water-Scrum-Fall
Water-Scrum-Fall refers to the common situation where Scrum is used inside the Agile development team, but this team is contained within a misaligned waterfall wrapper. The reality is that our organisational structures have evolved during a time when waterfall was the prevalent way of delivering work and these structures have not been built with Agile or Lean in mind. These structures still dominate the design of many of our organisations today and, as a result, while the development team may be agile and delivering working software in regular sprints, the Waterfall wrapper means that overall the programme may deliver in large batches, say every quarter, greatly limiting business agility.
Applying systems thinking, a system - such as an organisation - has certain finite performance characteristics. As we look to achieve the characteristic of greater agility from our organisation, a different organisational system is required. LeSS provides this different system by scaling Scrum patterns up to the large using small batches to deliver benefit realisation to the business every sprint, providing feedback loops early and often to continuously improve the process and product.
Problem 2: Dependency hell
Dependency hell occurs when separate teams own and work on components such as the front end, content management system (CMS) or search facility. In this situation features of a large product typically cut across the different components to deliver a chunk of value. The dependencies between teams can quickly become complicated and management of dependencies add substantial overheads. Organisations typically respond to this by introducing multiple management and co-ordination roles to manage the dependencies.
As an alternative, Large-Scale Scrum structures teams around features. ‘Feature teams’ learn to work across the multiple components required to deliver the features end-to-end. As a result, dependency issues are pushed from planning time to integration time, where a focus can be put on continuous integration to identify and resolve component change clashes between teams.
Problem 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. This is the intent of Scrum and Agile and is a principle that LeSS supports across multiple teams working on a product.
Problem 4: Contract game
The ‘contract game’ is a description of the internal relationship that most organisations setup between business and IT; it doesn’t just relate to contracts with external parties . Internal contracts often focus on locking down scope and dates early in a project or release cycle when the information needed is limited and of poor quality. Once the business succeeds in getting the development team 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 team to fulfil that contract. The business then loses visibility, control and the ability to make trade-off decisions to avoid waste and maximise the value for money. This can be problematic when you need to be more agile.
IT delivery teams or their management will often hide the reality of the project to the business. Furthermore, when under stress to deliver all the scope that was agreed earlier, when less was known about what is feasible, development teams find themselves with no choice but to 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. Scrum works best when there is transparency so that good decisions can be made to deal with the reality of the situation.
The competing pressures tend to escalate to a blame game between business and development team; a competitive environment when really we should be striving for collaboration and partnership in Agile development.
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. This creates a direct, collaborative relationship between the business person (who bares the external demand pressure of the market or business objective) and the Agile development teams. Clearly this is a better result than the relationship being intermediated by a contract that incentivises unhealthy behaviours and relationships within the organisation.
Problem 5: Skills bottlenecks
Moving to feature teams can be an issue if the teams don’t have the skills on each component to do the work. In LeSS, when teams can use specialist skills they exploit those skills, but when accessing specialist skills from another team is a constraint, the team breaks the constraint and moves forward acknowledging that they may deliver the work 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 can be a valuable investment for increasing flexibility and throughput.
Problem 6: Lack of cross-team learning
It can be a big issue if disparate Scrum teams don’t keep aligned and learn from each other. Using Large-Scale Scrum there is a greater focus on collaboration and learning across teams. Examples include ‘big room backlog refinement’ and ‘tradeshow or science fair sprint reviews’. These can be great ways to get rich dialogue going about the product and encourage cross-team learning.
Problem 7: Lack of design and architectural alignment
Organisations are often concerned about how to achieve architectural and design alignment at scale. Using LeSS, feature teams will have 'cross-team design workshop's and 'cross-team collaborative documentation' of the design every few sprints as it evolves.
Learn more
It is highly likely in your organisation that you face some or many of these problems and that as you adopt Agile, these are becoming more visible. If so, Large-Scale Scrum as a framework may be an area that you want to investigate further to gain awareness of how it might help in your context. A good next step would be to watch Rowan’s webinar that he delivered with us Overcome common Agile problems using Large-Scale Scrum. Also take a further look at our interview with Rowan on LeSS: Using Large-Scale Scrum for scaling Agile development. More LeSS resources and case studies are available from less.works.
