Hot answers tagged

18

Responsible vs. Accountable Roles in a Pull-Queue System The question you're asking is really an X/Y problem. You have a couple of other problems that you haven't actually called out in your question: Kanban is a pull-queue system, not a push system. So, unless the API team knows to pull from your "feedback" column, or unless they have their own backlog ...


17

TL;DR Your question strongly implies management metrics tied to individual utilization rather than flow or cycle time. The 100% utilization fallacy is antithetical to Kanban, and to agile systems in general. Furthermore, Kanban systems aren't intrinsically concerned with how much time individuals allocate to a given task. Instead, they focus on the cycle ...


13

One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus. The daily standup allows ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

The main ideas with Kanban is to visualize your work and to limit work in progress. This allows you to maximize flow while at the same time see where you have bottlenecks. If you started work on something that now needs to stop for whatever reason, you need to remove it from your work in progress. What you do with it depends on what exactly you want to ...


11

I think this has a canonical answer, at least from a traditional PM point of view if not with Agile or Kanban or whatever else. If a piece of work was unable to be finished for whatever reason, by the mechanic, developer, trades person, whomever, then the issue falls back to the PM or PM control part of the project to be tracked and resolved. The ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


10

There are two schools of thought about what an Epic is. Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which ...


6

TL;DR Hold the event daily, even if you don't use the whole time box allocated for the meeting. Don't skip it routinely, even if you think you have good reasons. Doing so may not bite you right away, but it probably will eventually. If you're not finding value in the Daily Scrum, it's likely because the team isn't really performing just-in-time (JIT) ...


5

To contribute and also help move the discussion forward, let's first start with the definition of WIP: WIP is the number of task items that a team is currently working on. When rolling out a new workflow, you monitor the average number of task items in each iteration and determine the WIP limits. However, it is not possible to know if the WIP limit is ...


5

Unfortunately, there is no "right" answer to this question. However, there is a good way to find out the right answer for you. Especially in Kanban, the purpose of the board is to visualize your workflow. Consider a few questions: Do both teams have the same workflow? Does the workflow of value delivery mix between teams? Do you get better visibility into ...


5

Agile thrives on collaboration between people, rather than building walls around each team and throwing things over it. The ideal situation would be that the designers work in the same team as the developers and create their designs as the software is being developed, with the technology used to deploy the designs. This way, the designer is the one who ...


4

This depends quite a bit on the team norms and standards, but often the work is taken on by the team and not an individual. Several people may be involved in doing the work, depending on what the work is and the current skills and experiences of the people involved. For example, two or more people may pair up or mob on one piece of work to share knowledge ...


4

All work should be tracked. If you hide the things that don't conveniently work in your system, you eliminate the benefit of kanban. If you put a large open-ended research task into progress, it will take one spot in your WIP as you describe. This will encourage the team to break down the task, which will in turn force them to think critically about the ...


4

I would strongly suggest you ask the team. The team understands the domain, the way they work, the personalities involved and the nature of your organisation. They are in a much better place to determine the team structure than anyone outside of the team. This is what we mean when we talk about self-organising teams. Also, don't be afraid of making the ...


4

I just wanted to add a little to Thomas's excellent answer. Epics are a solution to a problem. The problem is typically: "Our backlog is a bit cluttered and some stories are quite big". You don't have to use epics, many teams get by without them. Experiment with how you use epics, but always within the context of the problem you are trying to solve. Are ...


3

Jira items have a history. When you move items from one column to another, that change is recorded and you have the history. You can find out who all the assignees were. And to be honest, that goes for your people too. If you move one item from "development" to "code review" and you re-assign the Jira issue, you still know who developed the code, don't you?...


3

One approach you might consider would be to add a time-boxed task that is an investigation of how you would go about doing the research. The goal would be at the end of this time-boxed task you would know more about the research and so would be in a better position to: Break it down in to more manageable sized tasks Estimate how long it will take As an ...


3

Little's Law is most commonly used to explain why the practices in Kanban exist. As you point out, you can just calculate the average cycle time and don't need Little's Law to tell you what it is. Now, you say your WIP is 3. I think you are conflating WIP with WIP limit. WIP limit is a set number but you should not be at your limit at all times. But for a ...


3

The two approaches actually solve different problems and are fairly compatible with each other if you happen to have both problems. Scrum Scrum is designed to solve complex-adaptive problems. That is, problems that are difficult or impossible to quickly identify the best solution for, moving targets, and problems where you understand the problem better the ...


3

TL;DR In agile frameworks such as Kanban, you shouldn't have to care about how the work is allocated within a process state such as "development." That's up to the team. Just focus on right-sizing the WIP limits to ensure they are based on available team capacity and optimize for flow rather than individualized tasking. Limit Work to Optimize Flow From a ...


3

TL;DR While there can be circumstances where you need the level of granularity you're proposing, in most cases it's likely to be a symptom of command-and-control management styles and an outgrowth of the 100% utilization fallacy. Kanban should generally be tracking significant state transitions at the product level, not attempting to prescribe procedures ...


3

Kanban's first principle is "Start with what you do now." and iterate from there. So, what you want to visualize is completely up to you, based on what you do today to track data about your work items. If you have absolutely no current process/ practice regarding something, start somewhere - take a decision as a team that "we will visualize these things ...


3

Why would this be an anti-pattern? One of the Kanban principles is about visualizing the workflow. Being an Agile practices, it's also about transparency. Look at the board and you have an image of what's going on. That means what work is in progress and - if you have an assignee on the card - who is working on the items. If you find it useful, you can add ...


3

It depends. It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...


3

I would say it really depends on the context - there are no "rules" that Kanban enforces - it is up to the team and the business stakeholders to decide. If it is happening on a regular basis, then, they should look at the WIP Limits and enforcement related policies to see if these need to change to accommodate this phenomenon. For the example you have ...


3

By and large, if the work is product development go with Scrum and if it is tech support go with Kanban The type of workload that you describe could come from product development + production bug fixes. If that is the case, go with Scrum. Designate a person as the Product Owner (PO) and empower the PO to make the final call on all prioritization. Otherwise ...


3

TL;DR There's no right or wrong answer here in terms of what activities, columns, and swimlanes belong on a given Kanban. However, it's likely that your process is being driven by a software tool choice rather than reflecting the actual workflows and working agreements in your process. You should carefully evaluate whether you have captured the right ...


2

Work in Progress is a critical part of Kanban because of Little's Law. You are welcome to read more about it, but the short version is it shows a direct relationship between throughput, response time, and work in progress. By limiting your work-in-progress and focusing on flow (and prioritizing getting things to done over getting started or keeping people ...


2

Limiting work in progress is a cornerstone of Kanban because: It helps to emphasise that Kanban is a 'pull' process It is often a very effective way to improve the throughput of work for a team It is simple and easy to implement It combines well with another feature of Kanban: visualisation of a process using a Kanban board


Only top voted, non community-wiki answers of a minimum length are eligible