This is a story of a true scrum team, self-organized, that realized that scrum was holding some heavy flow pains that they wish to solve. The feeling was that this team delivers but with a lot of context switch. The team felt that a focus is missing that they deliver high rate of code but struggling to deliver E2E value. They felt, that although they deliver to the satisfaction of their stockholders, they can do better.
They identified much pain in preparing the sprint, sniffing the tasks and managing the flow.
They have decided to change direction and move to scrum-ban. Meaning adding a Kanban style flow management to their day to day activities. As a self-organized team, they have identified their own needs, decided themselves over the method, trained their own members over the new flow and took ownership over the evolution of their flow.
The following post will present the evolution of a Kanban board in a scrum environment by a self-organized team.
First suggestion of the flow
Once the most simple and basic flow is agreed, we move to a physical board.
Why ? because we can easily change our flow on a physical board then on any there… and it will really be hands on , visible flow.
Wip is set at the first time
User stories are added … off we go…
Adding avatars:
Progress is easily visible, especially beyond development (e.g – to sandbox and production)
The method is exposed to other teams
The team starts identifying different types of tasks . It help focus over the right priority , it helps identify progress. We still struggling to achieve a fast moving value towards production.
Blockers are excluded and paced on the shelf to be highly visible. It helps focus on removing impediments that holds value from flowing to production.
New user stories are added every day, the velocity is higher than we used to have.
Version control visibility is also added. Helps Focus on delivering fast value to production
Blockers are discussed and eliminated every day during the daily meeting, eliminated to allow faster value delivery to production
The team board is being controlled and changed according to changed requirements and needs during the sprint as relevant
New card types are introduced .
Some sprints passed and the team reports on faster value to production, easy to manager CI. Easier to identify blockers, easier to identify automation issues and to take ownership as a team over entire flow tasks.
Besides, its fun working in this team, after all , no fun , no value delivery.
Look how many user stories are done now.
