BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Goal-Driven Kanban: Improving Performance and Motivating Teams

Goal-Driven Kanban: Improving Performance and Motivating Teams

Bookmarks

Key Takeaways

  • Challenging goals motivate a team, improve performance and help bring deep satisfaction to team members
  • Having a chain of goals achieved forms a path of the team's successes
  • Goals and timelines should be set by ther team, not imposed on them
  • Celebrating success reinforces the positive motivation of good goals
  • Retrospectives are particularly important when goals are not achieved to enable blameless examination of what to do differently in the future 

Motivation

Since 2003 when Mary and Tom Poppendieck published their book, Kanban has become a popular method in software development. However, it has never gained more than a few percent of the overall distribution of various agile methods and practices. Scrum and its custom flavors dominate.

Kanban has captured a niche where there is no need to deal with challenging goals and employing the “fast try/fast fail” approach. Commonly it is used by teams that provide various types of service. Another typical application of Kanban is for products that are either in maintenance mode or very mature and thus require just steady adding of new features at a moderate pace. Also, Kanban is quite often chosen by teams that prefer to work in a less challenging and more relaxed atmosphere. Here the main factors are the skill levels of developers and/or the overall motivation of employees.

Actually both Scrum and Kanban work well in high-pressure and low-pressure environments. However Scrum as an approach creates more pressure on developers than Kanban due to timeboxing and fine-grained planning.

Discussing with me, many motivated senior developers claimed that in Kanban they miss commitment and focus while they want to keep the bar high to ensure that they can enjoy great achievements time by time. In contradiction, Scrum brings timeboxing and the sprint goal which fit well to these desires. Unfortunately, software development does not always imply challenging goals, quite often there is a need to deal with boring tasks, maintenance, and adding scattered tiny features. Developers periodically struggle when trying to identify a sprint goal and see timeboxing as a rather annoying restriction causing unnecessary overhead when running “non-goal driven” sprints. 

Scrum was created to cope with complex problems (open systems, where the right approach is “try and see what happened”) and is not that good when dealing with complicated (closed systems, fully analyzable) or even simple problems. Kanban addresses complicated problems well however is not designed for systems where uncertainty is high and where the “try and fail/succeed” approach makes more sense. A good example of an open system is a company that is just forming its product proposition and trying to identify its place on the market in close collaboration with customers.  A stable company that has been around for years with the same customers and products, just adding tiny features here and there can be considered as a closed system with some approximation.

black and white typewriter on green textile

To overcome restrictions of these  Agile methods while keeping their strengths, we came up with Goal-Driven Kanban. We took Kanban as a basis and enhanced it with elements that help developers understand main goals, focus on them, and commit. At the same time, they can comfortably work with a class of tasks where it is difficult to identify goals, focus and commit to them.

Amendments to Kanban Values, Principles, and Practices

Naturally, to succeed, we need to address the challenge on different levels. 

First, in addition to the normal Kanban Values 

  • Understanding the working pattern within the organization and the way to change it
  • Agreement to continuous improvement
  • Respect the current responsibilities and roles
  • Leadership for everyone
  • Flow to get certain results in specific ways
  • Customer focus via flow optimization
  • Transparency at all levels including status, risks, opportunities, and decision making
  • Balance viewpoints, capabilities, and aspects to achieve goals
  • Collaboration to find solutions together and encourage consistent improvement

we propose to add two new ones

  • Commitment to achieving the goals set
  • Focus on the work needed to achieve the goals

Second, on the Kanban Principles level in addition to standard ones 

  • Start with what you do now
  • Agree to pursue incremental, evolutionary change
  • Respect the current process, roles, responsibilities & titles
  • Encourage acts of leadership at all levels

we introduce a new one

  • Choose the next goal

Finally for Kanban Practices in addition to 

  • Visualize The Workflow
    • Visualize invisible: work, workflow, risks, etc.
  • Limit WIP
    • Implement pull system
  • Manage Flow 
    • Monitor, measure, and optimize, ensuring smooth and fast flow
  • Make Process Policies Explicit
    • How things work and how work is done.
    • DoD, Team Charter, etc.
  • Implement Feedback Loops
    • Both internal and external ones. 
    • Could be (but not limited to): Standups; Delivery Review; Operations Review; Risk Review etc.  
  • Improve Collaboratively, Evolve Experimentally
    • Usually triggered by WIP and Feedback Loops.
    • Requires common agreement in the team.

we add the new practice

  • Set a voluntary deadline for the agreed goal and allocate time for these activities
    • Avoid any distractions while achieving the goal
    • Celebrate when achieved
    • Retrospect frequently

Kanban Values Extension

Commitment to achieving the goals set

The goal serves as a target for the team to strive for and to plan against. It can be a product goal, addressing technical debt, research, or learning. 

The goal is an objective for the team. It must be fulfilled before taking on the next one.

Focus on the work needed to achieve the goals

The team focuses on the work needed to achieve the goal. The team continuously avoids distractions which might delay or even prevent achieving the goal.

The focus is the center of the team's interest and activities. 

Kanban Principles Extension

Choose the next goal

Whenever the team has reached the previous goal and feels comfortable to take on new challenges, they choose the next goal.

Choosing the next goal helps the team build its own path from one achievement to another, keeping the bar high, motivating team members and giving them freedom to find the best way they can contribute to organizational success.

Kanban Practices Extension

Set a voluntary deadline for the agreed goal and allocate time for these activities

The team may set a deadline to achieve the agreed goal. It helps the team to concentrate on the goal related activities and gives a feeling of necessity and urgency.

The deadline specifies the latest date by which the goal should be completed. The team puts in all possible efforts to meet it.

