5

In our team all task's steps are always done by the same developer. I.e for task 1, person A does design, development, and testing; for task 2, person B does does design, development, and testing, etc. Does it make sense to use Kanban in this case?

1
  • 4
    You can still use kanban so you can see progress, and keep the person limited to 1 task. However, having the same person do development and testing is a recipe for disaster.
    – CaffGeek
    Dec 28, 2011 at 18:05

2 Answers 2

6

I would suggest still using Kanban by slightly changing the process:

Person A does design            Person B does design
Person B Reviews A's Design     Person A Review's B's design
Person A does development and   Person B Does Development and Initial Testing.
initial testing
Person B QA's person A's work   Person A QA's Person B's work.

Putting all tasks with 1 developer as Chad pointed out is a recipe for disaster while not in the initial stage but most certainly down the road when maintenance on the project would be required.

1
  • I would also suggest to add "writes unit tests" step along with the development. It is also a good idea to clarify what your done-done state includes (is it done when qa is done? or will it require documentation after all? will it require to be integrated as a part of done?) having clear picture for each state will help you to gain more from Kanban.
    – Paul
    Dec 28, 2011 at 23:08
0

To some extent, we have to answer with "...that depends." I personally like to start with Dr. Phil's "How's that working for you?"

There are some basic 'bumper's' to keep you on track, by that I mean best-practice and/or kanban practices.

As others have mentioned: Best practices is that developers don't test their own code. I think everyone agrees on that.

But the other is to reduce WIP, and move code to DONE. In agile, there is no such thing as "development done". Code is done when it is developed, tested and approved. Anything short of that is "In Progress".

Kanban is all about VALUE FLOW. It forces focus on "getting work done", by contrast with having a lot of "work in progress". Therefore, teams are HIGHLY encouraged to swarm work.

The Design, Review, Develop, Test, Approve steps mentioned overlook the fact that development may include many steps, some of which can be worked simultaneously by different people. (Not in all cases, granted)

I like to point out to my teams the difference between a single-threaded process, in which jobs must be done in a serial manner, compared to multi-threaded systems, where jobs can be done simultaneously. Developers seem to easily understand the difference in processing power using that analogy, and helps guide them in the next steps.

Kanban metrics include Cycle Time and Touch Time. Cycle Time is the total duration from the moment the work is started until it is DONE. Touch Time is how much time it took to get it done, and can be the summed effort of all resources that touch the task.

The objective is to increase value flow in every way possible, and this will result with a reduction in these metrics that demonstrate gained efficiencies and increase throughput.

Therefore, it is more efficient to multi-thread (swarm) the process and reduce the cycle-time.

Example: A task has 20 hours of work across 10 steps. If one person works each task in serial manner, 8 hours per day, without any issues, the job can complete in 2.5 days. Cycle Time = 2.5 days, Touch Time = 20 hours.

Same task, evenly swarmed. Dev 1 does 10 hours of work, Dev 2 does same. Cycle Time =1.5 days, Touch Time = 20 hours.

The task is ready to approve in 1.5 days compared to 2.5 days.

So in your example, it makes sense to use Kanban in the case you described, but the process you described could be improved to increase efficiencies and quality.

*If anyone sees any flaws in my logic let me know!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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