Enhanced Quality And Productivity

Introduction

The software development process has become paramount in the world of technology and matters most to young developers. The same case applies to the company in Ocean Island that carries over 150 software developers engaged in building the business information systems. Within the company, the CIO demands whether the Kanban software development methods can be applied in the due course as one way of enhancing the quality of software produced. Kanban can simply be described as the method used in managing creation of different products with a close emphasis on the continuous delivery without overburdening or bothering the development team. It behaves the same way as Scrum while helping teams to work together in a more effective way. Kanban operates under three basic principles, which include visualizing what is to be done, or the workflow, limited work in process as well as enhancing flow. The preliminary driving concepts behind Kanban are said to have been developed by Toyota immediately after the Second World War. The company was quite desperate in competing with Western companies citing the economic downturn. A refocus on Kanban made the company to understand the essence of eliminating waste, optimizing the flow, significant approach to collaboration, leadership and teamwork, and finally, making use of a defined process that has distinct steps. Before recommending the method to the CIO, the report will first explore the Kanban software development methods, assess the methods in terms of team communication and collaboration, assess the methods in terms of software productivity, and lastly, recommend the best method depending on the discussion on strengths and weaknesses.

Kanban software development methods

Kanban software development methods, referred to as Kanban methodology, are simply an agile methodology that is never necessarily iterative. Notably, processes such as scrum are known for bearing short iterations that mimic the project lifecycle based on small scale while bearing distinct beginning as well as an end for iteration (Sommerville 2015). Apparently, Kanban paves way for the software to be developed in a single large development cycle. Kanban in software development takes advantage of the stages in Software Development Lifecycle (SDLC) to reflect the stages of development process. The central purpose of Kanban is to control as well as manage a flow of features that allows the process to reflect the completed features. Kanban is essentially regarded as an agile methodology based on the fact that it satisfies the twelve principles of the Agile manifesto. However, Kanban can still be agile and incremental at the same time. A simple reflection of Kanban can be represented as shown below.

Under visualization of the workflow, Kanban works besides the sticky notes and the visual board with every card giving a representation of the task. The idea behind this includes visualization of the workflow while fostering minimal marketable features. Again, this encourages transparency as well as visibility of the work. Kanban also plays a key role in terms of making the process policies more explicit, which helps organizations to comprehend as well as make right adjustments to the processes. This further works in favour of the work policies that can be tailored to meet both the development and managerial need. The profound call for the use of Kanban in software development has also captured the business information system application. This is because Kanban is universal and can equally find place in ecommerce and the IT sector (Anderson 2010). The tool is said to have been nurtured to manage as well as schedule all work in progress as IT conforms to the changing business demands. Some of the characteristics of Kanban are that it is event-based and bears an advantaged beyond the application of the time-boxed systems. In business, the Kanban board serves as a platform that determines the net area that need to be worked on when an event triggers the next action. Key functions of Kanban shared in business include transit of work, sharing, endorsement of work and attribution.

An iterative development process such as Kanban has essentially gained relevance in the industry for the long period. However, most of the companies, especially large organizations and IT firms, are attracted to assessing the Kanban software development based on its strengths and weaknesses as related to team communication and collaboration. First, Kanban has been lauded for boosting communication as well as collaboration (Oza et al. 2013). This is possible using the Kanban board that is known for updating the team in the progress of the work items. The exhibition of the WIP limits prompts the need for collaboration and communication across a number of circumstances. In case of any blockage within the workflow, clearing it calls for the parties to pass or share information with a key purpose of developing a solution. This is perfectly articulated by the findings established by Maassen and Sonnevelt (2010) where impediments and bottlenecks were made more visible and clear on the Kanban board, while putting more pressure in the testers and developers. Such findings led to an understanding of the importance of corporation within teams.

The study by Oza et al (2013) also pointed out that Kanban shows a strong support towards team communication. Their findings noted that Kanban facilitates strong communications needed at the start of the project but keeps fading towards the end of it. Secondly, Kanban is cited as the key tool in motivating the team members while entrusting the norms and goals encouraged among the members. By showing an overview of the situation as well as displaying the work items, Kanban stands a better chance of convincing team members on the possibility of achieving the target. This is made possible through empowerment, increase in confidence and self-organization, which are key platforms introduced by Kanban. Based on experience report confirmed by Polk (2011), Kanban parents steady progress within the team and provides continuous improving cycles through energy and motivation. The argument is well supported by the notion of subjective feeling towards good performance and high efficiency.

