Skip to main content

Scrum: Retrospective

From a collection of writings I wrote in 2007 when I first explored this methodology.





Retrospective is a process where in the team reflects upon the just finished iteration and enumerates what went well, what did not go well, what they should continue to be doing, what they should immediately stop doing, and what new things they should start to improve the process.

In my view, in order to do justice to this exercise, the following pre-requisites have to be met:
  • The environment should be created such that, people can open up to air their views
  • The primary focus should be internal (i.e. within the team) with the other stakeholders, being good listeners. They effort should be to understand the views/issues raised and help the team in addressing the issues by providing necessary support and guidance.
  • The scrum master should be an active facilitator who will drive the team towards holistic improvements and ensure that the meeting does not reduce to a forum for finding faults.
  • The management should back the exercise, show patience and help the team evolve by giving sufficient time, and respect for this exercise.
One important aspect, which I believe will add a lot of value to the process is to make the scrum master the primary facilitator of the exercise, who with the help of other stakeholders can encourage the team to open up, solicit feedback and drive the team towards solution. The purpose would get defeated if the scrum master (who in my opinion is like a shepherd for the team) abdicates his responsibilities at this juncture and the whole process is driven by people who are not in touch with the working dynamics of the team.
The other thing we should avoid during the exercise is the urge to justify the happenings. Definitely it is obvious to everyone that the events which transpired are justifiable. But the focus of the retrospective should be to hear the views of the team and enable them to work in a manner where they can maximize their own productivity.
The utility of this exercise is lost if at the end of the retrospective, the team walks away with a feeling that there is nothing to improve and derive satisfaction from the sole fact that they have aired their grievances to everyone. My point is that - "Retrospective is not a forum to air grievances. It is a forum available to the team to reflect and come out with mechanism to improve the way they are working".


Comments

Popular posts from this blog

Dilbert on Agile Programing

Dilbert on Agile and Extreme Programming -  Picked up from dilbert.com - Scott Adams.

Big Data: Why Traditional Data warehouses fail?

Over the years, have been involved with few of the data warehousing efforts.   As a concept, I believe that having a functional and active data  ware house is essential for an organization. Data warehouses facilitate easy analysis and help analysts in gathering insights about the business.   But my practical experiences suggest that the reality is far from the expectations. Many of the data warehousing initiatives end up as a high  cost, long gestation projects with questionable end results.   I have spoken to few of my associates who are involved in the area and it appears that  quite a few of them share my view. When I query the users and intended users of the data warehouses, I hear issues like: The system is inflexible and is not able to quickly adapt to changing business needs.  By the time, the changes get implemented on the system, the analytical need for which the changes were introduced is no longer relevant. The implementors of the datawarehouse are always look

Overview of Hadoop Ecosystem

Of late, have been looking into the Big Data space and Hadoop in particular.  When I started looking into it, found that there are so many products and tools related to Haddop.   Using this post summarize my discovery about Hadoop Ecosystem. Hadoop Ecosystem A small overview on each is listed below: Data Collection  - Primary objective of these is to move data into a Hadoop cluster Flume : - Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store. Developed by cloudera and currently being incubated at Apache software foundaton. The details about the same can be found here . Scribe : Scribe is a server for aggregating streaming log data. It is designed to scale to a very large number of nodes and be robust to network and node failures. Dveloped by Facebook and can be found here .  Chuckwa : Chukwa is a Hadoop subproject dev