Earlier on in this blog I have written about feedback loops. Time has come to revisit that topic, and also to talk a bit more how we do it right now.
One of the six Kanban core practices is “implement feedback loops”. Short loops gives the possibility for fast feedback. Our feedback loops are mainly implemented as a set of meetings with different cadence.
The purposes of the meetings with different cadences are the following:
- Improve quality – By giving early feedback on work, errors can be found and corrected when they are “small”, and not later when they become “disasters” (i.e., found in production by customers).
- Reduce context switching – By giving feedback fast, the context is still “active” and no context switching is needed (that takes time and reduces the overall productivity).
- Implement feedback loops – As mentioned earlier, it’s one of the six core practices in Kanban.
Meetings with daily cadence
The purpose is to enforce all six Kanban core practices. The team captain conducts a daily standup in front of the kanban board, with all team members present. Other stakeholders can listen in. Focus is to get tasks to flow through the process, and taking care of and removing impediments (bottlenecks that are preventing the flow).
We believe that over time more brains makes better decisions than just one! To prioritize between bugs is an activity known as “bug triage” in the software industry. All new bugs entered in the ticket system shall pass this meeting for decision. Fix or not? If fix, when – current release, upcoming or future? Is the bug valid, if not close.
The bugmaster (yes that’s the name!) conducts the meeting and goes through the list of bugs currently in the state “Dispatch”. Afterwards the ticket system is updated with all the decisions made on the meeting.
Meetings with weekly cadence
Status, Planning & Prioritization
The purpose is to follow up on already made commitments, but also to be agile and be able to act fast on changes from customers or in the market.
This weekly meeting has the following agenda:
- Action points from last meeting.
- Discuss the overall planning, currently we are using “The Circles”.
- Discuss and prioritize activities in “The Volcano”.
- Any adjustments needed in time, cost or scope? We work in teams, but team members can move between them to where they are needed the most for the time being. If we can, we cut the scope for a release (we work in priority order, starting with the things that are promised to customers so it is possible). A last outcome is to postpone the release (change the release date).
- Any other business. Sometimes we use “The Shooting Target” to focus when we get closer to a release for a product.
The Head of Project Management is conducting this weekly meeting together with other stakeholders and the captains from the teams. A written protocol is produced and made available after each meeting.
System architect group
The purpose of this meeting is to secure that we have an architecture for our products that is sustainable and can live a long time. General topics around the architecture is discussed (security, scalability, redundancy etc.), as well as all tickets marked “Sysarch” in the ticket system. The Head of Development leads this weekly meeting together with all system architects.
The purpose is for developers to show their work on regular basis and to get early feedback on it (before it is “too late to change”). The demo is conducted on Friday afternoons together with “fika” (Swedish phenomena – like an extended coffee break) in the control room.
Meetings with monthly/quarterly cadence
The purpose is to produce a prioritized scope (specified on high level) together with a time plan (release date) for the coming release of a product. Stakeholders meet in one or several meetings to discuss:
- Targets – What do we aim for with this specific release? The targets must be meaningful and understandable to ALL! They shall also be helpful in the daily work. “Shall I do A or B?”, the targets shall guide the decision.
- Scope – What shall be included in the release.
Ad hoc/when needed meetings
The captain calls the team for a planning meeting anytime needed. Usually this is done when the team starts to work with a new thing (fetched from “The Volcano”).
The purpose is to secure that we improve the teams and the process a little step every day (continuous improvements). Before we had this meeting regularly (bi-weekly), but we sort of lost momentum. Now the meeting is called upon when needed (something in the team or process needs to be improved). We use a channel on Slack to bring up the topic with two possible outcomes:
- The topic is discussed and solved on the channel directly
- The topic is extensive and a meeting is needed (or some smaller topics are collected before a meeting is called).
The Agile Coach and the captains together with other persons with interest in the topic(s) perform the meeting. The outcome is documented on the Slack channel.
There you go, these are the meetings we conduct to implement feedback loops. We also have some other channels for feedback, but I save them for another blog post. What type of feedback loops does your organization have? Don’t hesitate to contact me if you have any questions!
All the best,
Tomas from TheAgileist