An Executive’s Guide to Software Quality in an Agile Organization: A Continuous Improvement Journey

By Navid Nader-Rezvani

Utilize a set of practical guidelines to help your Agile organization elevate software design quality as an important business driver to achieve customer satisfaction and, ultimately, higher revenue for your company. This is the first book to focus on a holistic quality view—what it is and how it links to overall business enhancements.

The real-world examples used in this book allow you to learn and apply similar strategies and guidelines to help create a quality blueprint for your organization. Five pillars of quality are defined that can be used for any industry and, once internalized, can serve as a set of tools to continuously improve and measure the key factors impacting quality.

What You’ll Learn

• Be aware of the key elements in any transformation that involves culture
• Link quality and business outcomes
• Understand quality and its holistic definition and why continuous improvement is still a relevant approach in enhancing quality
• Follow guidelines with specific examples that can be applied to any product release in any type of industry to improve quality and enhance Agile processes
• Utilize relevant metrics to measure and continuously improve to make incremental positive changes

Who This Book Is For

Individuals at various levels in organizations—from Agile scrum teams, all the way up to executive leadership

• Language: English
• Publisher: Apress
• Release date: Aug 16, 2018
• ISBN: 9781484237519

Book preview

© CA 2019

Navid Nader-RezvaniAn Executive’s Guide to Software Quality in an Agile Organizationhttps://doi.org/10.1007/978-1-4842-3751-9_1

1. Quality in Agile

How the Two Fit Together

Navid Nader-Rezvani¹ 

(1)

Los Altos, California, USA

I don’t want to sound like Agile is the answer to all our problems in releasing software with high quality. After all, for many years companies had released software, sent human beings to the moon, built aircraft, and achieved many more accomplishments via a waterfall software development lifecycle (SDLC) process . However, with the fast evolution of technology, we have no choice but to adopt Agile and deliver high-quality, incremental value faster.

Taking a moment to understand what problem Agile really solves will help navigate and ground leaders who may think Agile is the silver bullet to resolve their quality problems. A lot of people who are first introduced to Agile think that it helps them deliver product to market faster. That is actually not the objective of Agile! In fact, one can argue that Agile will slow down the ultimate time to market and introduce overhead that is certainly well worth the gain. But this is not what most people expect.

Agile allows for the delivery of an accurate solution to the market. Keep in mind that engaging customers along the way will enable teams to react and adapt to the needs of those customers. With more iterations, you have the opportunity to put smaller pieces of functionality out in the market and thus receive feedback more quickly. However, delivering a full solution compared to the old SDLC process could be slower. I think you will all agree that while speed is important, there is no point to being fast in delivering a useless solution to customers!

The focus of this book is mostly on the transformation and quality-improvement journey that has dependencies on the culture of the organization, the technology that they deliver, and their customers’ appetite for the right level of agility. Culture does not change overnight. It is a reflection of the employees and the company as a whole. Leaders should enable teams and create an environment for the culture to grow. Inclusivity and consistency will be very important in transforming the culture. Everyone in the organization should be involved in continuous evolution and transformation, especially the people who are closer to the customers.

Pure Agile may only exist in an academic world. In the real world, it is all about continuous motion and transformation to help influence many years of legacy practices and ways of thinking around quality and customer expectations. Adopting practices that will allow organizations to continuously deliver value to customers should be considered a key priority when organizations decide to embark on this quality journey. Initially, such practices may not align exactly with the mature Agile practices. But, over time, the team will evolve and get better.

As an example, Agile purists may not support hardening sprints or separate level 2 sustaining teams. They may even cringe when they learn about organizations that have set aside planned time for hardening or have a separate level 2 sustaining team. The reality is that, unless you have experienced Agile teams, full automation, no legacy code, and no certification requirements, you may need hardening and level 2 sustaining support. Organizations just starting Agile will need more time to focus on key areas such as automation that will help them improve their processes over time. I always advise teams to be patient with themselves while embarking on their Agile quality journey and learn how to crawl before they walk.

The biggest benefit of using Agile is to deliver value to customers faster. Breaking complex problems into smaller pieces is one powerful technique that will help in doing so. This process needs to be fully adopted and accepted at all levels of the organization for it to be effective. If the leaders are skeptical about the value Agile brings to their organization and are not true believers, it is almost guaranteed that the product teams will not be successful. In the Agile quality transformation, the leaders’ commitment to quality and continuous improvement is critical and cannot be delegated. After all, as they say, a change will go no further than the mindset of the leaders who lead it.

Another challenge in implementing Agile is when one function in the company has adopted Agile, but the rest are still functioning in a waterfall manner. For example, if the engineering teams have made the shift, but sales, education, and support haven’t bought into the Agile practices, friction develops, which will lead to failure in delivering value to the customers.

A key principle in Agile is working as a team. Agile is a team sport, and collaboration is not negotiable. A few years ago, my boys attended Michael Jordan’s basketball camp. One of the enduring lessons they learned is the importance of collaboration and teamwork. They learned that while talent alone may win a game, teamwork and intelligence are key to winning a championship!

Why am I talking about Agile when the focus of this book is product quality? Although quality is all about building things right, understanding how to build the right thing has a significant influence on the customers’ perception of quality. Also, quality is a foundational element in Agile. Leveraging various frameworks that will lead organizations through this important and difficult journey will allow companies to stay competitive and operate in a constantly changing world.

Building the right thing can be made easier when you have a strong culture of quality and an Agile mindset, as well as a process framework that leads to delivering incremental value. I have been brought into multiple organizations to address their quality challenges when the first dilemma for the executive team is why their product quality still suffers after going Agile. By going Agile they usually mean investing time and money in delivering Agile training and adopting Agile ceremonies. They sometimes overlook the need for executives to focus on creating an environment where teams can thrive. This is where I usually start, diving deeper into their Agile implementation and focusing on Quality Integral Mapping, which I will cover in the next chapter, to help analyze such situations.

The most important part of Agile is to work iteratively by collaborating and achieving incremental value. Many organizations that call themselves Agile, focus more on the Agile ceremonies and assume that by following such processes they are automatically ready to deliver software faster and with higher quality. Often the required tools and framework—and, most important, the right quality mindset—are ignored. Usually that is because the investment required for developing people, processes, and tooling does not get considered as part of the overall