5

I'm new to kanban and agile as such but I'm really positive and enthusiastic and I have a clean vision of it's potential for us. I made a decision to start off with a first board and take it from there. Let's visualize and understand ourselves...

I always thought that the development work in the company I work in is a pure CHAOS. Dozens of small (10 - 30min) to medium sized projects/requests thrown at you on a daily basis from a range of (6) product managers / directors of a sort + direct request from customers + customer services girls and data team having their issues.

Priorities change every second day with super urgent tasks requested for end of play tomorrow.

There is 6 of us in the team and each one has got his own niche overlapping each other only from time to time.
There is no such thing as testing the software before deployment.
The developer is pretty much responsible for delivering a working piece of software.
Bug fixing and maintanance is part of the job (actually it's probably more than 50% of the job unfortunatelly).
Big projects just take ages to complete and tend to generate a great backlog.
There is never time for automation, however hard we try and whatever good ideas we have. Technical directors were not helping us (3 of them in the last 5 years).
We are self-organized fire-fighting chaos. Thank God there are still 2 people who's been building the product from the very beginning (8 years ago) - me being one of them. It would be critical otherwise.

Last month I've read Personal Kanban by Jim Benson and I knew it's it. I knew I've got to try it ASAP with my team. You just can't get it wrong, can you? ToDo, Doing (55), Done and bang - you've got board with WIP limit, you can see the flow, you can improve it. Then I was polishing my vision and couldn't fit the board to match us. I just couldn't find the common denominator for each and every team member. There is no such thing as quota for us - the task tend to be thrown directly to the junior developer (by the technical director) etc.

Today was the day when I drew my first kanban board in the office. And I can say I'm not too happy with it. I've done something that I feel is slightly wrong, but I stuck to the idea. This is what I've done:

Backlog | Ready (6) | Who | Today | Doing (2) | Pen | Done

    |         | Bob |         |           |     |       
    |         | -----------------------------------------
    |         | Rod |         |           |     |       
    |         | -----------------------------------------
    |         | Jay |         |           |     |       
    |         | -----------------------------------------
    |         | Jim |         |           |     |

The first main reason I've drawn it like that was that this is basically how we work:).
The second main reason why I've done it this way is because I don't know how we work.
I don't have a clue how many small maintanance 15-minutes jobs we're doing on a weekly/monthly basis and how does it relate to the new features that are improving the product.
I don't know where the job is usually coming from and what are the 'classes of service' distribution or who is the best multitasker etc.

So I have also itroduced a rather-sophisticated post-it notes system with 7 different class of service (different colours and shapes) and some extra bits to be added on the very card (like the source of the task). I thought that it can't be wrong this way. I'm visualising the work. Not so much I've limited the WIP (it's limited to 2 tasks for each member on the doing column; also the Ready column is limited to 6 tasks - for better planning), but I'm going to focus on completing the once started tasks and limiting the multitask switches (what I have identified as the number one disease that's killing us).

The kanban system will evolve, I'm sure of that.

But the goal I want to achieve is to measure the our team's throughput.

I'm planning to go with the board measuring individuals' efforts for 4 weeks or so. I want to identify and understand the input interface. I want to learn about the efficiency of each members on particulart tasks etc. I need to understand what percentage of the throughput is used for maintanance and bug fixing. Only then I will be able to make a really big step towards improving the process (and not only among the dev team, but a bit higher too).

So, is that a really bad approach? Can you suggest an alternative one? Perhaps it would just be better concentrating on the team effort as a whole from the day 0 and measure the input interface on the team level.

