Time is a powerful constraint.
It forces us to define what matters most, make choices of priorities, and leave behind less valuable activities.
Time becomes a more powerful constraint with the acceleration of the digital competition and innovation with organizations requiring Quality at Speed software to change on time.
But the acceleration of software delivery also increases its debt, leaving organizations with the choice of balancing the addition of features or implementing refactoring.
This article presents the Quality Engineering methodology of Time-boxed Refactoring and how it can help to perform refactoring efforts in just-in-time.
Follow the QE Unit for more Quality Engineering from the community.
What is Time-Boxed Refactoring?
Refactoring in software is the act of improving how the software is made to better answer non-functional requirements like maintainability or readability.
It is important to clarify that refactoring is not:
- Pre-optimization: it is about improving the existing how
- Perfection: it’s about making better but not perfect
- New requirements: adding a security layer is not refactoring.
It is a practice that was largely shared and supported in eXtreme Programming (XP) and the more recent advent of Software Craftsmanship.
As engineers, we usually like to improve things. But organizations with the pressure of digital transformation have limited time and require continuous iterations of value delivery.
Refactoring questions are usually:
- What to refactor?
- When to refactor?
- At what cost? (i.e. time, resources).
We can apply a selection technique more natural than performing a complex prioritization exercise at each software iteration: Time-Boxed Refactoring.
Time-boxing activities is a known practice that constrains to maximize the value delivered in a defined timeframe, avoiding tasks to take the available time to complete.
Time-boxed refactoring consists in ensuring a systematic, yet limited time is allocated for refactoring software changes during their implementation to prioritize by value.
Its implementation enables to maximize quality and speed in software delivery, taking a seat in the practices making Quality Engineering.
Why use Time-Boxed Refactoring in Quality Engineering?
Quality Engineering is the paradigm constraining the end-to-end software lifecycle to continuously deliver Quality at Speed software.
Its implementation relies on a systemic approach to software delivery in the five domains of MAMOS: Methods, Architecture, Management, Organization & Skills.
Time-boxed Refactoring is a methodology that forces to deliver the most valuable refactoring within resource constraints to limit more costly reworks afterward.
How does Time-Boxed Refactoring contribute to Quality?
Delivering quality requires to align multiple stakeholders on the most valuable quality attributes to implement during iterations where time is limited.
The first implementation of quality attributes is rarely satisfactory the first time. That’s normal in a creative activity such as software full of complexity and uncertainty.
From a first experience, the team identifies improvements that can better answer the stated requirements of todays, enabling to much easier change the code afterward.
Time-Boxed Refactoring contributes to Quality being:
- Results-driven focusing the team on most valuable increments
- Systematic in its application to every change and supported by DoD
- Scalable in the organization, type of changes and for more complex products.
How does Time-Boxed Refactoring contribute to Speed?
Digital organizations are searching for speed in different ways. They want results in the short-term but also sustain a continuous force of transformation.
Speed in Quality Engineering requires to balance value delivery at these different time-horizons to support the reinvention of companies in the marketplace.
Organizations able to adapt software with just-in-time improvements focus on minimal changes that reduce debt at a minimal cost, allowing to keep an iteration speed.
Time-Boxed Refactoring contribute to Speed with:
- Focus in constraining most valuable refactoring with time-box
- Rhythm being systematically applicable in the week or during sprints
- Visibility in identifying and sharing improvements across the organization.
How to start with Time-Boxed Refactoring in QE?
Time-Boxed Refactoring should be applied in a few teams to develop an organizational maturity that can be deployed more broadly afterward.
The following principles must be shared for effective TBR:
- Refactoring improves the existing how
- Collaboratively prioritize on value
- Demonstrate & share value
- Stop when the time-box is complete.
The following steps then let you implement Time-Boxed Refactoring:
- Share the vision and principles
- Identify the most valuable team
- Collaboratively define the scope
- Implement time-box refactoring
- Clean tasks and update the backlog.
Share the vision and principles
Different actors will have a different vision about the need, the how and the what of refactoring.
It is necessary to align the vision of what is Time-boxed refactoring for the impacted stakeholders to create a shared basis of collaboration.
Use the content available in the definition, Quality and Speed contributions, and principles to craft a presentation containing concrete examples in your context.
Ideally, you should have a recent case where not performing refactoring or performing too much refactoring led to concrete business problems.
Using these cases will improve the power of your message and enable you to identify which team would be more suitable for starting with the practice.
Identify the most valuable team
The most valuable team to start with must balance a set of individuals that work on sufficiently valuable software components.
It is better to start by identifying which software product increments would be more adequate in terms of business value, limiting the risks taken.
The team can then be arranged, even adapted, with motivated and open individuals able to iterate on the new methodology, make it better and then share it across the organization.
Collaboratively define the scope
Which refactoring to perform, and their relative importance vary between individuals. And sharing enables to generate and enrich ideas.
That’s why it is important to collaboratively work on defining the refactoring scope to improve the performance and impact of the methodology.
You can identify the scope in a workshop involving the key stakeholders necessary, don’t forget actors that are not coding the product.
It’s not about justification and lack of trust for the software engineering teams. Making explicit what we want to do is essential to clarity, value and prioritize better in time-box.
Implement time-box refactoring
The scope of refactoring defined, the team can now plan and implement the identified refactoring.
It is critical at that stage sticking to the defined time-box to guarantee the effectiveness of the methodology.
The first iteration may lack time or results, but let the team learn and improve the methodology from that experience rather than adding extra time.
Strictly maintaining this timing is essential to keep alive the force of Quality Engineering alive in your software lifecycle.
Clean tasks and update the backlog
Once refactoring has been done, cleaning the house enables to continue future iterations with a clear mind and minimal debt.
Items not completed must be assessed to define if they should be deleted or moved to the backlog.
Make sure to mark the backlog item with an indicator of how many iterations were checked for planning.
If for 3 to 5 times the item is not moving forward, it is one of the less valuable increments you should not care about.
In the meantime, your iterations have changed the software and more valuable just-in-time refactoring is already happening.
Time-boxed Refactoring within Quality Engineering
Refactoring is a practice that continuously performed makes the difference in delivering Quality at Speed software.
Larger improvements in the Quality Engineering ecosystem are helping to be right the first time, but coding is still a craft requiring continuous improvements.
Time-boxing activities are not only reserved to refactoring. OKRs is an example of another methodology using the same constraint for setting priorities.
Time has been and continues to be one of our scarcest resources we have to effectively use to succeed in transforming our organizations in just-in-time.
What’s your next time-box refactoring?
References
Martin Fowler, Refactoring, MartinFowler.com.
Martin Fowler, Kent Beck (2018), Refactoring: Improving the Design of Existing Code. Thoughtworks.
Emily Bache, Turning an example by Martin Fowler into a Refactoring Kata. Eficode.