Talk: Commitment Failures to consistently Successful : A case from the Land of Gurkhas

Talk description

Title:	Commitment Failures to consistently Successful : A case from the Land of Gurkhas
Short synopsis:	This is an experience sharing session based on my 4+ years work experience in a Scrum Team. The Scrum ceremonies are really important, but Team should first understand why the guidance is to do the ceremonies and whether it will really help the team. Team should be free to tweak the ceremonies as per their own understanding with good reasoning. Here I'll go through some of the ceremonies and how some tweaking helped us in a big way! Max size: 500 chars
Long synopsis (optional):	1) Iteration Planning --Well groomed stories are planned in the iteration based on both Team Velocity and Capacity hours loaded. --Remind the team that its okay to take below capacity, but fulfilling the commitment is utmost important. --Plan the work such that, majority of work finishes 2 days before the sprint ends. Why - Because, its hardly possible to plan the work for all the team members till the end of the sprint and still able to complete all the stories. - Helps team to get habituated to complete 100% commitment. - If unknown/unplanned risks occur, Team still has buffer time to mitigate the risk. - If the team really completes 1 or 2 days before the Sprint end, they > Analyse stories of next sprint. > Increase skills : Tehnical/Domain/Anything that will ultimately help them individually as well as benefit the team. > At times, just chill - Do whatever Team members feel like doing. One can even mark a story as Stretched or Not committed if it helps. This can happen due to Capacity/Non-confidence of delivery. 2) Daily Stand Up --The Team member specific answering of 3 questions is great for start. But when the number of team members is a bit on the higher side or when the work is complex, the answers to the 3 questions may be difficult to grasp. --The alternate method is Story-wise answering of 3 questions by each member who is working for the Story. Why - The status and issues raised becomes story specific and easy for everybody to understand the current progress of the story and if there is any help required from anybody. -- This is done based on priority of the story, so top stories get more attention and people are automatically forced to change their priority to complete the priority stories. Helps minimize WIP. -- Team members also inform "When" the tasks they are working will be completed. This helps everybody to re-plan their own tasks based on priority. -- Discussions after the normal 15 minutes time is really required. Do it whenever required with the members(if necessary with everybody in the team). 3) Sprint Acceptance & Demo Acceptance of a Story need not wait till the Sprint Demo Day(last day of Sprint). The story must be sent for acceptance as soon as it is completed. This helps reduce the ToDo work and reduces risk of non-completion. 4) Sprint Retrospective Retrospective must be used for Team's Continuous Improvement. -- The things that are going well must be appreciated and continued. -- The things that are not going good, must be discussed and improvement plans/actions identified. -- Team should also brainstorm, if there is a thing or two, if undertaken, will really help the team. If anything is identified, that should be planned. -- The improvements can be within the Team primarily, but nothing should stop raising points outside the team which impacted team's work. Such things should be escalated to rightful stakeholders(most probably by the SM). Max size: 5000 chars
Tags:
Speaker directory:

Speakers directory