This project was an attempt to create a Kanban Board that respects Agile, Lean and Devops principles. The Kanban Board's purpose is to make work visibile, identify Work In Progress and resolve bottlenecks. Adapting these principles to Game Dev is my goal.

After some thinking and experimentation I came to the conclusion of archiving the page. The reason is that it's too soon to define processes and methods until we are clear on one thing:

<aside> 💡 We need to establish what exactly our goal is for Dare.

Are we trying to create a full, small game? Are we making the first playable for something bigger and we're never going to leave pre-production? Where does all of this fit into our thesis? Can we make something unfinished for our honours and finish it for Dare? Or should it be finished for our honors, and then we sprint for some extra features to win Dare?

</aside>

Last semester we sometimes struggled with processes exactly because of their "forced" application: we adopted some procedures without responding to real needs, and that made them often archaic.

Following are the materials for the exercise conducted.

Principles to Keep in Mind

  1. Work should always flow downstream, never go backwards. This is done to avoid handoffs, which cause a loss in productivity and disruption. We try to inject quality into the system early, so that defects are identified sooner and our architecture is always consistent. We do this by breaking tasks down as much as possible to bring the project to a "shippable" state as early as possible and then always keeping it stable by working on smaller and smaller batch sizes
  2. Feedback should cycle back as much as possible, so that when a card does go backward we are aware of what happened and how we can prevent the same issue from happening next time.
  3. Every production pipeline has a bottleneck, a constraint. Every improvement that is not made at the constraint is an illusion: if you improve before the constraint then work will just pile up before it, if you improve after the constraint then those work centers will be starved for work. Improve the processes where work tends to pile up.
  4. Keep it simple, stupid
  5. People before tools and processes
  6. Methodologies don't make a difference, having one and sticking to it does.
  7. [Creativity and Productivity require different strategies](https://nesslabs.com/should-we-really-focus-on-one-thing-at-a-time?)
  8. Self not for feeling down when creating example tasks: don't worry if you can't think of any, you're not an art director, neither a programmer, you can't know on your own, the tasks are defined together by the self-organized team when choosing to tackle a User Story.

Experimenting with Kanbans

Experiment 1: Focus on Features and Bugs, Linear, Few Columns

Experiment 3: Work Stations