aspose file tools*
The moose likes Agile and Other Processes and the fly likes Kanban and individual status Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Kanban and individual status" Watch "Kanban and individual status" New topic
Author

Kanban and individual status

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Marcus Hammarberg wrote:Think about this: how do your coworkers know that you have loads to do? That you're on a roll? That you need help? What you have accomplished the last week?

Marcus,
If there's only one person working on tickets in a column, I can see how this would work, but if you've got more than one then how would you know how well a specific person is doing? Are you having people initial the card as it moves across the board?

Thanks,
Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

Hi,

Oh no, that's no fast rule at all. You can, but you sure don't have too.

A process with different persons in each step would create a lot of handovers and waiting times.

It can still prove useful to have the different stages a work item goes through on the board. Or you might not have that. One great example that I've been using lately that is described here: http://codebetter.com/marcushammarberg/2013/08/13/some-tools-for-improved-focus-improve-teamwork-and-faster-delivery/

So; model the process you are using today onto the board. If that contains a lot of handovers - show that. If you are teams that follow the work item from start to finish show that.

Our customer doesn't really care - they want working software in production. We should strive to reach there but start from the point where we are today.


Hope this helps
/Marcus
http://bit.ly/theKanbanBook
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

This is one of my pet peeves actually. I am in the camp that believes most metrics should be used to provide feedback for the team, not so much the individual. Kanban, Scrum, XP, etc. are about teams and delivering products. I think it's improper to measure individual performance using things that are meant to be applied to teams. There are other ways to track individual work and I think those should be kept separate from the team process and the metrics around it.


Junilu - [How to Ask Questions] [How to Answer Questions]
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Marcus Hammarberg wrote:Oh no, that's no fast rule at all. You can, but you sure don't have too.


OK, so how does using Kanban help my coworkers know if I'm swamped, on a roll, or stuck? I think I'm missing something. I know that in a daily stand up, it's pretty easy since we're telling folks what we did, what we doing now, and if we need help. I don't see how that maps to a kanban board - other than cards backing up in one stage, or that stage being empty most of the time. What am I missing here?

Thanks,
Burk
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Junilu Lacar wrote:This is one of my pet peeves actually. I am in the camp that believes most metrics should be used to provide feedback for the team, not so much the individual.

Agreed. It strikes me as odd that most businesses I know about talk about teams, and team performance, but still base rewards, raises, etc on individual performance. Are you aware of any that actually do performance reviews at the team level only?

Burk
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

My company does both team and individual recognitions. As for reviews, those are still primarily on an individual basis but a lot of the input comes from your teammates. During our yearly performance review cycle, many of us are asked to give feedback on at least 3 other team members. Managers who are in tune with their teams will also hear about team members through informal channels so they get feedback, good and bad, in many different ways. Granted, these may not be the most objective way to measure performance but they're not the only ways either. We set up goals for ourselves and track our progress against those goals, with regular quarterly reviews or 1:1s with our managers. The point is that individual growth and performance are not tied to what we do as part of an agile team, at least not directly.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Actually, after thinking about it, I do know of several large companies that look at more than just individual performance for yearly reviews. They include the performance of the company itself, the division, and group the employee is part of.

Having feedback from peers is very important in my opinion because the folks we work with tend to know more about what we do and how well we do it than most managers. OTOH, developers often have a different idea on what kind of things to measure than managers do.

I'm curious about the goal setting you mentioned. I'm used to seeing goals be tied to skills needed for upcoming projects. The problem is that when the project needs change then the goals may no longer be relevant. How does your company do it?

Thanks for sharing with me,
Burk
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

We have individual career growth goals and goals that contribute to your managers' goals, which contribute to their managers' goals and so on. What I like about my company is that I have very few goals that are project-specific -- goals are mostly about contributing to your manager achieving his/her goals and growing your career. I guess we take project-related stuff as a given: you are expected to get your project stuff done but what else are you doing to improve yourself and become a bigger asset to the company?

But coming back to kanban, it makes me wonder if there is some kind of similar mindset there. If kanban is about improving process, does it have a narrow focus or does it help you take a more "systems thinking" view? One problem with immature teams is that they often don't know where to start making improvements. They can identify a multitude of things that they need to improve but have a hard time deciding where best to start so that they can see results quicker and get the most out of their efforts. Is this something that the book touches on? That is, does kanban help develop systems thinking, looking at things more holistically (e.g. at the team or group level) vs local optimizations (e.g. individual performance)?
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Junilu Lacar wrote:But coming back to kanban, it makes me wonder if there is some kind of similar mindset there. If kanban is about improving process, does it have a narrow focus or does it help you take a more "systems thinking" view? One problem with immature teams is that they often don't know where to start making improvements. They can identify a multitude of things that they need to improve but have a hard time deciding where best to start so that they can see results quicker and get the most out of their efforts. Is this something that the book touches on? That is, does kanban help develop systems thinking, looking at things more holistically (e.g. at the team or group level) vs local optimizations (e.g. individual performance)?

Well, Marcus has pointed out before that one of the benefits is making the work visible, so you can see where the bottlenecks are. If cards are stacking up someplace then it's something to look at.

The board becomes a dynamic model of your process. If someone's on vacation for a week you should see a slow down in the areas they normally handle - or someone who can afford the time may notice and jump in to keep things moving. At least that's my understanding of it.

Burk
Marcus Hammarberg
Author
Ranch Hand

Joined: Aug 07, 2013
Posts: 41
    
    5

Junilu Lacar wrote: If kanban is about improving process, does it have a narrow focus or does it help you take a more "systems thinking" view? One problem with immature teams is that they often don't know where to start making improvements. They can identify a multitude of things that they need to improve but have a hard time deciding where best to start so that they can see results quicker and get the most out of their efforts. Is this something that the book touches on? That is, does kanban help develop systems thinking, looking at things more holistically (e.g. at the team or group level) vs local optimizations (e.g. individual performance)?


Hi Junilu,

thanks for your questions. The thing with kanban is that it doesn't really care or is limited to the personal or team level. It will reveal your "improvement opportunities" to the level where you apply it. If you apply it on the team level you will start find ways to flow work faster through the team pretty soon. What often happens though, is that after awhile you'll reach the limits for you team, and will have to start interact with and improve outside your team, with other functions or people

For example, let's say that you have a separate department doing deployments. If you start flowing work through your team fast, you will still end up waiting for the deployment department. The focus on lead time (the complete time from idea to production) will be slowed down by waiting for the deployment department. This is now your next problem (oh sorry improvement opportunity) to solve to gain even faster flow.

Kanban sadly don't have any patented one-size-fits-all solution (nor should you trust any method that claim to have so). Kanban simply showed you the problem, by focusing on shorting lead-times. What you do about the problem is what decides if you will improve or not.
For awhile i called kanban for "problem finders" because that's all they really is. They show you problems. Problems that, if you fix them, will help you improve.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Marcus Hammarberg wrote:For example, let's say that you have a separate department doing deployments. If you start flowing work through your team fast, you will still end up waiting for the deployment department. The focus on lead time (the complete time from idea to production) will be slowed down by waiting for the deployment department. This is now your next problem (oh sorry improvement opportunity) to solve to gain even faster flow.

I'm curious, have you ever run into a situation like this where the external team had it's own priorities and schedules, and was not willing or able to become more agile? How would you work around something like this?

If it's just the production deployments, then you could have them deploy whatever the latest version was. They might skip over one or more, but at least the most up to date on would go out each time. But, if you're waiting on deployments for QA then it's a bigger issue. Any ideas?

Burk
 
wood burning stoves
 
subject: Kanban and individual status