Retrospectives allow the scrum teams to reflect on the sprint cycle by highlighting successes and issues that they faced during the current sprint cycle. It helps the agile teams to learn, grow, and improve their performance along with boosting their morale.
Retrospectives are focused on what went well and what didn’t, such as Sprint processes, iteration lengths, commitments, common blockers, feedback cycles, co-ordination with external teams etc. The teams should not be discussing technical issues related to the project, those discussions should be tabled to be discussed separately.
Step 1: Sometimes it is difficult for the team to articulate specific things, to facilitate discussion the facilitator can ask questions similar to the ones listed below
- Did the team finish the work committed in the sprint?
- Was there work added or removed during the middle of the sprint?
- Did the user stories have sufficient detail for the team to perform the work?
- Are the team members being pulled into managing any other work?
- Are the action items created in the previous retrospective complete?
Step 2: Encourage every team member to participate and gather data as to what went well and what could need improvement. With distributed teams this can be a challenge, so it is helpful to use a tool that will help with collaboration. Its best to supplement video conferencing with with a canvas wherein people can view and edit information simultaneously.
Step 3: Each team member can cast votes on issues that need to be tackled in next Sprint. The top two or three issues which have the maximum number of votes should be picked.
Step 4: The top issues should be discussed by the team to figure out what needs to change, if its within the team’s capability. Else the issue needs to be escalated to management. Once the team agrees on the possible solution or escalation then action items need to be created along with assigned owners to those action items.
One of the questions that came up during our retrospective at a program level is that as we are moving to continuous delivery, the concept of ‘Time Box’ maybe becomes irrelevant. As we are not waiting until the end of the Sprint to deliver or deploy our code into production, then why have these scrum ceremonies or processes?
The basic assumption is that Sprints force a team to release at a particular interval rather than being able to deploy once the code is ready to be shipped, even in the middle of the Sprint. Traditionally this is true, wherein the Sprint Review allow the teams to demo the functionality or user experiences and the Product Owner, signs off on it.
When we move to a Continuous Delivery model, especially when the end product is a hosted web application as opposed to a downloadable piece of software. The notion of waiting till the end of the sprint, adds little or no value.
The best way to handle it decouple the releasing the shippable increment with the other aspects of the Sprint, such as standups, backlog refining, planning, reviews and retrospectives. This approach allows us to keep all the benefits of following Scrum and at the same time embrace Continuous Delivery with no friction.
It is implicitly assumed that when an team transitions to Continuous Delivery that all the related aspects such as planning also happen continuously. This is rarely true, when there is no timebox, teams often fall back into the default mode of very little planning and alignment with the other teams.
Scrum framework gives us that luxury, wherein we can take a step back at the end of each timeboxed Sprint and reevaluate what has been achieved. Collect and present our findings to the larger group, especially when we are working in an enterprise. Based on the feedback from the users using the newly released features and input from the larger group on the alignment and strategic direction, the next iteration can be then planned.
As a summary, here are three things that will help us to continuously deliver using the same scrum framework
- Decouple the release or deployment to production from the Sprint Cycles but follow through on the Scrum ceremonies.
- Use the timeboxes to emphasise the human aspect of software development – take a pulse of team morale.
- Examine the interdependencies with other teams and plan them into your next iteration as most projects at enterprise scale are interconnected.
Hello Folks, I have been meaning to blog on the subject of Agile and Scrum because most of the material available today focuses on simplistic implementations such as co-located teams. Also they assume a simplistic predefined structure wherein the stakeholders are identified and available at the team’s discretion and dependencies could be worked out within one or more teams within the organisation.
The complexity is compounded in open source projects because of the varied nature the intermingling of contributors and stakeholders. The team is not only focused on features that were loosely drawn up by the product manager but also works actively on the ones that the community is interested in.
I also hope to address some of the challenges that are unique to working in open source environments, wherein you have to collaborate with not only internal teams but also work with external organisations which sometimes have conflicting interests.
One of the focus areas will be working with globally distributed teams, wherein the team members are spread across different timezones. For example even a simple thing as daily standup becomes challenging due to time zone issues making it impossible for team members to meet at same time.
If you are wondering about the image depicting lightening in a bottle – Well the original expression is “like trying to catch lightning in a bottle”, it describes something that’s extremely difficult, almost bordering on the impossible. That is how I feel, my self imposed assignment would be like, but based on the amount of pain and confusion it can alleviate, the effort will definitely be worth it.
Over the years I have realised that we tend to learn better from short, focused articles rather than elaborate descriptions and detail material. Hopefully, these one-pagers will aid in understanding and adoption of Scrum.
So, the plan is as follow up with short one pagers, in the context of open source and globally distributed teams.