LegalShield Official

Around the globe, many well-known companies use an Agile approach to streamline their processes, deliver fast, and quickly adapt to market changes. After seeing a success with Agile on a small scale, more companies are scaling Agile at an enterprise level. After a while, several of them have started complaining about the Agile implementation. Here are their story lines:

Everyone in our company underwent the Agile training. The product, business and scrum teams seem to be working closely on the requirements. The Scrum teams are following all of the scrum ceremonies, but they are consistently failing to deliver on their commitments;

“We don’t think Scrum is working for us”.

Here is Ron Jeffries’s quote about Scrum.

“Scrum doesn’t fix your problems. Scrum shows you your problems. You’re supposed to fix the problems”.

Don’t blame it on Scrum. We are the problem. We need to fix ourselves.

Unrealistic timeline?

Most companies today expect that simply implementing Agile will solve all the problems they have. Sometimes the top executives will enforce a timeline and they will ask the teams to go and deliver it. Can they do that? In most cases, if two out of three constraints (scope, cost, schedule) in the “Iron Triangle” can be variable, then it is acceptable. But in many cases, they want to keep more than one constraint as a static variable, which would go against the DNA of software delivery and that’s why we see a failure. But most of the time, that is not the case. Leadership, business, and IT are all in agreement about the timeline, cost, and the scope; but still the scrum teams are struggling to deliver on their commitments. Let’s take a closer look.

 Quality should be built into your entire Agile development process. Built-in quality helps with scaling Agile at an enterprise level successfully 

Scope Creep?

In many Agile projects, I have noticed that estimations coming out of the Program Increment (PI) planning or a Release planning completely take a U-turn during the execution, but the teams still have to meet the timeline, which results in many teams working day and night and weekends to deliver a low-quality product just to meet the release timeline. Is it because of the scope creep? The answer is maybe. Sometimes the business side either gives us bad requirements or completely misses the requirements at the beginning. They always come to you with new requirements towards the end and will tell you that it has to be included in the MVP.  We all know the second principle behind the Agile Manifesto is “Welcome changing requirements, even late in development”. But in reality, it is not going to work without reducing the scope or changing the timeline, especially when planning for a program level incremental delivery. But in many cases, that’s not the real problem.

Lack of quality in Agile development process?

The real problem is the lack of Quality in the work of the Agile teams. Whether it is an intrinsic quality or an extrinsic quality, the quality is a critical piece in the Agile software development.

We need to see quality in the role of the Product Owner in how they gather the requirements, how they write quality user stories, how they groom and prioritize their product backlog, how they define their acceptance criteria, and how they define the goals and create a vision to align with business objectives.

We need to see quality in the role of the Scrum Master in how they promote and support the scrum process, how they manage a good relationship with product owners and the development team to maximize the business value from the scrum team, how they lead and coach the organization in its scrum adoption, and how they remove the impediments for the scrum team to meet the sprint goal.

We need to see quality in the role of the Development Team in how they self-organize when managing their sprint backlog, how they apply the best engineering practices while working on their code, how they fulfill their Say-Do commitments, how they demonstrate their sprint work for quality feedback from the stakeholders, and how they work on the automation testing and CI/CD (Continuous Integration/Continuous Deployment) process.

We need to see quality in the role of the Program Manager in how they manage the risks and dependencies in multiple programs, how they report the program dashboard with forecasting, how they manage continuous integration within feature teams, how they manage deliverable- based planning across all the teams, and how they provide the rolled-up progress at the program level.

Built in Quality

Here is Dr. W. Edwards Deming’s quote from Out of the Crisis about quality.

“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it”

Therefore, quality should be built into your entire Agile development process. Built-in quality helps with scaling Agile at an enterprise level successfully.