What makes a project Agile' is adherence to Agile values and principles.
The widely-popular Agile methodology provokes quite many debates upon software quality issues such as: Is it better to release code quickly ... or release clean code? Is bug-free software the goal?
Does Agile mean to poor quality delivery?
As IT leader, what's CIO's strategy and methodology to balance quality and speed; flexibility and discipline; best practice and next practice? And how to apply Agile principles when managing software development or running IT as a whole?
These two concepts (quick release and clean code) are not mutually exclusive. If the development team follows an agile process and leverages the paradigm of Test Drive Development, what a stakeholder sees at the end of a sprint/iteration should be qualified constructed, quickly delivered software. If what is being moved to code complete status in a sprint is true "buggy," then you have a great teaching moment on your hands to sit your agile team down and make sure they all have the same commitment level to the project. So with the right process and rigor, you can have the quality code (no such thing as 100% bug-free code) and have it available quickly for the end users.
The goal is a happy client. If every IT project is a business initiative with clear business goals such as improving customer satisfaction or optimizing business processes, then the goals of software are often described in terms of measures, such measure selection should be based on the nature of project and purpose of the business initiative. Keep in mind the long-term project success will
require maintainability, scalability, etc. and clean code will make the platform more stable than the quick dirty solution so it could potentially save time and headache. Further, if you don't repay the Technical Debt, comes the time when you get more work maintaining bad code than releasing new evolutions. However, is bug-free software the goal? No, it is highly desirable but not the main goal.
Not all problems will achieve maximum benefit from bug-free code. Some problems benefit more from a good solution today rather than a great solution tomorrow. Not all IT departments are staffed properly to be software development houses yet they are often required to do custom software development. If the goal for these departments is to delivering "bug free code" vs. solving a business problem, then you will end up with very long and cost prohibitive software development cycles whose end results is probably just "nearly bug-free" code that no longer meets the business needs because the business has moved on to a new issue with new requirements. If you do have to do custom development, then the goal should be a system that meets the requirements of the business, is delivered when the business needs it and at a cost, the business agrees to, is usable, is elegant, is maintainable, is flexible, is expandable and is integration friendly.
What makes a project Agile' is adherence to Agile values and principles. Achieving bug-free code 100% of the time is unrealistic, but the goal should be to strike a balance between quality code and timely releases. The Agile process, which is often sold as "quicker product release" delivers a code of truly production quality. It clearly can. But too often the process is not used in conjunction with management approaches that deliver on that capability. To apply the paradoxical "Agile" philosophy: Faster release shouldn't compromise customer satisfaction; while high quality also doesn't mean "perfect" or bug-free code; Iterative communication, incremental improvement, and strong engineering/ management discipline are all principles behind Agile. There needs to be a pragmatic way of applying whatever principles to the problem in a CONSISTENT manner
Plan well is a key step in delivering the expected result. Such quality concerns carry a strong indication that the PM is not doing things properly by accurately defining requirements. Requirements and designers should work transparently with the client and IT team to see what can be delivered in the given timeline with the best quality. For big systems, requirements are sometimes vague and even if they are not, the overall development cycle is long so the requirements are prone to become obsolete before the cycle ends. Risk assessment and mitigation is a key attribute for entry and exit gates in each sprint. Bugs aren't usually caused by trying to get the release out too quickly; they are more often caused by poor planning and allowing the scope to creep, trying to do too much without thinking about the consequences of each change or addition.
The other common failing of Agile approaches is to not include management itself as a customer. If you do not include management as a customer (in an Agile process) then requirements like future maintainability, code complexity, "localization" (translation to different markets) and reusability get inadequately low priority. Key considerations are:
-Competitive advantage
-Risk - Brand damage, or loss of revenue
-End User experience - will the end user be frustrated and not come back
-How much rework will be required (incidents on the call center, defect resolution-develop and retest, change management impact, how many redeployments need to be redone)
Bugs can be caused by bad design. But more often than not, they are caused by the simple human error. When you put a team under unreasonable time pressure, the likelihood of error increases. When you have a design that requires a skill level outside the median capabilities of the team, the likelihood of error increases. When you allow teams to be less than rigorous about the processes of construction of complex systems, the likelihood of error increases.
Not every bug is created 'equal'. Known bugs can be fixed, ignored or tolerated; a reasonable set of choices based on the circumstances and impact of the defect. Standard technical bugs (data exceptions, missing function parameters, etc.) are perhaps unavoidable. Serious bugs in APIs or other more sophisticated processing or interactions that serve the business process can only arise due to: incorrect requirements (specification) or the failure of a programmer to properly implement requirements that have been identified as correct. In any case, the level of testing and the rigor of its execution is an engineering consideration that has to be appropriate to the product involved.
Many times IT is struggling with how to strike the right balance between agility with discipline; creativity with governance, flexibility with best practices. IT development is both science and art, the bug-free software may not be the final goal, but the quality is indeed important, and how to delight customer to achieve the business goal is a noble purpose for any successful software project.
Read More about magic "I" in CIOs:
CIO as Chief Imagination Officer
0 comments:
Post a Comment