Posts

Showing posts with the label Retrospection

Root cause analysis for why so many meeting happens

One of the common issues that every organization is facing is too many meetings!! Is it good or bad, we can easily find out using a technique called 5 whys!! Lets take an example - In a typical scrum environment, after the sprint planning is over, team is again meeting to clarify some more doubts Why#1 - why are we meeting again to clarify requirement? response - because when team actually started working on the requirement they found more questions/gaps. Why#2 - why team did not come up with earlier during the sprint refinement/grooming meeting? Response - because team were busy with the last sprint activities hence did not go through the requirement gaps. Why#3 - Why Product owner could not realize these gaps earlier? Response - because PO was busy with the other priorities and could not focus on the requirement to analyze it thoroughly Why#4 - Why is Product owner is so busy when it is clearly defined role. Response - Because Product owner is handling too many proj...

6 tips for Scrum Master to make Retrospection meeting effective

Comparing to other Scrum Meetings, Sprint retrospection meeting is sometimes considered boring by the Scrum Teams. Team do not find much value in participating in this meeting. What could be cause of such feelings. Sometimes this becomes repetitive and same issues/pointers are discussed. SM need to think over it. I advise the Scrum Master to follow the below mentioned pointers to make retrospective meeting effective: 1) This is a place for team to talk about the people, process, relationships and tools which are delicate matters as there are chances team members start pointing fingers to one another for the failure. SM master need to avoid such discussion to popup. Lets keep this meeting healthy. Note it down and discuss it later with the concerned member. 2) See all the team members are getting the opportunity to talk and share their thoughts on the sprint.  3) This meeting to thank to all the people who helped during sprint execution. There could be dependencies ...

Retrospection meeting using Fishbone diagram

Image
Step 1: Identify the Problem Step 2: Work Out the Major Factors Involved Step 3: Identify Possible Causes Step 4: Analyze Your Diagram Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. http://www.mindtools.com/pages/article/newTMC_03.htm http://www.techrepublic.com/blog/tech-decision-maker/create-fishbone-diagrams-with-the-xmind-open-source-tool/

Any right way of doing Agile retrospective meeting?

There is no TRUE way of doing retrospectives. Teams are different in motivation, competence, culture and size. What works for you, might be ineffective in my context.  For me, the key indicator of good retrospective - developed action plan to improve process. How you get there is not as relevant

Retrospective Technique - 5 Whys

The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.The primary goal of the technique is to determine the root cause of a defect or problem. (The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.) A key phrase to keep in mind in any 5 Why exercise is "people do not fail, processes do". Source-  5 Whys Example-  The vehicle will not start. (the problem) Why?  - The battery is dead. (first why) Why?  - The alternator is not functioning. (second why) Why?  - The alternator belt has broken. (third why) Why?  - The alternator belt was well beyond its useful service life and not replaced. (fourth why) Why?  - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)