Godsend Project Management #6: What we did right and what we did wrong
In this entry, I will try to look over what we did in terms of project management objectively, how we followed wagile principles and where we made mistakes. In order to not be all negative, I will also try to highlight what we did correctly.
At the end of the very first sprint, we did something correctly – a sprint review and a retrospective. Having these meetings was useful, as we could look back and see what we did, what’s left to do and what we could do better. However, it also made one problem apparent – meetings are not always useful, especially when no action comes out of them. This more or less happened to both of the meetings. While the sprint review was less useful, as we simply did not have enough data to estimate how long development of features takes, we could not re-scope properly to make sure we don’t overload ourselves with work. However, the sprint retrospective came out with some incredibly useful points and I think that having the meeting itself was really good.
The problem then came down to the fact that a lot of the retrospective points were never actioned. Not to say all of them, but more than half for sure. In my internship with IBM, I learned one way to remedy this which I tried suggesting, but I guess I didn’t push for it enough. That is coming up with an action plan as a result of what’s discussed in any particular meeting and assigning people to put the plan to, well, action. As a result of not practicing that too much, our team just sort of ditched the reviews and retrospectives, and instead at the end of each sprint we would just meet to talk about the feedback given to us, rather than looking back at how well we actually performed and how we could improve the team performance (this could have included re-scoping to be more realistic about what we want to achieve).
As IBM is quite large and difficult to manage, actually, meetings is what people did there most often. This taught me to be wary of too many meetings, as ultimately they consume time and if the action points that come out are not worth the time spent, or are not actioned, then the meeting just wasted development time for all of us. Andy (our producer liaison) tried to remedy this by involving as much of the team as is necessary in meetings, rather than all of us, which was a good step forward I think. Throughout the module, our meetings became more focused, as they mainly discussed feedback, feature design and implementation, and as a result, meetings finally became actioned.
However, we never did end up talking about re-scoping our project and that’s how we ended up in a development cycle that is not sustainable. Furthermore, based on the feedback we received in milestone reviews, we put even more features and tasks into the backlog. We did try to prioritise, but prioritising was made pointless, as we would end up doing all of the tasks allocated to the overloaded sprints anyway.
In a sense, we were very much following a waterfall approach – identifying the backlog early on, then crunching like crazy to meet the task deadlines as indicated. Instead, we could have and we should have re-scoped the project by prioritising important features and cutting on the ones that we did not deem to be as crucial to the project. The only thing agile about our approach was the fact that we added even more on to the project as feedback arrived from milestone reviews.
To put the ridiculousness of our goals, one of the weekly Alpha sprints contained over 330 hours of work after we broke down and guesstimated how long each task would take (this is mostly programmer hours mind you). 330 hours in 3.5 days (8 hours per day, lets say) would require around 12 people to accomplish, but there’s only 3 programmers. Our answer was crunch, but it is definitely not the most appropriate solution, we should have just re-scoped.
Having talked about meetings, sprint-reviews, retrospectives, milestone feedback, sprint planning and backlogs, the only thing left to discuss about our wagile approach is the scrum meetings. At first, these seemed to have little use, but eventually we found that it helped identify blockers, task dependencies and design problems in our game. We would first break into talking about the problems during the scrum, but one of the producers shifted it around to instead use scrum to identify meetings that need to happen. Once we started doing that, it became so much better, as we started identifying who needs to talk to who to resolve dependencies and such after the scrum. Putting that into practice was definitely useful, especially since we couldn’t find a good way to mark task dependencies in Hansoft. It also made me realise why – Agile says Human interactions over processes and tools and that’s the one principle we really followed well. Rather than marking a task as dependent in a tool such as Hansoft, we would just talk to each other and resolve the issue.
How I would approach it next time
Going forward to the next project, there’s a couple of thoughts in my mind about how to do it differently. We learned how to manage meetings eventually, so we’re good on that. We need to do sprint reviews and retrospectives, and then put those to action too. We didn’t do them as much due to how overloaded we were with development work I guess, but having those reviews would also enable us to tackle the problem of being overloaded. We just need to insist on having the meetings and looking back. I think given how exhausted everyone was by the end of it, we should be pretty motivated to do just that for the PS4 project. Furthermore, I heard a great quote from one of the guests in our final presentation, which is “be a producer or a designer, don’t be both”. I think this is something for our producers to really take home. All of us wanted to make a great game and that was the problem. We were all designers at least partially, and we really need a person who is solely focused on getting the thing done in a timely fashion, rather than getting the game to be great. If time is not the primary concern of one of the team members, we can not possibly how to manage our time more effectively.
Godsend Project Management #6: What we did right and what we did wrong
In this entry, I will try to look over what we did in terms of project management objectively, how we followed wagile principles and where we made mistakes. In order to not be all negative, I will also try to highlight what we did correctly.
At the end of the very first sprint, we did something correctly – a sprint review and a retrospective. Having these meetings was useful, as we could look back and see what we did, what’s left to do and what we could do better. However, it also made one problem apparent – meetings are not always useful, especially when no action comes out of them. This more or less happened to both of the meetings. While the sprint review was less useful, as we simply did not have enough data to estimate how long development of features takes, we could not re-scope properly to make sure we don’t overload ourselves with work. However, the sprint retrospective came out with some incredibly useful points and I think that having the meeting itself was really good.
The problem then came down to the fact that a lot of the retrospective points were never actioned. Not to say all of them, but more than half for sure. In my internship with IBM, I learned one way to remedy this which I tried suggesting, but I guess I didn’t push for it enough. That is coming up with an action plan as a result of what’s discussed in any particular meeting and assigning people to put the plan to, well, action. As a result of not practicing that too much, our team just sort of ditched the reviews and retrospectives, and instead at the end of each sprint we would just meet to talk about the feedback given to us, rather than looking back at how well we actually performed and how we could improve the team performance (this could have included re-scoping to be more realistic about what we want to achieve).
As IBM is quite large and difficult to manage, actually, meetings is what people did there most often. This taught me to be wary of too many meetings, as ultimately they consume time and if the action points that come out are not worth the time spent, or are not actioned, then the meeting just wasted development time for all of us. Andy (our producer liaison) tried to remedy this by involving as much of the team as is necessary in meetings, rather than all of us, which was a good step forward I think. Throughout the module, our meetings became more focused, as they mainly discussed feedback, feature design and implementation, and as a result, meetings finally became actioned.
However, we never did end up talking about re-scoping our project and that’s how we ended up in a development cycle that is not sustainable. Furthermore, based on the feedback we received in milestone reviews, we put even more features and tasks into the backlog. We did try to prioritise, but prioritising was made pointless, as we would end up doing all of the tasks allocated to the overloaded sprints anyway.
In a sense, we were very much following a waterfall approach – identifying the backlog early on, then crunching like crazy to meet the task deadlines as indicated. Instead, we could have and we should have re-scoped the project by prioritising important features and cutting on the ones that we did not deem to be as crucial to the project. The only thing agile about our approach was the fact that we added even more on to the project as feedback arrived from milestone reviews.
To put the ridiculousness of our goals, one of the weekly Alpha sprints contained over 330 hours of work after we broke down and guesstimated how long each task would take (this is mostly programmer hours mind you). 330 hours in 3.5 days (8 hours per day, lets say) would require around 12 people to accomplish, but there’s only 3 programmers. Our answer was crunch, but it is definitely not the most appropriate solution, we should have just re-scoped.
Having talked about meetings, sprint-reviews, retrospectives, milestone feedback, sprint planning and backlogs, the only thing left to discuss about our wagile approach is the scrum meetings. At first, these seemed to have little use, but eventually we found that it helped identify blockers, task dependencies and design problems in our game. We would first break into talking about the problems during the scrum, but one of the producers shifted it around to instead use scrum to identify meetings that need to happen. Once we started doing that, it became so much better, as we started identifying who needs to talk to who to resolve dependencies and such after the scrum. Putting that into practice was definitely useful, especially since we couldn’t find a good way to mark task dependencies in Hansoft. It also made me realise why – Agile says Human interactions over processes and tools and that’s the one principle we really followed well. Rather than marking a task as dependent in a tool such as Hansoft, we would just talk to each other and resolve the issue.
How I would approach it next time
Going forward to the next project, there’s a couple of thoughts in my mind about how to do it differently. We learned how to manage meetings eventually, so we’re good on that. We need to do sprint reviews and retrospectives, and then put those to action too. We didn’t do them as much due to how overloaded we were with development work I guess, but having those reviews would also enable us to tackle the problem of being overloaded. We just need to insist on having the meetings and looking back. I think given how exhausted everyone was by the end of it, we should be pretty motivated to do just that for the PS4 project. Furthermore, I heard a great quote from one of the guests in our final presentation, which is “be a producer or a designer, don’t be both”. I think this is something for our producers to really take home. All of us wanted to make a great game and that was the problem. We were all designers at least partially, and we really need a person who is solely focused on getting the thing done in a timely fashion, rather than getting the game to be great. If time is not the primary concern of one of the team members, we can not possibly how to manage our time more effectively.