When things don’t go according to plan
|
Welcome back! This weeks post will be about some of the issues and struggles I have experienced while coaching my team as a scrum master, and how I plan on resolving these issues. It might be a bit dry, so I apologize in advance. The members of the project I am currently in charge of have during these past few weeks had massive issues with successfully delivering on the tasks that they had picked during our sprint planning sessions. Each sprint review consisted of me asking to see results and getting shown next to nothing. At a regular workplace this kind of late delivery of features would have negative consequences. However, since this project is a part of the course we all study, the only real consequence of not finishing your tasks is having to explain to the group that you did not succeed with the tasks for the week. I can for example not cut their salaries or threaten to fire them if they perform an inadequate job. Still, even if that was the case, that would not be my primary solution to a situation such as this one. Instead my perspective of the issue is to understand why certain members have issues with completing the tasks they have picked for themselves. Mainly this was an issue for my two graphics students that each week had a new set of excuses to throw at me. Simply explaining the Scrum framework and how such issues should have been brought up early during daily stand-up meetings was not enough to remedy the problem. After talking to the two multiple times, I had developed a decent understanding of why things were taking so long. They are both talented and have the skill to produce something great. With that kind of talent and skill it is common that you set unreasonably high quality standards on your work. The end result that I was finally shown was truly excellent, but it should not have taken that long to deliver. Besides, the finished product looked very much like an earlier version that I was shown a week or two previously. The time spent “improving” the asset did not create enough value to justify the time spent on it. So where am I going with this? In parallel with my game design major, I study project management. Currently we are working towards our certificates in the DSDM framework. DSDM can be tailored to work with Scrum. By applying certain principles of the DSDM framework into how we work, we can eliminate situations such as the one described previously from happening. While the Scrum framework is nice in the sense that it gives amazing amounts of freedom to your team, it also poses the risk of lacking enough structure to keep the project stable. I will not work with DSDM in this project, since it can not be applied for this specific project. I will however add some of the principles to the way I practice Scrum. DSDM has 8 principles, several of them being applicable and useful to elevate the workflow within the project. “Never compromise quality” and “Deliver on time” are two of these principles.
The 8 principles of the DSDM framework Never compromise quality is in essence a way of saying “work till it is good enough, no more, no less”. In principle it will make sure that the work does not have its quality compromised, while avoiding to add details that add little value, thus avoiding the risk of diminishing returns on the time invested on the task. This goes hand in hand with delivering on time. If you try to add extra details to the product, you risk delays. Creating something that is just good enough allows the team members to move on to different tasks, thus maximizing efficiency and having the level of quality consistent across everything created within the project. To apply these principles to the Scrum framework, the members of my team will now timebox their individual tasks. So for example, in a sprint planning session when they are asked to estimate the amount of time they will have to spend on the tasks, they not only estimate but also assign the hours that they are allowed to dedicate to working on that specific task. In the end, all tasks picked should end up at 20 hours of estimated worktime for the sprint. Knowing that you only have 4 hours to work on a specific asset, reduces a lot of stress. While this might not be obvious to everyone, I am confident that this is the case. If you are given a basically unlimited amount of time, it is much harder to be content with what you have created. You keep wanting to add things to the product, to make it better. While it is true that things can always be improved, it is like previously stated a process that has diminishing returns. By knowing that you have for example 4 hours to complete the task, much of the burden of seeking to create something that is perfect is reduced. Upon telling my graphics students that this is how we will work in the future, they thought it sounded reasonable and explained that my read on the situation was correct. In the end I feel like I learned a lot from having these problems. I am thankful that it happened on my first real project, and I am proud of myself for finding a solution that I feel was tailored perfectly for the issues that we were experiencing within the group. Not having the option to punish my team members is a blessing in disguise, since it forces me to really find the root of the problem and use my creativity and limited experience to solve the problem. Thank you for your time!  |
