One of my favorite activities is teaching (potential) Product Owners about their roles and responsibilities in the Scrum Team. One of the most important things I try to help them understand, is “time is rigid, scope is flexible”. And it’s true, in the (Scrum) projects I have been working on at a digital agency for the last few years, quotes do not contain a detailed list of detailed features. And Product Increments made within the Sprints are successful in achieving their Sprint Goals, but are (on a level of functionality) not always what was envisioned at first.
Every once in a while, I encounter a client with the need to describe every detail beforehand. Or that they express the need to have a detailed design of all features fully fleshed out “before the sprint”. The feeling underneath those needs is valid; some managers long for control and like to have a clear view on the ‘value for money’.
As Scrum Master and agile professional, but also based on my experiences as a project manager, I advocate that time should be ‘rigid’ and the scope should be undetermined, and thus flexible. This would seem as giving up control. I am here to tell you: you are gaining a more valuable form of control and as an added bonus more flexibility, support – and overall happiness. My advice would be, in the lyrics of the 1995 hit by TLC: “Don’t go chasing waterfalls”.
(That’s it. I used a TLC GIF. You’re welcome.)
The unruly nature of software development
In the Cynefin® Framework, a framework that is developed to help leaders understand their challenges and helps in decision making, there are five different domains in which ‘problems’ can be categorized:
Software development is located in the complex domain, because requirements continuously change, technology continuously changes and people (stakeholders and end users) are unpredictable and therefore complex. And for complex problems, applying empiricism (and thus Scrum) is a sensible approach. So it’s a rather vain notion that in software development all can be planned and designed beforehand. I once experienced software development in a more conservative environment, where the creation of a website was compared to the complexity of making a brochure. Cause that’s what it is right; an online brochure? In a field of work where requirements continuously change, planning and designing everything beforehand is bound to create a feast of disappointment.
I remember a time where I worked in typical waterfall method. I used to manage (online) projects by making a detailed wireframe, which lead to a fully fleshed out design, which in turn lead to a development phase where developer(s) would create the front and back-end. The project would end with a single feedback cycle before live push. Oh, those days! If the client would come up with a new insight during the project, I would park the issue as an ‘author’s change’ and hold it off. I mean, the client did agree with the interaction design and the graphic design, so any new additions were …not really allowed. This made the process very rigid, unless the client in question put down their foot and new features were added to the project, prolonging the project and putting the finances of the project under renewed discussion.
Interplay of scope, time and resources
Project managers will surely recognize the ‘project management triangle’, also called the ‘triple constant’ or ‘iron triangle’. In Dutch we call it the ‘duivelsdriehoek’, which freely translates into ‘devil’s triangle’. That sounds rather ominous, and in reality it kind of is. It depicts the field of tension between three factors: scope, resources and time. Expansion of one, goes inevitably at the cost of another. The fourth factor is quality, neatly tucked at the center.
In practice, it’s mostly a wrestling match between scope and time, the two factors regarded as two universal truths. And it’s mostly seen as a scenario where the ‘unstoppable force’ of scope meets the ‘immovable object’ of time. It’ll end however, in tears; there is always a loser at the end. There is always a sacrificial lamb. When either time or scope are fixed, it usually ends in one (or more) of these scenario’s:
- The quality is reduced;
- There is an enormous stress on resources, either people and/or costs.
Scope is rarely reduced. And time, or rather the deadlines are sacred cows and are rarely sacrificed.
Quality, however, is a bargaining chip quickly cashed in when scope and time are fixed. But most often, the resources, or better put the (well-being of the) team is sacrificed to get the project done. In many industries, especially in IT related work, crunch-time is a given and simply to be expected. This causes a lot of stress! Not to mention, who is going to pay for all those extra hours? There is bound to be a negative financial coverage of the project. Does a client ever pick up the bill?
Applying Scrum in a project-based environment
So taking into mind the unruly and complex nature of software development and the general stress on quality and resources, many software developers have switched to an agile approach. Scrum, being one of these approaches, is a lightweight, iterative and incremental framework for developing, delivering, and sustaining complex products. The Scrum framework challenges assumptions of the traditional, sequential approach to development. A key principle of Scrum is the recognition that a) customers will change the scope and b) there will be unpredictable challenges for which a predictive or planned approach is not suited. These changes are accepted, embraced and analyzed. As such, Scrum adopts an evidence-based empirical approach; accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.
Applying Scrum in a project-based environment in a digital agency, one needs to deal with a degree of uncertainty that needs to be resolved, especially within the quotation of the project. There is an allocation of a budget to a project (i.e. a new website), which in combination with a broad outline of the functionality, determines an amount of Sprints to be included in the project.
Please note that continuous development of a product is not feasible for some products and budgets, here I am purely focused on a project-based environment where opportunities for development are fragmented and created through emerging needs and/or available budget.
Often there is a phase where strategic and/or conceptual starting points are explored, to provide the Scrum Team with valuable input for the sprint. This could be perceived as cooking up a detailed plan beforehand, but in my experience these starting points can be very useful and should always be perceived as valuable input; the development, and the making of all definitive choices, is done within the Sprints.
Time is rigid, scope is flexible
I have seen clients turn up with enormous MoSCoW lists of wishes and demands at the start of new projects, asking for a reassurance that all features should be included in the quote as a debriefing – as a reassurance of the value for their money. It takes a bit of reassuring, but basically it boils down to telling the clients that all issues should be “added to the Product Backlog”.
During the Sprints, there is a continuous communication and cooperation of the collective Scrum Team to deliver fully-functional Product Increments. The goals is to create the most value within the set time: Sprints are time-boxed events that are finite. So again: time is rigid, scope is flexible. The ‘what’ is determined by the Product Owner, the ‘how’ by the Developers.
The role of the Product Owner is vital within Sprints, because they give direction and purpose to the Scrum Team. This gives that person a lot of responsibility, but at the same time a lot of freedom. Choices to simplify or expand functionality are within the Product Owners means to give direction. And if suddenly new needs and wishes emerge, it is the Product Owner who re-prioritizes the Sprint Backlog.
I have noticed a great sense of mutual understanding within Scrum Teams in project-based environments. Where there used to be a client-contractor relation, these seems to be a better understanding for each other’s challenges and the complexities of software development. The implications of choices (and alternatives) can be openly discussed and weighed. I have noticed a more effective way of working because of direct communication, preventing needless feedback. Efficiency and flexibility in turn create space to turn out space for extra wishes and the implementation of extra nuances, giving a feeling of ‘overdelivery’.
Another thing I noticed is the sense of (shared) pride and joy of the Scrum Teams! The Product Increment is a collective effort and the fruit of the hard labor of all involved. In the Sprints where I was involved as a Scrum Master, I noticed a direct correlation between the mastery of effective scope management of the Product Owner and the delivery of a qualitative Product Increment – and the creation of a productive and joyful atmosphere.
“Don’t go chasing waterfalls
Please stick to the rivers and the lakes that you’re used to
I know that you’re gonna have it your way or nothing at all
But I think you’re moving too fast”