Scrum Software Flexibility and Refactoring

By Mark C. Layton

Scrum works well with software for a variety of reasons. The cost of fixing defects increases exponentially the later they’re found. Catch them early and fixing is a hassle, but doable. Catch them later and the accumulated technical debt can be costly.

Building in quality every step of the way to reduce and eliminate defects is a scrum advantage. Although testing each and every requirement and its integration with others is integral to the process, mistakes still happen.

Software can be very flexible. Although it’s not free to have a developer refactor code, the physical impact is virtual, so in many cases it can be done with relative ease.

Refactoring code is the process of changing the existing code without changing its outward behavior to improve nonfunctional aspects of the system.

Refactoring is inevitable in scrum (in a good way), and you’ll do more of it than ever before, because you’re responding to and embracing change. Fortunately, scrum’s empirical approach disciplines teams to continuously inspect and adapt to improve the health and quality of their product. Identifying needs for technical improvements and prioritizing them against new development are part of this ongoing maintenance.

Refactoring code is like maintaining your car. You hear the rattle, notice the little red light come on, or smell something electrical. You know if you don’t do something, those problems are going to get bigger. You can pretend you have a choice, but you really don’t. So, like with refactoring code, you take the little steps necessary to make sure that your vehicle is running smoothly. Maybe you just need more oil or a bolt tightened. But if you wait, your engine could seize or a part could break, leading to much higher expense and time wasted.

With scrum and software, refactoring allows you to make a working module that is scalable, extensible, and stable. In today’s world of The One Who’s First Wins, this type of efficiency in quality control is priceless. Refactor early. Refactor often.

Release often and on demand

Deploying new products to the market no longer requires packaging and shipping. Thanks to the Internet, the cloud, automated testing, and continuous integration, you have the flexibility to plan your releases on demand and as often as needed to suit other factors, like market readiness, customer expectations, and marketing campaigns.

You now have a much higher degree of flexibility in the product that you create and the timing in which you release it to your customer. Money previously allocated to hard-copy product is now diverted to more pressing and profiting needs. The Download Here button makes life easier in so many ways, and in many cases such as SaaS (Software as a Service), updates are pushed out automatically, even eliminating this step.

Behemoth tech companies like Facebook, Amazon, and Google deploy code to production multiple times a day. In the case of Amazon, it’s 3,000 times a day. Now that’s fast!

With scrum’s emphasis on producing “shippable” product after every sprint — or even within sprints — you now have even more flexibility in planning product releases. You don’t have to wait until the end of a project to release. You can do it incrementally in stages and continuously, with tested, integrated, and approved functionality.

Customize your release sizes

No matter how often you release, smaller is generally better. Similar to the flexibility of releasing often and on demand, the size of product that you release is now incredibly flexible with scrum, based on functionality, target dates, and market conditions. Is it one tiny requirement that rounds out a larger previously released one? Or is it a granddaddy new generation that’s about to be birthed?

From a single line of code to a full bundle of functionality, it’s all been through the same thorough process. Quality is the essence of flexibility — and it’s the essence of scrum.

Inspect and adapt as you release

With the ability to customize both the timing and size of your releases, you’re also able to receive immediate customer feedback. Each time that you release product, you’re able to assess the results and make any necessary changes. Both analytics and customer service are able to collect data quickly, and from this input, you fine‐]tune future development and enhancements.

With scrum, you inspect and adapt daily, after each sprint and after every release. And as you’ve discovered, these can happen as often as you like and will suit your project. In fact, the more you release, the more you can inspect and adapt.

You can even tailor the quantity and focus of feedback. Smaller releases might have more targeted feedback. Larger releases might receive broader evaluation, and from this, smaller targeted future releases can be set.

The sprint retrospective idea of inspecting and adapting your process works here too. You adapt your process at every iteration rather than only once in one sweltering meeting at the end of the project when everyone’s just relieved that it’s over and ready to start on different projects.

The point is, in this world, the customer has a lot to choose from, and new products hit the market every day. To survive and excel, you must be at least as nimble as and certainly faster than the next guy. Scrum provides the framework for just this.