Shim asked me about how Kanban helps manage multitasking, and this is my response by way of trying to demonstrate how it works. Leave a comment and tell me what you think or if you have any other questions I can answer.
Hi Josh, first of all I''d like to congratulate you on the the method and delivery of the video, it''s an excellent way to convey information. I''ve listened sometime ago to a TED presentation by Chris Anderson, titled "How web video powers global innovation" where he talks, amongst other things, about the power of YouTube to deliver information in manners not previously possible and to an audience that in the past might not have been able to tap into this information. So, well done.
I can see the practicality of using the method you demonstrate and wonder though about the practicality of that when dealing with resources who are allocated to a number of projects simultaneously or development resources who have also some level of support responsibilities. I guess there are two points here: 1) it is the responsibility of individuals to apply common-sense in the way they utilize their time and how they allocate it to ad-hoc (what you interestingly call ''drive bys'') requests; and 2) it is the responsibility of management to assign clear and unambiguous priorities so it does not put people in jeopardy when attempting to allocate their time correctly.
Thanks again, Shim.
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
Thanks for the comment Shim!
On support/distributed staff, it seems to work even better for me than dedicated staff. Let me explain.
On one of my teams, I have a DBA allocated 20% or so (fluctuates) who also works for other teams. In his case, he really liked the way I was doing personal Kanban and so he created his own personal Kanban to help him wade through all of the adhoc requests he gets. So in his case, we only have his tasks specific to my teams on their respective Kanban boards.
I also have a DB architect who is usually more like 50%-60% allocated to one of my teams, but also supports the other groups too. In his case, he preferred to put all of his work on our team Kanban, which was fine with me in this case. (It''s a small team, and a highly DB-focused team, and I manage a team for other subsystems which also uses his time.) So in his case, our team Kanban board is also his personal Kanban board.
On another project team I manage, other groups will negotiate time from some of my developers to work on other important projects and tasks. I keep these negotiated allocations on the Kanban board. I''m essentially helping to manage their workload and focus, even if I''m not responsible for the adhoc work they might do now and then. It allows them to focus on one thing and get it done, and I don''t bug them with our teams'' project work until I know they are done with the adhoc request (because they move it to ''done'' and pull another story or task into WIP - it''s a self-organizing or self-initiated work flow - they don''t wait for me or anyone else to tell them what to do).
So, it''s very flexible and can be used in various ways. I hope that''s helpful and illustrative!
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
