Q: “We need to be able to manage our Change Requests within our project, but how is that done when we are doing Scrum?”
A: “Ok. Then that is easy. You don’t do CR’s, you prioritize”
Q: “What if we need more done in the same time?”
A: “Then you can discuss scaling the team. It is an increase in costs, but has nothing to do with CR’s and Scrum”
The above was a completely fictional discussion, but the topic is not that uncommon. Just the other day a colleague came to me after having a similar discussion with a client.
Organizations who try to adopt more agile ways of developing their software solutions often still hang onto old management practices that do not really mix with the wanted approach. And unfortunately ‘Scope’ and ‘Change management’ are common topics in this area. Scrum, for example, is seen as a ‘development phase’ thing in a project and is not understood as an end-to-end framework from concept to release, where upfront planning and scope definition is replaced by continuous planning and design activities.
Instead of defining too much of the actual work upfront, we take an empirical approach, where the starting point is that we do not know everything. Changes are a natural part of the day-to-day project and not a separate process where you manage Change Requests (CR’s later in this article).
Time and Scope over Quality
The main target of any business-IT project is to deliver value to end users; value which is measured based on the needs of possible users of that software. Yet quite commonly, when the success of projects is measured, the criteria is based on:
-
Schedule… Even though during the project, we can find new things that provide more value than the ones originally considered.
-
Scope… Even though in the beginning of a project, we have most likely not identified all the things our users consider valuable.
-
Budget… Locked based on the 2 above factors, which are not completely known and therefore not 100% reliable.
In a traditional model, CR’s are a way to manage this uncertainty. We spend a lot of time planning and making guesses, based on which we define a schedule, a scope and a budget which are set in stone. Then it is easy to hide behind an agreement when we encounter a surprise: “Not in the planned scope, we need a CR”.
Time and Quality over Scope
Dandy people has created an excellent set of free posters and infographs related to Agile. One of them focuses on Product Ownership and has this really nice and simple picture regarding Planning for value.
Any software solution developed nowadays should not be considered as a project, but as a product. The focus in developing the product should focus not just in the project life-cycle, but also in the overall solution life-cycle. If time is something that is limited, then the possibility to deliver less with more quality usually ensures that the overall solution life-cycle costs stay smaller. Most Agile frameworks emphasize Quality over Quantity (Scope).
Product Ownership is a full day job which requires focus, commitment and mandate to make the needed decisions. When working with Scrum, for example, the Product Owner has a center-stage role in ensuring that the focus is on the right things. PO’s should have the time needed to do the role and the organizational mandate to make decisions for maximizing the value delivered by the team. Again, better to do less and more quality than more and less quality.
A type of waste
When working in a complex environment, change is constant. A CR process caters to the needs of a project over the needs of the solution ( its life-cycle) and the users the solution is meant for. CR’s cater to the false assumption that it is possible to know all the solution details beforehand.
CR’s are in the first place a way to manage costs, but when you consider the effort and time needed to define a CR and process it through, then doesn’t it actually in some cases work against the need of managing costs?
If we take this further and look at the principles of Lean, then the CR process itself can be considered waste, since it does not directly add any value to the solution, so why spend time on something that isn’t of value?
The important thing here is not to mix scope and cost with each other. Increased costs do not necessarily translate to waste, if the target is to increase the delivery of value. These are the cases where (in a project context) something that relates to CR’s can be considered since the targeted value requires an increase in costs. (Like scaling the team.) Still, these kind of changes should still be driven by targeted value, not the targeted scope.
Faster time to value
When working with an iterative and incremental framework like Scrum, we break the solution into small pieces and focus on priority and delivering with quality. The focus on priority and quality ensures that anything we deliver to the actual users most likely resolves a real user problem, is easy to maintain in the future, and hence provides both short- and long-term value.
Within any Agile framework, the main target should be in delivering value as often as possible, preferably every day. This becomes extremely hard if we manage the surroundings with waterfall-type management principles. Next time you think about starting a CR process, think about if it really serves the users, or does it just serve the management process? With the time it takes to process the CR, the problem it relates to might already be solved.
