Retrospective After Planning

Adoption of any agile framework is very interesting and non-deterministic process. Basically anyone can do anything based on simple rules. Rules vary from framework to framework, but it’s nothing comparing to waterfall or similar.

Freedom and flexibility of choosing how you work and what works best for you is a very nice thing, but … it can lead to a very weird decisions sometimes. Team’s decision to change basic rules like meetings sequence, time boxes, etc. should be a signal for you that something is really going wrong. Consider having a corrective actions or at least track it for some period in order to understand the real source of the problem.

I see only two reasons for such changes:

  • You don’t really understand what is the goal of a certain practice and your knowledge of it is superficial
    • Daily stand up is not for problem solving or big discussions, but for understanding the pulse and highlighting issues for further discussion during the day
    • Retrospective is needed not for discussing the output or success of the sprint, but for discussing how the process was applied and what should be improved or changed
  • You are trying to solve the consequence of the problem, but not the source of the problem
    • Try “5 Whys” approach or something like that to uncover the real problem

Before you decide changing basic and trivial rules of any agile framework please make sure that you really know and understand what you do!

p.s. this post is inspired by this discussion in this group – “Scrum Alliance – transforming the world of work.“.

p.p.s. “inspect and adapt”