Improve this question
3
  • 3
    What exactly is your question here? More importantly, what's your goal for implementing whatever it is you're trying to do? Please focus on one question, and make it obvious what the goal is.
    – Todd A. Jacobs ♦
    Commented Mar 19, 2013 at 4:02
  • Thanks for the piece of advice. I have edited my question to make it more clear and ephasize the goal. It's the uncertainty that drove me to ask the question(s) and it was rather expressing my thoughts than asking for advice.
    – Tytus de Zoo
    Commented Mar 19, 2013 at 9:11
  • You have a good start here, and some good answers. What would really launch you guys into efficient operation and seriously reduce your blood pressure would be to convince the powers that be that you need a Scrum Master (or equivalent facilitator for non-Scrum agile processes). Even if you were only able to borrow one periodically and not full time, I have seen the difference a good SM makes in your team's situation firsthand.
    – JBiggs
    Commented Apr 8, 2019 at 16:13

2 Answers 2

Reset to default
4

It is not unusual, unfortunately. I work in a similar environment now - we, as a team, do not use Agile or Kanban methodologies, but I do. I will recommend a book which is more of a direct relationship between software development and lean concepts - including, in a small way, Kanban. I also recommend the video from one of the creators of Scrum - one of the more popular Agile frameworks.

Given that you work in an environment where priorities change often - including the injection of new high priority tickets - you should probably include a "fast-track" notion in your board.

I know you said you don't have a way of doing testing before deployment; however, this concept comes more from the waterfall methodology. I would recommend, if possible (it's usually not difficult to set up), writing unit tests before you do development. Don't worry about trying to put it around everything you've built in the past, only new tickets (a.k.a. Test Driven Development). This should dramatically reduce the number of defects released into the wild, and allow you to better see the impact of changes made due to the code being coupled in some way.

In an effort to measure your team's throughput you will probably want to add a method for estimating task durations (or level of effort) - I use time, but there are a lot of various methods - try a few and find what works best for your team. To measure just the team's throughput, you want to measure the time it takes to move a ticket from the backlog to done, as well as the average times an item spends in a given column. This will give you a better understanding of where you are as a team. So, having a "creation date" on the card, a date of when the card enters each column, and an "average time in column" indicator under each column might help you in the data collection department.

Having said that, if you do not have a basis for estimating a ticket's level of effort, knowing how long it took to move through the board will not be very helpful. If you get a bunch of little tickets that move fast - then you have a false team velocity, which will appear to slow dramatically with the first more complex ticket.

A piece of advice outside of your main goal, would be to begin thinking of a method/policy/process for the team to discuss what the hang-ups (impediments) are: interruptions, changes of priority, etc. And, I do think the board will assist on this as well. I know some teams mark interruptions on the task with a red dot - and an interruption could include the changing of prioritization and shifting a team member from one task to another.

I think overall you are on a good track, because you are trying to put something in place to measure how life is, but the sister concept to that is how to get feedback and alter how life is in small ways, eventually culminating in a better way of life overall.

Hope that helps.

http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704

http://www.youtube.com/watch?v=IyNPeTn8fpo

Improve this answer
1
  • Thank you for your advice and the resources. I really appreciate it. I guess the most important thing is that the wheels are rolling now, the kanban board is in place and we talk about every morning. I took the note on the fast-track notion. I don't want to change the board too often and too early now. I want it to settle. We are adding dates and time to the tickets - now it's just important to load it to a spreadsheet and analyse the outcome. There is a lot of work ahead and a lot of books to read and videos to watch... thanks again
    – Tytus de Zoo
    Commented Mar 20, 2013 at 20:40
1

One core thing you might be missing is that Kanban should probably use Pull principle where you have a backlog with bunch of tasks - (does not matter what size they are (of course in time you should learn to divide tasks in such manner that all of them would be similar in size so you could measure you future effort)) - so that bunch resides on the left in board and then you have a pipeline with steps like ready, development, doing, pen and done. You do not need four different rows for each person, you should focus on limiting Doing column to 4 so it would mean that people take tasks when they are out of work and drag them into Doing.

Improve this answer
1
  • I have been thinking about the pull principle. I want to get there, however I just don't feel this is the right thing to do just now. The tasks in the Ready stage must be set up in the way that there will be something for each member so that whenever a current task is completed he can pull the next one from his 'pool'.
    – Tytus de Zoo
    Commented Mar 19, 2013 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.