Cut my life into stand-ups, this is my Scrum approach… Correlation, No waterfall…. Don’t give a truck, if you click this post, reading
Hello!Today I will be sharing my experiences with Scrum as a producer (Scrum master??) for team Kraken.Don’t mind the title, just follow the tuneSprints and tasksFor this project, the sprint length was pre-determined to be 1 week long (although 2-4 week long sprints are most effective), which I am not very content with. However looking from another perspective, it makes fellow team members work pretty much every day. Starting with small steps is good for them, rather than starting with 2 week sprints. One reason why I would prefer longer sprints is to give members more time to complete a bigger user story that requires more time and attention (for ex. A user story covering an enemy. With all animations, one week is barely enough) In the beginning, not all tasks were delivered at the end of a sprint, even though our second year scrum master and I explained clearly that the tasks group members choose, have to be done by the sprint reviews. If any issues occur, where someone feels that they can’t finish all their tasks, they are supposed to be brought up during the daily stand-ups. However, that part was taken for granted by some of the members. Task overload meant we had to move leftovers to the next sprint, or even remove an asset or two forever (for ex. a dying animation for an enemy). At the same time, there is no real “punishment system” if someone doesn’t complete all of their tasks, whereas in a professional environment, that wouldn’t be accepted for long and the employee would risk losing his job. The employee also gets a salary for his work – here in university not everyone is motivated to work, show up for meetings, take initiative etc. I am pretty lucky with my team. Almost everyone comes to all of the meetings, are there when needed, take initiative and are motivated to do their job. That is SUPER important for a project to succeed, and is a way to gain full benefit from agile approaches, such as Scrum. (I don’t want to mention individual/group-specific “bad examples” because of respect to my team) Daily stand-upsThe daily stand-ups have been going really well compared to my initial expectations. I’ve even had them at 8.45 for a week and people still showed up! I don’t have them at 8.45 anymore, though. That was because of 9 am lectures. Thanks to the stand-ups, everyone knows each other’s progress in terms of task completion. If anyone needs help with a task, she/he can ask for aid at the daily stand-up from a fellow team member. These 10-15 min meetings also provide increased communication between the team members. I think it is important to meet each other physically often. Every individual has their own preference in communication style, whether it is over a digital chat, over a phone call or meeting physically, our group has a lot of both physical and digital (over chat), which creates a good balance, in my opinion. The only issue I experience regarding stand-ups is the “same place and time every day” aspect of it. It’d be really nice to actually have an office/work space dedicated to the team – which would make the “same place” of it all easier and more motivational for the team to show up. Practicing daily stand-ups here at campus entails room-booking, which is shared with all campus students, which means that chances of being able to book same room every sprint are minimal, speaking from own experience. I’m not even going into detail regarding “same time” stand-ups.. To make daily stand-ups more effective, and properly practiced, it is recommended to have a Team Board (Kanban board or similar, made out of for ex. post its) present as well. So when a member says he/she is done with a task, that task is moved to “done” section. This is impractical to execute for our project due to lack of a stable work space. Visualization improves communication, and a team board is one of the approaches, which makes it easier to keep track of team’s progress. Right now, this is only visible in “sprint planning” sections in team’s Scrum document.
Working AgileEven though I’m mentioning lots of negative factors, I do enjoy working Agile, especially when my team members work agile as well and understand importance of it all. It enables high level planning rather than low level planning, which gives space for change. I do my best to listen to me members’ opinions and suggestions and also accept change. As an example, I create high level weekly schedules for my team. If lead designer wants to add an extra design meeting then I add it to the schedule. I don’t neglect it and force everyone to follow the pre-made plan engraved in stone. That is the opposite of agile philosophy.
It feels like there is so much more I’d like to include in this post, but I have a DSDM framework (not Scrum) exam tomorrow to study for. Bye!  |
