How do “ENABLERS” contribute to your product development?
Preface
This article is targeted to the Scrum teams in a SAFe environment. However, the Scrum framework does not restrict us from adopting any best practices that benefit the team. Thus, I strongly believe the content will help any Scrum team out there in getting a brief idea about the Enablers and their relevance.
What are ENABLERS ?
An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality — © Scaled Agile, Inc.
Enablers help establish a solid Architectural Runway that enables the team in building large-scale solutions which are easily extendable and maintainable. Enablers can be considered as “Infrastructure Upkeep”.
Let’s put it in simple terms, It is like servicing your car. Timely maintenance ensures safety, delivers sustainable performance, avoids major breakdowns. If not taken seriously you are bound to face serious problems.
Small periodic investments often pay off in the long term and avoid the otherwise inevitable, expensive investments at a later point in time.
Unfortunately, we often see Enablers lagging to gain a spot against Features making them look like low priority items. This mostly happens as the Business Owners / Product Owners / Stakeholders do not see a customer value in the Enablers and do not consider it worth investing time on.
If this is what you often see in your organization or if you are not sure about the Enablers, then this article will provide you the clarity required to make the right decision.
Common reasons why Enablers are deprioritized ?
1. The product’s lifespan is short and it is built with an acceptance criteria to become obsolete at a later time.
In this scenario, the Developers / Architects do not see the benefit of investing in an infrastructure that is more suitable for a large-scale solution. Thus, the outcome will be precise with a possibility to expand but limited to support the product’s lifespan or any other factors applicable.
For example: When a customer wishes to build a prototype application that can scan QR code, it is very unlikely that the developers will develop a custom library rather they will use an existing solution that can scan the QR code and get the required result.
However, if the product has to provide more sophisticated features including data security, scanning custom QR codes specific to the manufacturer, and has an extensive future scope then it is worth investing in developing a library, patenting the solution (if applicable), and bringing Enablers for the continued support of the library and seamless product development.
2. The Stakeholders fail to see the long term benefit in having Enablers.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team — The Scrum Guide 2020
It cannot be always blamed on the management for not prioritizing the Enablers. The Product Owner should always guide the Developers in understanding the product roadmap and what is the long-term expectation. The Developers are the technical experts who will then propose the best approach to match the business expectations and produce the expected results. Thus, based on the inputs of Development Team, the PO should make the value outcome clear to the Stakeholders (if SAFe, Enablers are created by RTAs providing the guidance to analyze them and the information to estimate and implement them) This way it will be easy for the PO to prioritize the Product Backlog Items.
Please note: In case the PO prioritizes the Enablers, then it is the responsibility of the Developers to later present the outcome of investing the efforts on the Enablers. Any data that demonstrates how the Enablers helped avoid issues or saved long-term costs will be highly valuable for the Stakeholders / PO to consider Enablers in the future.
For example: Performance improvements providing better customer experience, any cost saved, or measurable improvements in the product quality.
3. Stakeholders interpret Enablers as maintenance activity and consider the product is too young for Enablers.
Better three hours too soon than a minute too late — William Shakespeare
We were developing a Mobile Application using PCL for shared code. However, this was soon deprecated and we had to switch to the .net standard due to its large access to .net APIs and the best coverage of Base Class Libraries. Since there was no impact on the customer and neither stood a chance in front of the value the immediate Features would bring to the customers, it was difficult to prioritize the Enabler. However, slower build time impacted our productivity and retarded us from creating the Increment. More bothering was the unavailability of new futures and limited support which was very important to tackle customer’s pain points. We presented the right data and with help of RTAs (Release Train Architects) we were successfully able to prioritize and soon we ported from PCL to .net standard 2.0.
Other circumstances where Enablers may be kicked out of the priority list :
a. The upcoming milestone could be achieved without the Enabler.
b. A Specific Feature was already committed to the market and the Enabler couldn’t compensate the value outcome from the Feature.
c. When Enablers are presented as a recommendation but not something that has to be addressed immediately.
d. Not enough data available to support Enabler’s value addition to the product.
e. The cost of development vs The outcome of the Enabler is not matching the expectations.
f. The Enabler is having a high level of technical complexity or external dependency making it difficult to estimate and plan the implementation(A SPIKE may be planned in this case for Analysis)
HOW WE DID IT?
Here are few examples of the Enablers we as a team were successfully able to work on that indeed kept the product updated and also helped us efficiently release without any hassles.
- Updating the library for better performance
We were using a library that had a new version with better support available and soon stops supporting the version our app was using and was crucial for our customers. Since the cost of later finding an alternative, license, and terms of use, feasibility would stop the customers from using the app for several weeks. Thus, we prioritized this and worked on it. The pointing to the latest library did not incur any extra cost, indeed the customers were seen having positive feedback about the experience post switching to a new version. - Updating the development tools to latest version
Since we are developing Mobile Apps using the Xamarin Forms, we did the following :
a. Update the Target version of Android and iOS to the latest versions
b. Updating the mac OS and XCode versions
c. Updating from.PCL to .netcore for sharing code between cross-platform applications with better support.
(Please Note: For few Enablers other than those mentioned above, we either created SPIKES or decided to timebox. In either way, we were very successful in executing them. However, the key here is to document the outcomes and make it transparent to everyone to make the best decisions.)
Without Enablers
I think by now you have a better idea about the contributions of Enablers. Now let us see, how any product may look like without them.
Let us take an example of the Aviation industry. One of the two aspects that play a vital role in safe functioning are :
a. Frequent maintenance — Similar to Enablers
b. The Black box to study the root cause of aftermath — Similar to RCA (Root Cause Analysis)
Both of these are very important to prevent any failures that can cause minor to major incidents incurring a huge loss. The question is can you skip the “Frequent maintenance” i.e. in our case the Enablers and just live with the Black box? A black box is used to understand the root cause of the aftermath and see how to avoid such instances in the future. However, it would be too risky to wait for such incidents to occur and then take corrective actions. The reason is simple, the damage is done already which could have been avoided.
Similarly having frequent maintenance is not just enough. Having frequent and efficient maintenance will reduce the probability of any possible incidents but there can still be cases like the ones we have seen in our real-life about plane crashes. Removing the black box will restrict the team from understanding the cause and taking corrective measures.
Verdict — Enablers are not just a SAFe fad, it is like the thumb on the detonator, everyone is safe till it goes off.
HOW TO PLAN THE ENABLERS ? — THE STRATEGY
While the stakeholders may be busy bringing in new features, as technical experts the Developers should be able to propose the best solution for product. With my experience I have come up with a strategy and I call it “F.I.R.E”
F.I.R.E -> (F — Find, I — Impact, R — Rank, E — Evaluate)
Find: Have a SPIKE story or use fixed blocked capacities to research any Architectural or possible adaptations required for future support.
Hint : Pay close attention to senile areas of the product that can later become a blocker.
Impact Analysis: Prepare an impact analysis with details including how the proposed enabler can positively impact by removing the risks or immediate threats. Any data about cost reduction, removing blockers that could restrict the product delivery, or any immediate risk imposed of not having the Enabler. This will become an important input for our next step which is ranking. Here the team can also consult other teams to get expert feedback about the proposed Enabler. Since PO is the expert who can also decide what is the best for the product, It is that the team involves PO and make this transparent to their feedback.
Ranking: Ranking / Prioritization — In this step, the teams along with PO should collaborate with Architects, refine the Enabler and provide a high-level estimation to make the efforts, the gain transparent, and finally present to stakeholders. Later based on all the details from the team, stakeholder’s input, the PO will prioritize the Enabler.
(Please note: In SAFe, the inputs should be provided in time to ensure the topic can be discussed in PO Sync to discuss Program Backlog Refinement for upcoming PIs. Post which the POs will prioritize and bring the topics based on their priorities)
Evaluate: Post completion of the Enabler, the teams should evaluate the overall execution of the Enabler, inspect closely the learnings they had while implementing the Enabler, the value creation vs what was projected, and any other finding to take the necessary measures for future development.
Endnote
Great things are not accomplished by those who yield to trends and fads and popular opinion — Jack Kerouac
This is why I advise looking before you leap. A scaling framework may seem like a solution to your problems, but they add to the complexity and make Scrum less effective in the end. — Willem-Jan Ageling (source: In His article here)
This article intends to provide clarity on the Enablers, their importance, and their possible way of implementation. All the content in this article is purely based on my practical experience, my learning while acting as a Scrum Master and Team Lead. However, I would again emphasize the above quotes by Jack Kerouac and Willem-Jan Ageling. It is always recommended to check the feasibility of a framework, concept, or solution before directly implementing them.
I hope this article guides you in making your first steps towards the Enablers and helps you and your team develop a sustainable product.
