Is Agile the Cause for Defect Increase

Agile is a natural transformation in software development processes, to adapt to rapidly changes; Agile is an emerging methodology with many advantages such as faster release cycle, iterative communication, more end customer focus. It's the right way to do software or run business strategically, methodologically and tactically. However, as a new practice in many organizations, it also causes further concerns: Is Agile the cause for defect increase? Does Agile make most of customers more satisfied? Does Agile improve project success rate? What’re pitfalls to adopt Agile? etc. 

1. Should Agile take Responsibility for the Defect Increase?

Agile as emerging methodology to adapt to over-complex business environment, it’s understandable if it causes confusion as many organizations just start experiment it; and every progress is accompanied with some setback. Still there is validity to the argument that anytime when increasing the number of platforms, browsers, etc. that an application must operate on, organizations are naturally increasing the complexity of what have to be tested and thus would expect the overall defect count to increase.

• Every defect count, but not every defect is created equal.  An Agile project may have many more minor defects because of the speed and smaller / more frequent releases; whereas a more traditional waterfall based project will have significantly more critical defects because of the lack of feedback loop to the end users. And furthermore, if you have critical defects - you may never get to identifying or fixing any of the minor ones; as the project could be killed off before you ever get to that point. Besides defect rate, also review criticality of defect. 

• Many organizations are still at learning curve on how to build software via Agile methodology, and face the challenges such as lack of the right talent, effective process, or solid management support. etc. In worse case, Agile has been abused beyond recognition and is responsible for a substantial chunk of it. Some users haven’t had clear idea what they are doing, in fact that is often the key motivator for adopting something "chaos" and calling it agile. Agile doesn't mean chaos, it need standardization, structure and right set of guideline for teams to follow, maximizing the choices when collecting requirement, but minimum the risk when executing it.  

• Further investigations are needed when defect increase:  One should look at the root cause of failure. Without understanding the root cause an organization will continue going in circles  Is the problem merely that development projects are not getting the time needed to develop and test properly? Are QA teams being cut? Are developers less educated and experienced? Are companies letting experiences developers go in favor of junior people? Are the tools and processes being passed over and ignored? Have time pressures and release dates gotten cut too short? Has Agile blown up in  faces and shortened time and needed effort too much? Has it become too costly to fix bugs before release and less costly later? Have the product cycles and release cycles gotten too quick? Has most software gotten too complex where it needs to operate on too many types of devices? Most of the problems come from poor processes, unreasonable project time, poor quality methods, exponential growth of complexities, and a significant rise in operating system revisions and updates.

2. Agile Success takes Both Engineering Discipline & Management Practices

 The growing complexities do mean the skills of teams - Dev and QA - are challenged, the process, method and management practice should continue to be retooled, to reduce friction -culture inertia, mis-management.

Defect increase could also be the fact that the eco system is getting more complex with higher level of integration and inter dependencies

• Well set of Standards: In order for any solution to be successful, good methodology must be followed and that includes ensuring the company has development standards in place, those standards are checked for compliance and testing services to catch what the developers did not. Underlying to all of this is having a good quality management system in place that outlines key processes, checkpoints and a desire to prevent vs. react when something breaks. It doesn't matter on which continent one develops or tests, if the methodology is followed, right skill sets are attained and right processes to include proper testing are in place, things will run smoother (just to name a few factors.     
      
• The Planning & the Requirement Process: Work without plan is planning to fail, good preplanned methods for handling defects, prioritizing work, with proactive mode. The requirements process, if done properly, encourages thought beyond the 'happy path'. The exceptions are uncovered; the risks are identified and mitigated. The whole point is to get it right the first time. Rework can cost as much as 100 times the cost. 

• Agile requires high-performing team with well-mixed skills to balance value/cost/risk: The purpose of Agile/Scrum is to manage software projects with value, speed, adapt to changes and better customer satisfaction, it requires the team with well-mixed skill-set, having effective communication with both cross-functional team members and end customers, using 60/40/20 rules to prioritize the tasks can also be a good practice, let team focus on the most critical 60% deliverable first, another 40% is good to have, and the last 20% is stretch out goal. Do further study on Team performance such as:  

          --Face to face team vs. virtual team (Communication Matters)
          --Compare the teams use different tools (Technology Matters)
          --Agile vs. Waterfall vs. DevOp (Process Matters)
          --Team A vs. Team B (Talent Matter: How to build up a high performance deevelopment team) 

Thus, a well thought out process that leverages many of Agile's principles can be successful and many are. So, bottom line, don't whitewash the findings by simply saying that agile is not being properly followed and that explains all the results. It may be true in some instances, but certainly not all.

3. Balance the Best of Both Worlds (Agile & Waterfall)

The key is to have a balanced approach between the feedback found in an iterative approach and the formalism found in a more waterfall approach. 

• Best of both worlds: Do a waterfall type analysis and design, initially, but then switch to something like Test Driven Development as an production method and then Feature Driven Development as a feeder for the implementation methodology. It gives you an overview of the complete project, but allows you to develop and implement with constant feedback based on the requirements of the users. It allows team to gain insight into the large picture with up front analysis and design while permitting incremental changes during the development and implementation phases. The team can deliver complete, but focused functionality which comprises a small part of the whole. It seems to keep the business engaged and responsive while at the same time it gives the BA/QA team a better handle on the project as well.

• Key approaches to be acted, in order to address the above concern areas:  

1) Adoption of the System Engineering/ Architecture approach to minimize requirement gaps & to eliminate solution gaps. Solution workshops are to be conducted with all stakeholders (Business, Marketing, Operations, IT etc) at all the right Quality gates, to ensure congruence in Requirements gathering & Solution.

2) Change Control & Risk Management have to be strictly enforced, in order to control & manage scope creep. Major changes/ Last minute changes have to be taken to some kind of a review board, specially for larger/ transformational projects.

3). Executive sponsorship has to be strong, so is employee buy-in to the new system, specially in larger Transformation projects. A strong Governance mechanism has to be set up to monitor the project and provide timely support to the Project Manager/ Project stakeholders in case of conflicts or in case of escalations, and resource allocation from the client during the different phases to act as Subject Matter Experts, and Guardians of their own business rules.

• Good Practice of the hybrid model to combine Waterfall’s structure with Agile’s flexibility, some call it: “WaterScrum Fall model”: Well blend beauty of Agile (adaptability) with legacy of Waterfall (structure) to improve effectiveness of SW development. Agile's characteristics such as incremental-ism, iteration (cascade), improvement, better fit for today's accelerated change, it also requires talent's mindset shift, engineers need become true customer champions, to design/test the code which will truly delight end users

Agile is like a wheel, a symbol of progress at software development area, to make it move smoothly, through the right pace to touch the ground. Agile requires good engineering disciplines. It also requires some business disciplines. Agile has to be continually tweaked for it to work. Furthermore, for Agile SWLC, change management need go with Agile hand-in-hand, with senior leadership support, cross-functional communication, and clear vision of project. The goal is not about eliminating all defects, but about improving overall project quality and customer satisfaction. And Agile is more than a software development methodology; it’s mindset to run business.

Posted in: Agile,Keywords in 21st Century,Project Management