Continuous Improvement in Software Development

Continuous Improvement in Software Development The above principle concerns the close, daily collaboration between business people and customers is an important one for Agile as it ensures the usability of the product and consequently quality of work to fulfil the customers requirement in the best way possible (Cohn, 2005). The principle reflects the agile value of customer collaboration over contract negotiation. Schwaber (2004) highlights the importance of this principle as during the last decades with the increasing complexity of IT project, developers and customers have been drifting apart due to unsuitable methodologies that obstruct effective customer collaboration. Requirement collection following this agile principle goes beyond the requirement collection of traditional project management methodologies (Cobb, 2011). Beck (2000) suggests that when using XP, there should always be a customer on site to be able to answer all arising questions instantaneously. Customers often have different or no expectations from a project which emphasizes the need of close collaboration to detect any discrepancies (Cohn, 2005). Cohn (2005) further argues that through daily meetings changing requirements originating in rapidly evolving business environment can be addressed immediately and realignment of the strategy and deliverables is possible. However, the practice of daily customer meetings was not achievable during the wiki project; nonetheless, the team was able to consult with the customer frequently through email and very short response times allowed areas of unclarity to be resolved promptly. This close collaboration was often used to clarify small details in the requirements to increase the customer satisfaction through implementing change request without delay. When this principle is applied cautiously and thoroughly, a high level of trust can be developed between the two parties involved (Schwaber, 2004). Highsmith (2009) further argues that trust is a very important issue to be valued as it enhances the team cohesion and quality of collaborative work. This is supported by the experienced Group Green has made during the wiki project. During iteration 1 and 2, all requirements have been comprehensively discussed and clarified within the team and with the customer during iteration planning and initial customer consultation. After the team has started developing the iterations product, the customer was consulted again to resolve any remaining unclarities. Through this practice of close collaboration the quality of the product was at a very high level which was reflected through the outstanding feedback from the customer. However, during iteration 3 this high level of cooperation with the customer was neglected by the team which was been reflected in the iteration review meeting. The customer was not as satisfied with the product as in the previous two iterations, because the team failed to fulfill the customers requirements and specifications. In the subsequent iteration it was the Scrum Masters top priority to involve the customer again in more detail to enhance communication and idea exchange, removing impediment between the customer and the development team as suggested by Schwaber (2004). To adhere and to apply this principle might be one of the most valuable lessons learned in this project, as the close collaboration ensures a high quality of work and subsequently high customer satisfaction. The principle of sustainable development relates to the aim of developing the product in a constant pace without any perks in development velocity. Sustainability has a great significance, as the whole process of agile development is aimed to be a sustainable approach (Augustine, 2005). Poppendieck and Poppendieck (2003) note that companies which have adopted lean thinking have achieved a significant sustainable performance improvement. Stellman and Greene (2014) highlight that the breaking down of the whole project into smaller more manageable chunks facilitates the process of determining realistic durations of every story point or piece of work that is to be developed. The ability of estimating realistic durations enables the project team to give accurate predictions of the development time of the whole product. This supports a very steady flow of product development and the team can work in a constant and sustainable pace (Cohn, 2005). In software development, this constant flow leads to a higher quality of code and fewer inconsistencies in the source code. In consequence, less time is needed to address bug fixing, which make the whole concept more sustainable and viable (Cohn, 2005). Bug fixing, improving flaws and making corrections often lead to a higher work load for the project team and consequently lowers the motivation and increases the stress the team experiences. The stress primarily results from the still existing deadline at the end of the short iteration which still needs to be met, despite the amount of required re-work. Cohn (2005) further stipulates that over time, the customer realises and acknowledges the high quality, which subsequently enables trust to be developed between the customer and the project team. Cobb (2011) further points out that all team members, not just developers, need to keep pace with each other throughout the whole duration of the project. In agile development, the iterations prevent team members to step in or out of the project in different phases. As a result, the development of the product is much more fluent, as all team member can built up trust and develop a high team cohesion (Cobb, 2011). Cohn (2005) further argues that this can lead to a higher motivation for the project team as they feel empowered and are more willing to achieve better results. Whitworth and Biddle (2007) conclude that agile planning reduces tensions and conflicts and the consecutive development of small tasks promotes motivation in the team, which altogether which leads to an overall quality improvement. In practice, Team Green has experienced the value of this principle, however, not in as much detail as in real-life practice. The project was already divided into weekly iterations, which established the grounds of sustainable development. However, the team experienced the value of dividing the whole project deliverables into smaller parts as this practice greatly improves transparency and clearness of what requirements need to be fulfilled and how this can be achieved. The internally agreed deadlines did not drastically change during the whole project duration. This way the team was able to realise a routine of weekly development, which greatly helped and supported in developing a high-quality product. Trust among the team has been developed at the same time, which facilitated the sustainable development. An important lesson learned in this regard is the necessity of splitting the workload and thoroughly planning durations of the single pieces of work. This greatly benefits a sustainable, constant pace of development and consequently increases the product quality and customer satisfaction. The last agile principle states that the team should regularly reflect on how to become more effective and adopt their work processes accordingly. Through the alignment of the overall approach and the strategy of development, the project team aims to increase the quality baseline of the developed work. Stellman and Greene (2014) note that it is important to include retrospectives to evaluate and assess performance to figure out ways on how to become more effective in future projects. This retrospective should not be limited to one meeting at the end of a project but should be implemented immediately when any possible improvements are recognised. According to Beck (2000) the project team should use daily stand up meetings to get discuss any areas of general development improvement. If this is not possible, the team should try to incorporate a retrospective at least after finishing every iteration (Smith and Upton, 2015). Cobb (2011) elaborates on this in saying that sprints in agile a re generally much shorter than the development duration of traditional approaches, which facilitates the reflecting process. The concept of continuous improvement is linked to lean software development and based on the Kaizen philosophy and re-engineering approach to heighten the standard of status quo to achieve better quality products (Bond, 1999). Kaizen and re-engineering philosophy were originally deduced from operational management in logistics, but can be applied to other improvement processes such as Agile product development. Typically, the improvement process can be divided into four consecutive stages: 1. maintaining process status quo 2. process improvement 3. process re-engineering 4. achieving process stability. Group Green applied this principle during most of the wiki project. In the first two iterations, the team held one retrospective at the end of each iteration to identify areas of improvement and ways to implement more agile principles than the ones that were already used. This practice lead to a high quality of product and customer satisfaction. However, during iteration 3 this principle was neglected and the team did not pursue the strive of further improvement. This was reflected in reduced customer satisfaction in comparison to the previous iterations. In response, the team decided to add an additional retrospective reflect on how to further improve their development process to retrieve the higher quality standard and customer satisfaction of previous iterations. Based on this positive experience of reinforcing this principle it was agreed that an additional retrospective is being held at the end of the wiki project to ensure a high quality of final assignment report. Reflecting t he whole development process, it can be said with certainty that lessons learned includes the necessity of consequently applying this principle. Only by doing so, the prerequisite is fulfilled to continuously deliver high quality products and achiever customer satisfaction.