Overburdening: how to cope with it and work is irrefutable

Sometimes teams must take up work that exceeds their capability. Consider a company policy that says ‘The call desk picks up calls within 60 seconds’. This policy forces a call desk team to pick up new calls within 60 seconds. Saying ‘No’ to new work would be a sensible thing to do. But just not in this case. When in such a position what can you do to overcome overburdening and still keep happy customers?

In this blog post I’ll show that by looking at the workflow one can discover new options to overcome the overburdening and still not say ‘No’.

Alternative ways are described in The Business Support Team Pattern and Help! Too Many Incidents! – Capacity Assignment Policy In Agile Teams.
Read more →

Accurate Forecasting Without Estimation

Often the team or somebody in the role of product owner gets either the question ‘When will it be finished?’ or ‘What will be finished at <some future date>?’ and some forecasting is necessary to answer the question.

This blog shows an alternative way of forecasting that is based on empirical data and skips estimation altogether. In a follow-up blog I will address the ordening of the backlog of items.

Read more →

More Effective Team With Less Efficient Workers!

Methods based on Agile and the Kanban Method both stimulate collaboration to achieve focus and flow. In practice this is often challenged by teams with specialists who have a tendency to maximize the utilization of the specialists.

So, is a team with a focus to finish work more effective than a team with focus on efficiently using expertise?Read more →

Versnel je team met Scrumban!

Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende ‘velocity’ laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg hieruit door een structuur en principes te bieden.

Read more →

Backlog ordering done right!

Various methods exist for helping product owners to decide which backlog item to start first. That this pays off to do so (more or less) right has been shown in blogs of Maurits Rijk and Jeff Sutherland.

These approaches to ordering backlog items all assume that items once picked up by the team are finished according to the motto: ‘Stop starting, start finishing‘. An example of a well-known algorithm for ordering is Weighted Shortest Job First (WSJF).

For items that may be interrupted, this results not in the best scheduling possible. Items that usually are interrupted by other items include story map slices, (large) epics, themes, Marketable Features and possibly more.

In this blog I’ll show what scheduling is more optimal and how it works.

Read more →

Demonstration of the Exactness of Little’s Law

Day 18

Little’s Law is a powerful tool that relates the amount the work a team is doing and the average lead time of each work item. Basically there are two main applications involving either 1) the input rate of work entering the team, or 2) the throughput of work completed.

In previous posts (Applying Little’s Law in agile gamesWhy Little’s law works…always) I already explained that Little’s Law is exact and hardly has any assumptions, other than work entering the team (or system).

This post demonstrates this by calculating Little Law at every project day while playing GetKanban.
Read more →

The Business Support Team Pattern

Teams that organize plannable or ad hoc work using Agile methods often exhibit a similar pattern. If they’re usually responsible for operating the application, supporting the business in its use, and/or developing new features on top of a (usually third-party) application, I call them “business support teams.” I’ve noticed that the more ad hoc type of work these teams have to deal with, the more they struggle with a single backlog approach for managing it.

In this post, I’ll show you how business support teams such as these can use a particular set-up of boards and agreements to get a handle on their work.

Read more →

Dancing with getKanban (Using POLCA)

Companies that produce many different or customer-specific products can use a variant of Kanban called POLCA, which stands for “paired-cell overlapping loops of cards with authorization.” A few years back, POLCA got some attention on Twitter and I explained its potential application to knowledge work on my blog in a post titled, “Squeeze More Out of Kanban with POLCA.”

In this post, we play the getKanban Board Game, initially using the standard rules for work in progress (WIP) limits, then, inspired by POLCA, we change the rules. The results show an equal throughput between POLCA and non-overlapping WIP limits, with a smaller inventory size in the case of the POLCA version.

First, I provide a short introduction to the getKanban Board Game with a description of the set-up and basic results. Then I provide a brief introduction to POLCA and explain the change of the rules in the game and its set-up using it, then discuss the results. Finally, a few words are spent on the team’s utilization.

Read more →

Questions with a license to kill in the Sprint Review

A team I had been coaching held a sprint review to show what they had achieved and to get feedback from stakeholders. Among these were managers, other teams, enterprise architects, and other interested colleagues.

In the past sprint they had built and realized the automation of part of the Continuous Delivery pipeline. This was quite a big achievement for the team. The organization had been struggling for quite some time to get this working, and the team had realized this in a couple of sprints!

Team – “Anyone has questions or wants to know more?
Stakeholder – “Thanks for the demo. How does the shown solution deal with ‘X’?”

The team replied with a straightforward answer to this relatively simple question.

Stakeholder – “I have more questions related to the presented solution and concerns on corporate level, but this is probably not the good time to go into details.”

What just happened and how did the team respond?

Read more →