First retrospective to bring feedback over this 'special' two sprints following Scrum but with a Kanban board.


Retrospective

What did we do well?

  • Ringo joins the team.
    • Quickly catching up and helping the team.
  • The team is working well together and the work environment is good.
  • P.O. and stakeholders seem satisfied with the product.
  • Thorough testing,
    • P.O. bringing his expertise, 
    • experienced tester on MorphAn.
       

What should we have done better?

Working process (6 votes):

Although the team is just 'starting' we already identify some points to improve in the process as it follows:

  • Stand-up:
    • The overview takes too much and sometimes overlaps with the individual turns.
    • Sometimes we go off-topic or start conversations that should take place AFTER the stand-up.
  • Metrics:
    • We need a system to measure efficiency, both for the P.O. and as a team to know how well we are performing. 
  • Board:
    • Not entirely clear when to create new issues and when to extend the existent ones.

Action points:

  • The stand-up overview will take place at the last moment, allowing everyone.
  • Limit the interaction from the P.O. and the Architect.
  • For the next 'bug-sprint' we will introduce a simple metric system to describe complexity, as 1 for easy 5 for medium and 10 for very complex. In the future, when having new features we will use a proper scrum method.
  • Start with large issues than are later broken into simpler issues. Helping the testers detect problems and developers fixing them.

Resources (5 votes):

We have noticed several issues in capacity reflected on bottlenecks in code-review and testing.

  • The expectations for code review were not met. It seems as we had a misunderstanding on what to review and when to do it.
  • It seems like the team has been built a bit 'on the go'.
  • We should have assessed the capacity from the beginning. What and how much.

Action points:

  • Make SMART agreements before starting the sprints.
  • Being concrete.
  • Elevate faster problems when the resources become limited.

Legacy code (3 votes).

Sometimes implementing small feature requests meant spending too much time due to old limitations in the implementation.

Testing data (1 vote).

Some issues lack enough testing data for a more clear solution.

Actions

  • Overview at the end of the stand-up
  • P.O. and other 'consultants' stand-up interaction to be more limited.
  • Make SMART agreements.
  • Elevate resource problems as soon as they are detected.
  • Create smaller issues.