Background
One of the salient feature of Agile development is the emphasis on quality software. The quality can be measured in various forms. But the most oblivious ones are the visible indicators like the time to market, number of bugs per iteration or release. These are the aspects that are related to delivering the product or the functionality to the customer. There is also another aspect related to the software craftsmanship which is the quality of the code that is being developed. Agile tries to manage the balance between the two. There are occasions when quality is bound to get lower due to various factors. Lets look at some of the factors which help in building the quality into Agile projects.
Different Factors which impact software quality
The working software at the end of the iteration is one of the best measure which helps to gauge the quality of the deliverable. The customer has a chance to look at the potentially shippable product and can accept or reject the features. The early feedback helps the development team to rectify any errors as early as possible.
Assuming that there are enough software matrices in place the quality of the code can also be validated by means of code coverage and unit tests. Also the automated functional tests can help the product owner or their representatives to help the development team with examples which simulate the real life data. All these things combined together can act as a wonderful suite of regression tests which can be run as part of the automated build.
In order for these things to run smoothly its of paramount importance that every building block of the team functions as expected. But contrary to all the books and article that we read over the internet the truth is that it rarely happens that way. In almost every software project you have ups and downs no matter which project methodology you are using. Fortunately beauty of Lean and Agile projects is that it allows us to inspect and adapt to the changing needs.
Assume a situation where development team is ahead of the business analysts team. There is a situation where during a particular iteration there are less user stories to develop because the business analysts are still writing the stories and development team has finished almost all their tasks. And during the subsequent iteration there are so many stories to finish that development team does not have enough resources to complete the task in time. In an ideal world you would expect the business analysts to be ready with a set of user stories ready for development and development team developing them. Because iterations are time boxed in nature, it can be a tight call sometimes when the deadline approaches and there are many things still to be delivered. It’s a tough call to make. Whether to drop certain features or to deliver all the features but with reduced quality. This is the call which the stakeholders need to take.
It’s a choice between getting a quality product with less number of features. Or knowing that the quality of the product might not be very good but all the features will be there for the showcase or demo or whatever terminology is used to demonstrate the working software to the end user. When we try to squeeze in time and deliver more features, more than the normal capacity of the team, the whole balance shifts. This was summarized very well by Jesse Fewell in one of the trainings that I attended where he said “You have night outs and long weekends, angry spouses, shorter testing cycles, unstable product and possibly a failed appraisal”.
This is bound to have negative impact on technical debt as well. In order to complete the job at hand in a shorter span of time people are bound to take shortcuts. This can lead into duplicated code being written and code smells start to appear. In the long run it can make it very difficult to make changes to the system. Instead of achieving the goal of delivering more features we might end up with more number of bugs. In an attempt to increase the quantity of deliverable we end up sacrificing the quality of the product. In worst case you might end up spending more time fixing bugs which result out of these faster developed features and delaying the overall release cycle.
I personally feel that the quality needs to be built right into the product. It can never be done afterwards. Many project managers and scrum masters take the risk of delivering more features to meet the deadlines and sometimes to meet the numbers which the higher management looks at. It can serve the short term goals. But think of it over a longer duration. Assume that this scenario continues for 3 or 4 iterations of two weeks each and you have two months of development over. All of a sudden you realize that integrating a new features takes almost a month because of various interdependencies and complexities that have raised due taking shortcuts.
If you think from a customer point of view and what is that they would like. In situation one you have a delay of one week because you did not compromise on the quality of product by delivering less number of features but whatever you deliver was all Done Done. Or situation two where you delivered everything the customer asked for but at the end not even one feature was completely Done and had to be reworked for the next iteration to get to the stage of Done. You can answer for yourself in which situation the customer will be more happy.
Conclusion
Isn’t Agile all about delivering value to the customers? I fail to understand many a times why do people violate this very basic principle of Agile that we need to deliver quality software. If we deliver quality software at the end of every iteration the quantity of what gets delivered will take care of itself. All the numbers in terms of velocity etc will also fall in place over a period of time. It might take time initially to get to a point of stability. But it enhances your chances of maintaining a sustainable pace and giving the stakeholders a confidence that on an average X number of story points will be delivered consistently. If a team is not able to maintain a sustainable pace it becomes difficult to gauge when the development of a particular product will be done. In my opinion after some time customers hardly remember how long you took to build a product but they will always remember how well you built it. As software craftsmen we should make it easier for customers to make changes to their systems. And for that to happen we have to build quality into the product right from day one. You can never built quality as an after thought.
No comments:
Post a Comment