Agile software development methods, with the odd long since forgotten exception¹, adopt the use of fixed time increments, often wrongly called “iterations”². In Scrum, these are known as Sprints. A Sprint is a fixed period of time with a defined scope and a commitment³ to complete that scope within that time window. Originally, Scrum defined 4-week sprints. This was changed later, circa 2004, to a recommendation for 2-week sprints as the default. In general, it is recognized that agility is related to the frequency of interaction with the customers or business owners, and the frequency of deliveries. Hence, smaller timeboxes are more desirable, if you wish to pursue greater agility.
Software quality is often related to batch size and the time taken to complete a piece of work. The relationship is known to be non-linear, i.e. the defect rate rises faster and accelerates away as the batch size or length of time extends. Hence, smaller batches, completed in short periods of time lead to dramatically fewer defects. So, in theory, small batches of work are desirable.
Two ways to constrain small batches of work – timeboxes or WIP constraints
There are two ways to constrain the batch size of work: constraining the amount of time available to do the work, resulting in scoping to small numbers of requests that can be completed in the given time; or, simply constraining the number of work items, constraining the size of the batch of requests, also known as WIP constraints. All mainstream Agile methods adopt the use of timeboxes to constrain batch size by scoping work to fit in the available time. The Kanban Method instead adopts WIP constraints to directly constrain batch size.
At a small scale and with lower maturity organizations, it doesn´t much matter which of these two strategies you pick – they are both effective. Scrum is a perfectly good methodology to take a team from maturity level 0 to 1. However, as you both scale your ambition and the size of the organization, and improve the organizational maturity, with the goal of consistently delivering customer demand, within customer expectations, at larger scales (a product unit of 150 people, to a business unit of 600 to 1500 people or more), the timebox strategy breaks down. You cannot scale agility and organizational maturity with team-level timeboxes. The remainder of this article explains why not…
The Pressure for Shorter Timeboxes
The Challenges of Shorter Timeboxes
Developing capability with a new and hopefully better requirements analysis technique, designed to provide the granularity to ensure work items are sufficiently small as to fit neatly into a short timebox, is hard, even when you know with confidence which technique you should adopt. The challenge with very short sprints is that there is, still after 20 years of Agile, little or no solid guidance on writing fine-grained, consistently small user stories. Even if there is a good method that your team is comfortable using, then (a) you now have a lot of analysis upfront, before sprint planning, and (b) you have introduced a peer-to-peer, or parent-child dependency management problem, that becomes especially acute as soon as you are unable to select all of the peers for the same sprint, with the same team.
Fine-grained requirements analysis coupled to short timeboxed sprints introduces a dependency management problem to Agile methodologies.
Alternatively, in the absence of strong guidance on requirements analysis, anxiety leads to undesirable effects such as breaking stories up into functional units based on information discovery activities such as “architecture story”, “design story”, “development story,” “test story” where the real customer value may now span across multiple sprints and peer-to-peer dependencies between stories across sprints is now a tracking requirement. This type of breakdown defeats the purpose of the ever-smaller timeboxes and creates a false sense of agility when in fact, customer value and quality are not improving, perhaps the opposite may even be true. A failure to instrument for and track customer lead time disguises the problem, and Agile teams focused locally and only on themselves, merrily ignore that they are not delivering customer value.
The concept of a ¨Design Sprint¨ (or other similar, upstream, pre-commitment information discovery) is now a recognized thing and you can take classes in it. Be under no illusion, design sprints are an anti`-pattern, they are an indicator that timeboxed increments in Agile methods are a dead-end – they do not scale! To be Agile you need to be small – small teams, small products, small codebase. To scale, you need to abandon agility and use much larger timeboxes.
What if a story in our sprint backlog gets blocked because of a dependency? That might prevent it from completing on time. And hence, the shorter the sprint timebox, the greater the need to identify dependencies upfront. This requires yet more analysis of as yet uncommitted items in the product backlog. And what if there are dependencies? Agile methodologies resort to organization design to solve this – the magical cross-functional team. The idea that everyone on the team can do everything that might be required to produce a top-quality product. For any firm that aspires to market leadership, this has never been true – you don´t win at anything with generalists, winning requires specialists. A small band of elite generalists can and does happen but again it doesn´t scale. You don´t staff a 500 person IT department, or a 600-person business unit with elite generalists.
All too often we see organizations, like one of those in a case study we use daily in our training classes – they had 5 development teams, 3 data-base administrators, and 2 user-experience designers. So either, you put the two UX guys in each of 2 teams, and the 3 database guys in the other 3 teams and now you have 2 front-end teams and 3 back-end teams, and you try to plan the sprints such that those teams only pick front-end or back-end stories, and oh whoops, you are disconnected from the customer requested functionality and have created dependencies, or you accept the truth and you use the dba´s and the UX people as shared services, and once again you have dependencies.
Dependencies are a fact of life in all but very small-scale software development, or mediocre development done by largely dilettante generalists. If you are doing anything at scale, or anything that aspires to market leadership then you have specialists, and you have dependencies. The Agile movement has been in denial of this basic truth – to be Agile you have to aspire to be mediocre!
Scaling, Business-agility and Timeboxes
Dependency Management Anxiety is Rooted in the Sprint Constraint
If you want to be Agile beyond the team level, beyond maturity level 1, then you have to remove the constraint of timeboxes to control batch size. A time constraint is a fantastic way to take a chaotic organization from the anarchy of maturity level 0 to the control and predictability of maturity level 1, but that is where it ends. Time-constrained sprints are an evolutionary cul-de-sac, a dead-end. You cannot scale Agile using timeboxed sprints!
The answer is to focus on quality and short delivery times, by using a WIP constraint, rather than a time constraint. Only the Kanban Method offers this for organizations struggling to scale Agile.
How to Start your Journey to Large-Scale Business Agility
Relief from the Tyranny of the Timebox
Avoid: Will it fit within the timebox?
If things take, however long they take, then there is no need for upfront analysis to break an item into smaller items, no need to track complicated dependencies between sprints or across teams. Instead, let the work break down happen naturally once the work is committed for delivery. Track that work with a 2-tiered kanban board, parking lots, and avatars showing the involvement of shared services.
There is no need for awkward elaborate, big analysis upfront, estimation efforts. Simply track historical lead time through your workflow and use the lead time distribution chart to determine probabilistically how long something might take to complete.
Avoid: Will it get delayed by a dependency?
If things take, however long they take, then there is no need for upfront analysis to determine the need for specialists or expertise, nor do you need to constantly reorganize pursuing the Nirvana of the perfect cross-functional team that never needs assistance from outside. Let dependencies happen as you discover them, create visibility on to them, actively track them. Use a service-oriented approach to your organization design and utilize shared services for elite, specialist, market leading capabilities.
A General Solution for Dependency Management
If you need to pursue large-scale business agility, then you need to drop the use of time constraints to control batch size and improve quality and time-to-market. Instead you need to use WIP constraints and embrace the specialist shared services in your organization. Stop reorganizing! Start flowing work across a network of interdependent services!
To have a truly effective general solution for dependency management, you need to understand the opportunity cost of delay. You need to understand the urgency of a piece of work, and how dependency delays affect it. Later this week, we´ll be releasing that solution as an infographic poster in print-ready PDF format. You can also find it in Appendix F of the new Kanban Maturity Model 2nd edition available now.
If you are serious about enterprise scale business agility, we know how to take you there. Contact us for more information.