Based on the findings by Oza et al (2013), Polk (2011) and by Maassen and Sonnevelt (2010), Kanban software development methods, like any other method, has weaknesses as well. Kanban is to lack significant shared goals and effective levels of communications within a team. Strandell noted that almost every person can develop software but the most decisive point revolves around how effective it can be. Furthermore, Kanban does not have the capacity of handling social issues and tool cannot guarantee success. The same implications can be extended to shared vision as well as explicit understanding of the problems, which is not perfectly exhibited when using Kanban.

Assessment of Kanban software development methods in terms of software productivity

Kanban has gained attention over the years because of its characteristics that are tailored towards productivity in the company. While fostering process improvement initiative, it is important that measurable performance benchmark should be given attention. One significant metric that is put into consideration includes efficiency or productivity. Based on the reports by Polk (2011), the WMS Gaming is said to have improved after considering the Kanban method. It is worth noting that one cause for improvement is when the Kanban team establishes performance metric, which is the leading factor to enhancement of the lead-time. Polk (2012) indicates that productivity is likely to rise after the WIP limits are implemented in the course of production. The second area of strength for Kanban in software development entails the platform for improvement. This is supported through operational excellence and Kanban coaching strategy, which can be tailored towards the improvement opportunities for the team and individuals.

The first contact is established when the coach interacts with team leaders before touching on the improvement process, which influences software productivity. Depending on the team’s maturity level, a baseline for improvement is developed before engaging the improve stage. The third strength for Kanban is operational excellence, which directly goes to software productivity. The roadmap to excellence is the same roadmap to Kanban (Matharu et al. 2015). Four concrete steps are confirmed for operational excellence, which also address the scope of software productivity. These include creation of a baseline, establishing the flow, creating the capacity and optimization.

The preliminary step of creating a baseline conforms to definition of the current mode of working. The baseline is necessary for the purposes of securing changes that can make the team sustainable. Subsequent stages that bolster productivity include measuring and managing workflow, creation of capacity for improvement and finally, reaching operational excellence (Corona and Pani 2013). All these elements work in conformity to the principles of optimization, which encourage a movement towards smaller units of work. Apart from the strengths, Kanban still has areas of weaknesses or pitfalls with regards to software productivity. The first area includes lack of a warning signal where Kanban fails to point out problems. Lack of such warning signals always make the company to run for years without taking note of the flaws. Defects that are noticed later tend to cost more than the ones which are noticed sooner. Secondly, Kanban lacks detailed guidelines, which has always been part of the key reasons as to why some of the projects fail in the due course. As much as the Kanban theory is vast and equally draws the voice of reason from separate disciplines, it does not call for the fundamental features that need to be addressed in the course of software development. Kanban confirms that even the team size cannot be blamed for the technical issues that include testing, tools for programming and the emerging architecture.

The central purpose for introducing the Kanban software development methods was to investigate whether the method is likely to boost the quality of software, which is produced by the company. From the observations made on different findings, chances are that the method can equally enhance quality of the software by ensuring improved productivity and increased teamwork, and still ignore problem in the company (Corona and Pani 2013). Before even looking at what team communication and collaboration and software productivity can bring on board, the version of quality improvement can substantially be confirmed through the general practices of Kanban. The practices reflect key activities engaged while managing the Kanban systems, and the ones that can impact the software development process. The activities support seeing through the work, improving the process and ignoring the ineffective change. The first practice, which can equally be adopted in software development process, is to visualize (Corona and Pani 2013).

The Kanban board provides for the visualization of the process by definition of the delivery points and a display of the WIP limits. Such displays are significant in understanding the current system, as well as establishing potential areas that need improvement. However, it is of note that board designs vary among the Kanban systems, which are defined through their uses. At the same time, software tools meant to support Kanban are likely to introduce constraints. The second practice is the limit work in progress where new items are never introduced until work is finished, concluded or completed. Kanban supports observation, limitation and optimization of the amount of work, which is key to success. The third activity includes managing the flow where the software development process is maximized through delivery of value, predictability, minimization of lead times and ensuring smoothness of the process. The maximization of the flow of value mainly revolves around the cost of delay on the work items. At the same time, the lead time serve as the most significant metric for customers.

On one hand, Kanban supports the process of making the policies more explicit. Kanban confirms that the process policies are expected to sparse, visible, well-defined and always applied. One type of such policies is the WIP limits, which involve capacity allocation as well as balancing. On the other hand, the implement feedback loops remain to be part of the controlled process which is significant for an evolutionary change. This ensures strategy alignment, risk management, operational coordination and service improvement among others.

