I have been doing Scrum trainings for a long time. During the last several years, I have stressed more and more the importance of understanding the nature and purpose of the Scrum Framework at the beginning of the classes. Most of us know that Scrum is often understood in the IT industry as a process-oriented framework and that is one of the original sins that spoils the goal of obtaining what it was designed for, helping people to address complex problems. In a recent class, while trying to discover new metaphors to convey the true nature of Scrum, the term contextless (that sounds close to the "contactless" credit cards) came to mind to describe the mechanical, stringent and simple use of Scrum without considering the needs of the team or organization context.
In this article I will stress again the utmost importance of understanding the context of the organization as a strategy to achieve a possible, evolutionary and deep application of Scrum within organizations. This is, by no means, accepting distorted or flaccid applications of Scrum. It is aimed to avoid an orthodox or rigid view of the Framework that makes it fail in many organizations, when they reach the conclusion of "we can't do Scrum here".
Back to the basics: Scrum and complexity
Scrum outperforms predictive project management approaches when it is applied to solve complex problems. In those situations, achieving a precise analysis and defining an effective solution of the problem is difficult. The Stacey model summarizes in the groups the complexity drivers of a problem: requirements to achieve, technology to use and people involved in the product development or use.
Scrum outperforms predictive methods in the complex domain because it implements the empirical process control. It does not need to start with a heavy upfront analysis of the problem but one light split a big problem in smaller ones, easier to tackle, and learning continuously about all the complexity drivers (requirements, technology and people) to optimize both the solution and the processes to try to achieve it. The principles of transparency, inspection and adaptation are at the hearth of the empirical process control optimizing the value of the Scrum Team's work. The five Scrum values (courage, focus, commitment, respect and openness) enable the transparency, inspect and adapt principles.
So that, Scrum help teams to discover sooner better ways of approaching the problem, increasing the odds of obtaining a better product with potentially less time or effort.
Scrum and the team/organization context
Teams and organizations have different contexts, potentially huge ones. The Scrum Guide defines the Framework intentionally in a lightweight way, with minimal constraints and rules, so that teams can use Scrum as a thinking tool to discover how to optimize and tailor it to their context. Using it as a process model would render it as a rigid methodology to be followed, potentially without generating shared understanding on Scrum teams of why things are done that way and therefore how to continuously learn and improve.
Tailoring Scrum to the context of requirements
Why could requirements be less or more complex? Requirements can be difficult to understand upfront due to many reasons, e.g.:
- Requirements may have a complex nature, such as the cases of a complex algorithm, or a complex business domain.
- Requirements may not be complex indeed, but people involved have not experience with the problem. In this cases, once they learn about it the complexity may drop.
- Requirements may also have medium complexity, and people involved may also have experience with them.
In the first case, estimating a roadmap to solve the whole problem may just not be possible. A possible strategy to use could be to split the problem in parts and learn about this smaller chunk of requirements working in Sprints, so a partial roadmap could emerge. In the second case, defining a roadmap to solve the problem could neither be possible upfront, but after some learning about the requirements is obtained, it can be easier to define a whole roadmap to be continuously refined. In the third case, estimating a roadmap upfront could be even simple.
So that, Scrum can be used in contexts when defining a plan upfront can be attainable or when obtaining an emerging plan can be possible or even impossible
Tailoring Scrum to the context of people
How could people add complexity to the development of the product? Perhaps they are internal users without time enough to explain their needs. Perhaps they are people we don't know so we can't even ask them about their needs, e.g. external potential customers.
In the case of requirements to be developed with busy internal stakeholders it can seem an odyssey to have them to define and validate the requirements during the Sprint. When that happens, is not uncommon to get PBIs blocked during the Sprint because lack of requirements or validating them with the users during the Sprint Review, when the Scrum Team is supposed to inspect only what is "done". The preferred way to achieve effective Sprints is to increase the collaboration of stakeholders or even changing them with others more available. If that cannot be achieved, perhaps a workaround could be to define a stringent "Ready" with clear acceptance criteria. While that is certainly not very "agile", because it creates inventory and increases the "cycle time", it could be a better choice in the trenches that discovering painfully many items not accepted during the Sprint Review.
In the case of external users with highly uncertain behavior and likes, we may try to mitigate rework and waste by increasing empathy with users using techniques such as "Personas", experimenting systematically in very short feedback loops, and validating the work using practices such as web analytics, online surveys, A/B testing, etc. In this context, defining closed "Ready" requirements could be totally useless and Sprint goals could be highly oriented towards learning about the users.
So that, Scrum can be used in contexts when defining requirements previously to the Sprint may be needed, or in other contexts where doing that may be useless.
Tailoring Scrum to the context of technology
Technology adds a third driver of complexity to the product development and it can even make a product unfeasible. Questions about the technology that could be unknown before starting the development of a highly innovative product:
- Can the technology meet the performance or the requirements of the user?
- Is the technology mature and ready now to develop this product for the market?
- Can we achieve to design a product with the time and budget available?
Furthermore, when we develop with hardware products it is often not possible to achieve a potentially shippable product at the end a Sprints. That can be due to the facts like:
- The natural duration of some tasks in the technical domain can span several sprints.
- The response time of third parties providing us components that the Development Team could do internally in the case of software products.
Does that mean that we should give up to use Scrum then? Perhaps in those development efforts we could tailor Scrum like:
- If a Done increment cannot be reached within the time-box of 30 days, define one slightly longer that it stills helps us to have a frequent enough and useful feedback.
- The goal of a Sprint could be just learning about a really crucial technical risk, like testing if a physical part can achieve a strength enough for the operational use.
So that, Scrum can be used in contexts where the technology does not add a significant complexity, or in other context where dealing with the technical part can be a daunting endeavor.
To sum up
To achieve an effective use of any tool, we need to understand why it was invented to do and why it is designed in this way. Understanding deeply the components and rules of the Scrum Framework is mandatory to explain them to teams and help them to obtain a good use of Scrum. But if they want to achieve a great use of Scrum, it's even better to show it as a thinking tool, made to be tailored to their context by understanding deeply why empirical process control was intended for, how the Scrum pillars help to implement empirical process control, and how Scrum values help teams to enable an effective cycle of transparency, inspection and adaptation.
As the "shu-ha-ri" maturity path suggests, perhaps in the very first weeks of helping teams to embrace Scrum the stress might be put on achieving stability and understanding of the framework rules, but as soon as possible start transferring the ownership of the process to the teams by focusing their attention to the principles and values of Scrum. That will also help them to achieve a better tailoring and sustainable Scrum implementations.