Software development changes from recent sprint retrospective... How have you improved your development process with retrospectives?

In my current contract the use of agile processes is relatively new to the organisation as a whole and certainly to our team. This means we are still refining our processes, so things like sprint retrospectives were we meet at the end of a sprint and try and figure out what things went wrong and hence we should do less of, what things went right and hence we should do more of, what we can do better etc. are very important.

We had one recently and it was one of the better ones I’ve been involved in any previous role or project. I thought it would be nice to share some of the suggestions which came out of it, as I’m sure you have had similar suggestions particularly when agile was relatively new in your environment. Suggested process changes from our retrospective are below:

Split the daily scrum into multiple ones based around project teams. The team as a whole is 8-10 .net developers, format to date was one big stand up corresponding to multiple projects, meaning we all had to listen to other people talking about projects not related to us. For next sprint we are going to do separate scrums for each project (although we are going to keep the one retrospective for shared learning purposes), which should save us time.

Move the daily scrum to morning time, we had been previously doing it in the afternoon, nothing particularly went wrong or anything, just most of us are used to doing it in the morning from previous roles. Also having them early allow us to work on removing any identified blockers that day, whereas with scrums closer to the end of the day, issues are more likely to be forgotten about as people are starting to head off home shortly after the scrums. I suppose too that morning scrums align better with the three questions which are most commonly suggested for daily scrums, what did I do yesterday, what will I do today? and any blockers? A question about the best times for the standup on Quora has lots of different viewpoints. We are going to try morning scrums for a sprint or two at least anyhow.

Actually stand up in the daily scrums to encourage quick and to the point scrums. Currently some of us seem to stand, some of us sit. I guess sitting during the scrum could possibly kind of maybe make it seem like a break. For the next sprint sitting will be frowned upon and be punishable by having documentation related tasks assigned to the culprits.

Stick to high level task related conversation in daily scrum, what I did yesterday, what I will do today, anything in my way? Really technical things should be ‘taken offline’. Everyone is going to be mindful of this during the next sprint, hopefully it will save us a small amount of time anyhow.

Finish one vertical slice/use case set of the application completely before starting on new pages, unless a very good reason not to. At the moment we appear to be doing a few tasks from one page, then another few from a different page. At the end of the sprint when at the client demo we then need to say to the client you can test this page, but not this particular feature etc. Next sprint we are aiming to very selectively breakup parts of a particular piece of functionality that different team members can work on without stepping on each others toes (the system is not huge) so essentially we are going to try and go down (finish a section completely) rather than across (adding new pages).

Quick peer review of proposed steps to implement before someone begins on a new type of task/page. Although the team is very collaborative, there has been occasion were a developer (myself included) has gone off on a tangent and implemented something that was completely not needed or in a manner that was superfluous or more complex than it needed to be or just down right wrong. This quite often resulted in a lot of lost time due to rework. To minimise the chances of this we agreed for the next sprint that for any task that is new to the application(s) and hasn’t been done before will we get the person assigned the task to briefly outline the problem space and in four or five bullet points how they propose to implement the feature or page. After that the rest of the team will peer review and hopefully if something obvious is being missed as a collective we will be able to spot it.

Deploy to dev and uat via Visual Studio publish tool with web.config transforms so no manual manipulation needed. We were kind of half doing this but the deployment process is very easy to get wrong so for all future sprints we are going to lock this down fully as its quicker and more reliable.

Apply TFS label to the source code at the end of sprint so we can know what we presented to the clients, what version we fixed bugs in, introduced bugs in, easily restore, more easily prepare changelog files by comparing labels for sequential sprints etc.

Overall I think the team found the retrospective very valuable, we are certainly looking forward to seeing if the process changes above have a positive effect on the burndown chart. Please share some of the suggestions that have come out of your retrospectives too, particularly the ones that made a big difference for the subsequent sprints.

I'd appreciate shares or likes if you enjoyed this post. Also note that I am actively building my LinkedIn network so if you’re an IT or HR professional and interested please send me a connection request.