How to do R&D effectively in kan-ban(Agile)

In this article we are going to learn some tips and tricks on doing R&D tasks in Agile(mainly in Kan-Ban).

By the main principle of kan-ban, we know that kan-ban is all about quick output. But, in a Research and Development task, how to increase the throughput. Typically a Research and Development task contains unknown tasks, unknown scenarios, unknown challenges so it becomes unknown time line. SO, how can we handle those. If we apply some tricks , then it will be very convenient

-Make a statement as the goal of the r&d task(i.e- if you are doing r&d on intregrating webservice in iphone app, define like "To do some task Using this particular webservice")

-Make some defined user scenario as output of the r&d task(i.e- like as previous example, user should be able to do some task using this webservice)

-keep a target of minimum 4 hours , maximum 8 hours for providing/showing output. This is important, without target a r&d task can take a very long time. This output may be not useful, but it is necessary to keep getting the output. It does not mean with in 4/8 hours full task will be completed, but a partial implementation can guide next steps of r&d. After 4/8 hours , the r&d result should be shown with other group for feed back. That can insert new ideas and shows progress of that tasks. Typically group of senior members can provide great feedback after a span of r&d task.

-Choose The right person. Typically , type of task will define to whom to assign. But, a person with better search & find experience , will be the right person. Because of that a senior person(either developer/sqa) should be the ideal candidate for a r&d task.

-Avoid pair programming in R&D tasks. This was very interesting finding in my working group. Usually , pair programming was practiced in our group. But, when it comes for a R&D task, the output was less then single involvement. The thing happened that , while doing R&D, a pair may feel boring as the navigator always thing in pair and the driver had nothing to work abut. But, some cases, a pair can transfer knowledge of the R&D task better way and provide more dimensional opinion in the task. So, In my opinion, it is better to decider where it is pair or not, let it define on the criteria of a task. Generally, adopting new technology R&D done in single way and problem solving R&D done in pair way.

-Encourage the r&d members to write blog/article/slide with demo for the rest of them. This provides very quick outcomes and personal interests.

-Perform a quick review schedule(after every 2/4 hours) by same grouped senior members. That can boosts up the process speed.

-Encourage and provide feed back on daily stand up meetings

To day, Up to this. I will try to provide more ideas incrementally.

No comments:

Post a Comment