Clip Retrospective

Round the room (10 min)

Quickly rotate around room and collect thoughts on: What went well? What didn’t go well? What could be done differently?

• Well
  • Edmonton team learned a lot, coming from wild west world 🤠
  • Team go good at jumping on items and closing them (x2)
  • Liked the process used for development, sprints were nice
  • Calgary + Edmonton group agreed to do this and it happened!
• Not Well
  • Requirements
    • User requirements were discovered late in the project
    • Communication was messy between client and team
    • Requirements weren’t that clear to team (why, who, etc)
    • Lack of clarity in what the client wanted, some surprises late in project
  • Operations
    • Some team members were idle at end of project
    • Project plan wasn’t laid out that clearly at beginning
    • Team confusion on what they were to provide
    • Backlog items confusing without descriptions, could have been broken down more
  • Communication
    • Clients can’t drive project requirements on their own, perhaps we do more
    • Backlog items were too big to fit into a sprint
  • Feedback
    • Clinicians were being too nice, we needed some more negative feedback
    • Feedback coming from clinicians was not that useful at times, we could have coached them
  • Quality
    • First real in-person demo was a nightmare (lots wrong)
    • Bugs discovered late because of a lack of focus on demoable prototypes
• Change
  • We should have a “project owner” to have a wringable neck
  • Could use a dedicated person for management of pull requests
  • Try user stories for requirement gathering

Themes and voting (5 min)

Group items from team into themes and vote on which to discuss first.

1. Requirements (xx
2. Operations (xxx
3. Feedback
4. Quality
5. Communication (x

Discussion (30 min)

Operations

• We were learning how to do this. New processes, organizational learning.
• Single wringable neck - Having a project lead / point of contact to direct traffic would have helped the team know what’s going on.
• In our environment, availability is difficult for a whole project. At least a project hierarchy could be defined, ex: this person is the lead, if they’re not there, then 2IC takes over.
• Backlog issues may be due to team being new. If the team was more aware of the process, they would perhaps have been able to correct / adapt to Eli being away, etc.
• Backlog items were far too general (some stories, didn’t really call that out). We needed to do more user story breakdown in sprints.
• Perhaps some training for the team ahead of time re: process
• Edmonton / Calgary coordination with their management (ex: sharing resources)

Requirements

• Clients do have skin in the game, they need us to produce something for their research. Yet, their requirements / concepts were a bit too loose.
• Leverage demos to pull feedback from clients early to make course corrections. We did do a bit of this and it was successful to some degree.
• Communication of schedule pressure would help with feedback from client. Ex: should we refine a feature further or get going on the next thing. The “tick / tock” cycle will require us to be for firm about schedule.
• We can take some responsibility for requirements too - we talked in circles in the first client meeting. Ex: coaching them to state needs as a story (ie: as an I can so that )
• Communication of “what they’re going to get” would have helped set their expectations. They could have provided some feedback on the plan as we worked.