GovStack SandBox Retrospective

 Overview

Reflect on past work and identify opportunities for improvement by following the instructions for the Retrospective Play.

 

 Retrospective

Add your Start doing, Stop doing, and Keep doing items to the table below. We'll use these to talk about how we can improve our process going forward.

What was good

What was bad

Ideas

What was good

What was bad

Ideas

  • -The team and teamwork. Especially for UX part, Jonas was really helpful and stress-free, which was very positive. It was easy to see the roles on the team and work with others.

  • The customer was helpful regarding our work, and they gave constructive feedback, which was helpful. It was nice to see their active involvement in the project.

  • Positive feedback from our customer regarding our work were really motivating.

  • Level of freedom and responsibility over the sandbox (this can be an also negative thing on some level)

  • open discussions and exchange most beneficial to make progress, let's have more of that

  • we sprinted into uncertainty, but we sprinted, always better than working completely loose

  • great positive attitude from Meelis towards team and project generally

  • Nico is very supportive to make "things possible" for us

  • Architecture workshop in Helsinki

  • The scope has shaped a much more understandable

  • The UI/UX team has got the good pace

  • Team resourcing with expertise is pretty good
    Cooperation with stakeholders is on good pace (expectation management)

  • We still lack momentum, clarity, and focus.

  • Information about the product was too vague and sometimes contradicting, especially regarding workflows and BBs. The time spent on understanding the product slows down the process.

  • Documentation of the product is ambiguous, which makes it hard to understand, work and create. For example, scheduling BB documentation includes BBs workflows (which is also a different concept than general workflows). It can be seen on GovStack file a BB that is called Accounting BB, which is nowhere else but plays an important role in scheduling bb workflow. Or use cases that are too vague, which causes us to make a lot of assumptions.

  • There are many assumptions made for the projects to move quickly, but it is hard to predict how these assumptions might affect the project in future.

  • Lack of research for understanding user needs (what they want to see, do and play with etc).

  • nothing was bad! let's lighten the fog going forwards

  • A lot of meetings and time spent, but still things are a bit confusing

  • There are still a lot of uncertainties to clarify in whole Govstack ecosystem
    Catch up into others WG work- where they stand and how it may interact toward Sandbox project
    Slow start and understanding of needed resources
    Missmatch of tender requierments and real busines need

  • Add proper description and acceptance criteria to all tickets

  • even more exposure of work results and ad-hoc reviews

  • push technical evaluation of building blocks even more, set focus on realistic BB candidates for full or partial sandbox integration

  • simple DoR page in confluence to copy from for diff. types of tickets

  • 2nd "start" for the Govstack initiative

 

 

 

 

 

 

 Action items