Week 10 - Agile practices

Being a product owner and working with agile every day, the topics of this week were not very new to me. Regardless, it’s always good to reflect on how your current implementation of Agile relates to the base one as presented in the lectures. When working with Agile in practice you tend to pick and choose what works best for your team and project, as Belinda also mentioned in the Lecture content. This means that the way I am currently working with my team is a slight deviation from the baseline. Sometimes these adaptations are good, but sometimes they also snuck in unnecessarily. So let me take you through some of the main differences between my personal Agile practice and the one described in the lecture content.

Estimation

In the lecture material there was a focus on the Fibonacci scale story point estimation technique, The use of story points for effort estimation is widespread(Coelho and Basu, 2012; Usman et al., 2014; Zahraoui and Janati Idrissi, 2015). There are, however, a variety of ways to use story point estimation and the value of a story point is decided on by the team. A common way is to use the Fibonacci scale or some similar non-linear scale when estimation (Coelho and Basu, 2012; Tamrakar and Jørgensen, 2012).

The two teams for which I am Product Owner (the backend team and the frontend team) both use a different form of estimation with story points. In the backend team each story point is equal to 1 hour of work and we use a standard linear scale. In the frontend team story points are a measure of effort and we use the Fibonacci scale. In general, I find that the planning and estimation with the backend team is much simpler and faster, and it is also often very accurate. With the frontend team we tend to be overly optimistic in estimation. This might have to do with a variety of factors of course, like size of the team and experience of the team, but it is also noted in literature that using a non-linear scale can lead to overly optimistic estimations (Tamrakar and Jørgensen, 2012). This is important to note as overly optimistic estimations are one of the primary reasons for cost overruns (Molokken and Jorgensen, 2003).

Considering these findings, perhaps we should try out estimation on a linear scale with the frontend team as well to compare.

While working on the rapid ideation sprints I did not use estimation explicitly. This was largely due to the fact that I did not have enough prior knowledge to draw upon for the estimations. In the next project I will use story point time estimation to gain more insights into my development speed and to practice this skill in a game development setting. This will certainly benefit me when moving more towards game development. Just like in software development, incorrect estimation is reported as one of the main problems in game development (Kanode and Haddad, 2009; Petrillo et al., 2009). Getting better at estimating comes with experience, so starting early with practice will definitely help.

Agile for a project versus agile as a way of working

Agile is in the end more of a mindset than anything else. There are practical implementations of it like Scrum or Extreme programming but the principles from the Agile Manifesto are the core of it all. The lecture materials mainly talked about working Agile for specific projects. At my work we don’t necessarily have one project we got funding for that we need to take care of because we do not develop for specific customers. Instead, we develop our product to attract potential customers, and to increase the user experience of our current ones. This difference leads to some key differences in the way I use Agile at my work, versus the typically presented one.

One difference is in terms of the roadmap and sprint goals. We don’t have a roadmap covering the trajectory towards an end goal. Instead, we have a roadmap for the coming few months which shows the vision of where we want the product to go to. There is no end to the roadmap as it is a continuous process of improving and expanding out product. In this roadmap we have epics for specific features or topics we want to address. These epics can be seen as tiny projects on their own, with their own tickets. However, there are many epics running alongside eachother, with people being involved in multiple of them at the same time. To accommodate this the sprint plannings and evaluation are for the whole team and govern the planning of all these epics. Because of this the sprint goals are not always clearly defined goals such as “at the end of the week we will have an MVP of feature x”. Instead, the goals are broader like “this week we will be focussing on features x and y, and on fixing reported bugs x, y and z”.

Sometimes I wonder if we should make these sprint goals more defined, to increase the team spirit for instance. I could not find much in terms of literature on the topic for advantages of clear sprint goals. At the moment this way works for us, but it might be worthwhile to experiment with clear sprint goals every week.

