hendriknielaender/double-trouble

Create an iterative agile dashboard

Closed this issue · 4 comments

flyck commented

Create a dashboard that highlights the iterative approach.

A tool that makes it easier for product managers and the company to understand releases / iterations.

Roadmaps today (jira, github, etc.) generally show big bulky epics on a fixed timeline. This is still waterfall. It is time for truly agile roadmaps without huge bulky epics, to foster an iterative approach, instead of waterfall in sprints.

We could:

  • blog about it (punchline: it is time for agile roadmaps)
  • use some cool framework like qwik to implement it
  • integrate with gitlab issues first, jira only later

Dashboard Sketch:
iterative_dashboard

Ontop of this, the dashboard could also display key product KPIs / data used to come up with goals

Repos:

flyck commented

Hypotheses:

  • Managing technical projects is hard for companies. There is a tendency to do waterfall in sprints.
  • It will be easier for companies to become more agile, if they have a better overview of the iterative process.
  • Product managers would benefit from an automatically generated graph, highlighting releases, plans / goals and hypothesis together with customer feedback, all in one dashboard. This would foster a more iterative approach.
  • It is kind of easy to pull a lot of the information needed for such a dashboard and display them in a UI.
  • A blog post on an implementation of such a dashboard could be interesting to read.
flyck commented

A related rant about the current use of epics:

Epics are called epics because they are huge and inspiring. They tell a story and push the team into a direction. An epic is not necessarily meant to be completed. Changes will inevitably happen, the course will be corrected. For the most cases, determining a deadline for an epic is a bit nonsensical and totally waterfall. Deadlines are sometimes needed. But in general it is enough that an epic paints the picture, while the releases make the way. Releases dont necessarily need a deadline, as they happen asap (within one iteration). You might have a successful epic, which results in postive KPIs and an enhanced user satisfaction, without ever finish all items in the epic.

flyck commented

Another idea: When hypothesis are itself tickets, which are assigned to the PMs, you can measure the hypothesis validation time. The shorter obviously the better ;) These hypothesis tickets would be just tickets with a special type or tag, depending on the system.

This validation time might be much more valuable - depending on the usecase - than the deadline for the epic. What we want is often not to meet a deadline, but to evaluate a hypothesis in a short amount of time.

flyck commented

Got a super basic prototype of an agile roadmap working in github projects 👇🏻 All the basic components are there, but they are hard to differentiate 😄 Time to build something custom...

image