Overview
The module focussed on the various approaches to managing a software project, namely waterfall and the numerous Agile methodologies, the stages of a software project including requirements gathering, project planning, cost estimation, risk assessment, and software quality monitoring and management. There was some academic reading and investigation of planning methodologies, testing techniques and estimation tools, but the bulk of the learning was achieved through the completion of a team project: planning and delivering a software application.
Agile SCRUM
The first decision facing our team was choosing which project management methodology we were going to follow. It was obvious that we should choose an agile framework, as our customers (the other team) hadn’t chosen their requirements when the 10 week schedule began. One of the initial tasks in the assignment was to gather the requirements from the customer, refining them until each one was SMART, measurable and deliverable. While this was in progress, we wanted to start the development of the system which we could later iterate on as the requirements were solidified. The waterfall approach to SEPM relies on the upfront gathering of requirements and detailed planning and risk analysis before any development takes place, and was therefore thoroughly unsuited to our tight delivery timeframe.
After settling on Agile, we needed to choose which ‘flavour’. Due to our lack of prior experience, we decided to follow SCRUM as it is widely used in industry, is based upon repeated sprints of development to deliver functionality and value in a timely manner, and has a clear framework of roles and rituals to follow.
Though, ultimately, our project was successfully delivered on time, I believe that there were a number of problems with the chosen methodology. Some stem from our ‘implementation’ of SCRUM, but others, I believe, may be issues with the SCRUM approach itself.
Our implementation
SCRUM is a lightweight AGILE methodology based on teamwork, good communication, short sprints of development, and continuous improvement and refinement of the development process. It contains a number of roles for team members and regular rituals/meetings (Schwaber & Beedle, 2002). The first and most important ceremony of SCRUM is the daily stand-up, where members of the development team meet to speak briefly about what they did, what they are doing, and what blockers or issues they are facing. The idea is that through daily communications, the team can stay informed about progress, and the product manager or team lead can pivot the team to a new direction should the need arise.
Another important ceremony in SCRUM is the retro meeting. After each sprint, the team meets as a whole to discuss what went well, what didn’t, and take action to improve the next sprint. The retro meeting is essential to bring value to the iterative sprint process as it helps teams continually improve and avoid repeating the mistakes of previous sprints (Dalton, 2019).
Our Issues
We did not have daily stand-ups. Our weekly meetings were often not fully attended and the agenda generally discussed our progress on the assignment. It was difficult to know what other developers were working on. I mean, we could see which story they were working on by looking at our JIRA board, which was usually kept up-to-date, but the details of the story’s implementation and the challenges faced are not recorded on the JIRA tickets.
We did not conduct formal retrospective meetings. This was a serious oversight on our part. Arguably, the most valuable aspect of Agile methodologies like SCRUM is that the short development cycles enable continuous refinement of the development process where each iteration learns from the previous one.
The ‘push’ methodology, which before a sprint begins defines the work to be done, relies on the ability of the team to predict how much work they can get through in the sprint. This, however, relies on team members being able to accurately predict how many hours they are likely to work on the codebase. While this may be a simple calculation in professional environment, where developers work a certain number of hours per week, and their career depends on it, in a part-time university project environment, the same external motivations of money and career do not apply, and it is unrealistic to expect developers on a project like this to treat it with the same dedication as they would their job.
My thoughts
It could be argued that as we did not implement the two main SCRUM rituals, we did not actually implement SCRUM at all but some bastardised version of SCRUMbut, i.e. SCRUM but we didn’t do this, and we didn’t do that. However, I wonder if SCRUM is actually a good choice for a part-time project where developers cannot or do not meet regularly, and where the time each team member commits to the project fluctuates depending on their external commitments.
In this situation, perhaps KANBAN might have been a wiser choice. KANBAN is based on a pull methodology, where work is begun when the team is ready to pull the work from ‘To Do’ to ‘In Progress’. Kanban limits the work in progress to increase throughput. It also requires less structure, with defined roles for team members deemed unnecessary (Ahmad et al., 2013).
In fact, since the end of our project, I have spent some time investigating the differences between KANBAN and SCRUM and research conducted into the efficacy of both approaches. A 2017 study analysed a number of projects conducted in KANBAN and SCRUM. It reported that both approaches led to successful projects, though KANBAN was deemed slightly better at meeting project schedules (Lei et al., 2017). My research into why our implementation of SCRUM was not as successful as it might have been has led me to a 2013 empirical study into the reasons behind SCRUM failing (Eloranta et al., 2013). This paper identified SCRUM anti-patterns, common deviations from the prescriptive SCRUM methodology which resulted in the failure of projects. Four of our project’s issues made the list of ten anti-patterns: sprints being too long, testing happening after development (sometimes in a separate sprint), unordered product backlog and invisible progress.
Discovering this paper before our project began might have helped us avoid these common pitfalls. I believe that my future implementations of SCRUM methodology will be much improved. I plan to do this in the next module Secure Software Development.
REFERENCES
Ahmad, MO., Markkula, J., Oivo, M., (2013) “Kanban in software development: a systematic literature review.”. 39th Euromicro conference on software engineering and advanced applications, pp 9–16
Dalton, J., (2019) “Sprint”, in: Great Big Agile. Berkeley, CA.: Apress https://doi.org/10.1007/978-1-4842-4206-3_57
Eloranta, V., Koskimies, K., Mikkonen, T. and Vuorinen, J., (2013) “Scrum Anti-Patterns -- An Empirical Study.” 20th Asia-Pacific Software Engineering Conference (APSEC) 1 (2013): 503-510.
Lei, H., Ganjeizadeh, F., Jayachandran, P.K., Ozcan, P. (2015) A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics and Computer-Integrated Manufacturing, 43: 59-67. https://doi.org/10.1016/j.rcim.2015.12.001.
Schwaber, K. and Beedle, M., (2002) Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.