Notably, the WIP limits prompt a need for collaboration and communication with the workflows facilitating solutions to different problems. As noted in the findings, the Kanban board exerts more pressure on both the developers and testers to figure means and ways of how a situation can be improved, or how the quality of the software can be enhanced among other areas of interest (Anderson and Carmichael 2016). Furthermore, Kanban sets in a fundamental believe of empowering or motivating employees as one key area that can enhance quality. Performance of the firm heavily depends on the attitude of the workers and their perception towards work. Kanban fosters simple process that attracts the attention and the right attitude of the workers. Limited tasks mean that individuals can take time while focusing on the specific tasks that can yield the right quality. The same argument can be extended to the need for product efficiency and performance of the organization (Rola 2011). Kanban believes that one can attain better results or outcomes while making use of similar resources. Implementation of the WIP limits is confirmed to be one key element that supports performance and team control.

As much as Kanban software development methods are good enough in supporting performance, they still have their own weaknesses. First, Kanban is not effective is hitting significant levels of communication within a team. This means that differences are likely to emerge even when the team seem to embrace Kanban ideologies (Anttila 2014). On the other, Kanban shows weakness when it comes to handling some of the social issues affecting the team or lead to team divisions as indicated before. Kanban, furthermore, shows incompetence when establishing guidelines for teamwork. This means that the quality of the software should be put under question because of the doubted procedures. At the same time, Kanban shows the tendency of hiding mistakes or reflecting a fake system that looks operational but has many problems that are hidden. This increases the chances of a breakdown of the process of software development in case problems go unnoticed for a long period.

While Kanban shows lines of weakness, it still stands chances of being applied in the company in Ocean Island with 150 software developers waiting for the new method. Kanban has shown that the new method barely takes note of the mistakes or problems within the system. It is also evident that Kanban lacks proper guidelines (Ericsson and Granlöf 2011). However, the methods still show that they have an impact on team collaboration and communication, which is an important area for quality improvement. At the same time, Kanban can boost software productivity by reducing the number of tasks to be attended to. Therefore, it can be recommended that Kanban should be used in a company with 150 developers and would like to work on the quality of the software, and not just developing it.

Conclusion

To sum up, software developers are said to have been used to such methods like scrum and agile for software development. However, the thought of Kanban software development methods seems to have changed the narrative. The report has confirmed that Kanban bears a history that saw Toyota grow to a level where it could compete with the rest of the multinational companies. The report has established that Kanban supports team collaboration and communication as members share vision and goals. The same goes to software productivity where quality is enhanced through reduction of tasks as developers are only required to focus on the remaining few tasks. The discussion part of it has explored on what Kanban does and key areas of strength that has attracted the attention of software development process. The report also indicated key areas of weaknesses and still embraced Kanban as the best method. Based on the many advantages attached to Kanban, it was finally recommended for a company in Ocean Island that has over 150 software developers that foster quality products.

Continue your journey with our comprehensive guide to Enforceability of a Secret Trust.

References

• Sommerville, I., 2015. Software engineering (pp. I-XXIII). Pearson Education.
• Oza, N., Fagerholm, F. and Munch, J., 2013, May. How does Kanban impact communication and collaboration in software engineering teams?. In Cooperative and Human Aspects of Software Engineering (CHASE), 2013 6th International Workshop on (pp. 125-128). IEEE.
• Anderson, D.J., 2010. Kanban: successful evolutionary change for your technology business. Blue Hole Press.
• Matharu, G.S., Mishra, A., Singh, H. and Upadhyay, P., 2015. Empirical study of agile software development methodologies: A comparative analysis. ACM SIGSOFT Software Engineering Notes, 40(1), pp.1-6.
• Rola, L.D., 2011. Kanban for small software projects. Project Background Report, The University of Manchester, Manchester.
• Bolaji, A., 2015. A cross-disciplinary systematic literature review on Kanban Doctoral dissertation, Master’s Thesis. University of Oulu. 62 p. Available at:
• Anttila, S., 2014. The hidden pitfalls of Kanban in software development.
• Anderson, D.J. and Carmichael, A., 2016. Essential Kanban Condensed. Blue Hole Press.
• Westin, A., 2016. Managing Software Service Operations with Kanban. Ericsson, R. and Granlöf, A., 2011. The effects of Kanban in software development teams: a study of the implementation at Sandvik. Corona, E. and Pani, F.E., 2013. A review of lean-kanban approaches in the software development. WSEAS Transactions on Information Science and Applications, 10(1), pp.1-13.
• Maassen, O. and Sonnevelt, J., 2010, June. Kanban at an Insurance Company (Are You Sure?). In International Conference on Agile Software Development (pp. 297-306). Springer, Berlin, Heidelberg. Polk, R., 2011, August. Agile and Kanban in coordination. In Agile Conference (AGILE), 2011 (pp. 263-268). IEEE.