Time allocation helps the team to ensure that the goal and respective deadline are achievable. It requires proper estimation of efforts needed, at least superficially, skills available and understanding who contributes to which part of the goal while keeping in mind the respective knowledge set and skill level of team members. Effort forecasted has to be compared with measured team capacity to prevent the team from over-committing and the danger of burnout.   

Time allocation ensures that the goal and deadline are reachable while proper capacity is left for additional/unforeseen tasks. Time allocation is voluntary and not imposed on the team from outside.

Avoid any distractions while achieving the goal

Almost any team experiences strong pressure to do “extra” work on top of the planned activities. It could be additional requests from stakeholders e.g. related to pre-sales or new contracts, urgent requests from existing customers, bug fixing, supporting other teams etc. This requires clear agreements with all team stakeholders, so they know the next team goal, are aware of the deadline and clearly understand the team`s capacity available for their requests.

Avoiding distractions is tough. The team should decide how to deal with the problem, whether, for example, to create a clear policy which every team member should follow or introduce a gatekeeper role.

Celebrate when achieved

Taking pride in the team accomplishments by celebrating them boosts team members self-confidence, motivates them to achieve more and stimulates further development of the team.

Celebration gives the team the opportunity to pinpoint exactly what worked so they can repeat it in the future.

Retrospect frequently

When the goal is achieved, acknowledging what worked well and how we can make it even better opens room for further improvements. 

When the goal is not achieved, it is extremely important to understand what happened and measures that can help reach the next goal. 

Method Description 

The key element of the Goal-Driven Kanban method is the team that is able and willing to identify and pursue challenging goals.  

Note: the method does not impose those goals on the team. 

Prerequisites 

  • The team wishes to have the freedom to set challenging goals and enjoy achieving them while not being restrained by timeboxing and (timeboxed) sprint goals
  • Is either practicing Kanban or learned Kanban
  • Becomes familiar with Goal-Driven Kanban Extensions to Kanban Values, Principles, and Practices

The Team

  • Discusses various goals which they see ahead of them with input from various sources: Product Management, Architects, other teams, technical debt, etc.
  • Chooses the next goal to achieve
  • Agrees on a realistic but challenging deadline for achieving the goal, keeping in mind all other circumstances, for example, additional maintenance tasks, bugs, outages, requests from other teams, etc.
  • Avoids various distractions on the way towards the goal
  • Celebrates when the goal achieved
  • Retrospectively looks at the path towards the goal and agree on respective adjustments when needed
  • Can take a break for a while for example dealing with ad-hoc tasks, bug fixing, maintenance, etc.
  • Repeats with the next goal

four person hands wrap around shoulders while looking at sunset

Part 4. Rules

The team is free to choose the next goal.

This is needed to support team autonomy, self-efficacy, and motivation. The best results are achieved by teams that understand their path ahead and have sufficient support. Forcing a team towards some goals will have a negative effect.

The team is free to choose the goal deadline.

The deadline is chosen by a team based on goal complexity, uncertainty, available competencies, and skills as well as the team's capacity. Forcing the team towards an unrealistic deadline will lead to over-commitment, potential burnout, and overall unhappiness spoiling the proposed approach.

Team and team members’ performance is not measured based on goals achieved/missed

Measuring the team performance based on the goals they chose would inevitably lead to the team playing safe by taking non-challenging goals, planning safety time buffers, blaming distractions, and overall compensating of the introduced KPI by any means.

The team can stop setting goals at any moment and continue with pure Kanban.

It is important to have the freedom to step aside when it becomes obvious that the proposed approach does not fit the team/organization/environment etc.

Part 5. Goal-Driven Kanban in Action

Adopting goal-driven Kanban was done in one team. Initially, the team used Scrum. Due to the nature of the business, the team had a significant percentage of tasks that were dependent on other teams and various stakeholders and thus the team continuously was not able to complete them in time. Naturally, this caused frustration, and the team decided to switch to Kanban. This cured the issue but over time, the team members started feeling that they work as a “feature factory”. They were missing challenges. Thus Goal-Driven Kanban was born.

After receiving management support and agreement with Product Management, the team chose their first goal. It immediately revealed the need to re-plan other features and tasks since the team had to re-focus on the agreed goal. It required rough estimation of the goal, understanding of the team capacity and further agreements with stakeholders.

While working on the goal the team had to tackle various challenges, because the bar was high and the team had to all work together doing overall design and development. This led to better understanding of strengths and weaknesses of every team member and triggered the team forming processes.

When completed, the team celebrated the goal achievement together with stakeholders and received the deserved appreciation which raised their motivation to a very high level.
Naturally, they took a look at what was done retrospectively and agreed on better estimation of future goals as well as the capacity they decided to dedicate to other features and tasks. This helped to get even more support from stakeholders because of high transparency and better predictability.
Over time, while going from one challenging goal to another, the team went through various maturity stages and finally learned how to act as an organism rather than a group of individuals, choosing directions, making decisions,  and acting as a true self-organizing team. 

Part 6. Conclusion

The method presented here is a formal description addressing the concerns of developers looking for more challenges while not willing to be restricted by unreasonable limitations. It needs experimentation and thinking about how to make it work in your current circumstances and limitations: skills level of team members, team maturity, nature of products and tasks as well as proper management support. And even more: to succeed, the team members should truly wish to try it out, understanding they want to follow this path and what they are willing to achieve. Then the magic happens!

Ref: Lean Software Development: An Agile Toolkit
Ref: Kanban Explained for Beginners | The Complete Guide.

About the Authors

Rate this Article

Adoption
Style

BT