Another issue is that Agile is mainly developed as a methodology for developing new software, and not necessarily optimally suited for maintenance of that developed software (Rehman et al., 2018). In our situation we are simultaneously developing new features, as well as maintaining what is already there. Heeager and Rose (2014), conducted a study on agile maintenance and found major problems related to missed sprint goals. They found that customers requested emergency work during the sprints and that it was difficult to address them mid sprint with no planning moment. We see the same. Some weeks there are a lot of support requests and sometimes there is nothing. It’s very unpredictable. To cope with it we have a specific person who is assigned support duty every week and for whom less story points are planned in. This way there is a buffer in terms of time. This approach has also been advised by Schwaber and Beedle (2001), and it works well for us.

What I can take home from both approaches

The way we work with Agile at my work and the standard practices advocated in literature both have their pros and cons in different situations. For me it is important to take home the aspects that will help me in my personal practice in the game development field.

The game development field is a different one from the general software development field, even though they share the main obstacles (Kanode and Haddad, 2009). In the paper from Kanode and Haddad they highlight problems with estimation, with the diversity of assets and poor management as main issues. Diversity of assets might be game specific, but estimation and poor management are issues that are also prevalent in general software development.

I can improve my own estimation skills by practicing more with the various parts of game development and using estimation techniques during the master’s. This way I can build up experience to better inform effort estimations.

In terms of preventing poor management I will be able to draw upon my current role. At the moment I have a management like role, and I am learning a lot about how to properly manage projects, how to make sure goals are met and how to keep a team happy. A game development project might be very different, but I am certain I will be able to translate the management skills from my current job to one in game development.

List of References

Coelho, E. and Basu, A. (2012) “Effort Estimation in Agile Software Development using Story Points,” International Journal of Applied Information Systems (IJAIS), 3(7), pp. 7–10. Available at: www.ijais.org (Accessed: August 6, 2021).

Heeager, L. T. and Rose, J. (2014) “Optimising agile development practices for the maintenance operation: nine heuristics,” Empirical Software Engineering 2014 20:6, 20(6), pp. 1762–1784. doi: 10.1007/S10664-014-9335-7.

Kanode, C. M. and Haddad, H. M. (2009) “Software Engineering Challenges in Game Development,” in 2009 Sixth International Conference on Information Technology: New Generations, pp. 260–265. doi: 10.1109/ITNG.2009.74.

Molokken, K. and Jorgensen, M. (2003) “A review of software surveys on software effort estimation,” in 2003 International Symposium on Empirical Software Engineering, 2003. ISESE 2003. Proceedings., pp. 223–230. doi: 10.1109/ISESE.2003.1237981.

Petrillo, F. et al. (2009) “What Went Wrong? A Survey of Problems in Game Development,” Comput. Entertain., 7(1). doi: 10.1145/1486508.1486521.

Rehman, F. U. et al. (2018) “Scrum Software Maintenance Model: Efficient Software Maintenance in Agile Methodology,” 21st Saudi Computer Society National Computer Conference, NCC 2018. doi: 10.1109/NCG.2018.8593152.

Schwaber, K. and Beedle, M. (2001) Agile Software Development with Scrum. 1st edn. Upper Saddle River: Prentice Hall. Available at: http://sutlib2.sut.ac.th/sut_contents/H129174.pdf (Accessed: August 6, 2021).

Tamrakar, R. and Jørgensen, M. (2012) “Does the use of Fibonacci numbers in Planning Poker affect effort estimates?,” IET Conference Proceedings, pp. 228-232(4). Available at: https://digital-library.theiet.org/content/conferences/10.1049/ic.2012.0030.

Usman, M. et al. (2014) “Effort Estimation in Agile Software Development: A Systematic Literature Review,” in Proceedings of the 10th International Conference on Predictive Models in Software Engineering, pp. 82–91. doi: 10.1145/2639490.2639503.

Zahraoui, H. and Janati Idrissi, M. A. (2015) “Adjusting story points calculation in scrum effort & time estimation,” in 2015 10th International Conference on Intelligent Systems: Theories and Applications, SITA 2015. Institute of Electrical and Electronics Engineers Inc., pp. 1–8. doi: 10.1109/SITA.2015.7358400.