I discussed the “Boundaries of Kanban” with Markus Andrezak in a past podcast. Most people always want to expand the boundaries of everything they talk about. So, I had to ask him, “What are are the boundaries?”
Related Podcast and Transcription: The Boundaries of Kanban
An excerpt from the conversation:
Markus: What happened was that the team was working perfectly well in Kanban but they always had a conflict with the designers coming up with a new design for the new website. What I saw was a tremendous conflict between the production oriented mode of the development team, we want to make better Lean time, we want to gain efficiency, and all that with conflicting targets that the designers had that needed some depth. They needed to understand all the constraints of the website, all the constraints of the users, and they never knew if the next phase they’re going in is diverging or converging so what I saw was a conflict of the completely non-linear process with the designers conflicting with the developers who are going for a very linear approach. Why I’m telling you this is because this has really led to scenes basically where people were really arguing in front of the Kanban board and this really made it very transparent to me that the whole problem that we have at least two worlds we have to combine in what we’re doing as companies and systems.
Joe: And what are those two worlds?
Markus: How designers grow up is really digging into the problems and finding out what the real problems are, and they’re working in a highly multi-dimensional space of things, as an ex-developer don’t understand fully all of the time. If you look at the work it’s really coming up with lots of small, very small prototypes all of the time going into very, very different areas but what they’re trying to find first is not the solution, but trying to find the right problem to solve. Whereas the development world is always trying to find the right solution for the problem that is already found, so this is kind of a bi-section in the worlds.
Joe: So can I just make 2 swim lanes, does it work that way?
Markus: Oh no, because then you would be in parallel rather than sequential. There will be a time when the results of the design team will have to go to the developers and then you change face because then the design team has to be part of the development team. Again for the small changes, you could say micro-interactions in the UI or UX stuff. Really I think two parts of the world that we’re facing, which are not reflected in Kanban. For example let’s have two swim lanes as I said the work of the designers is really non-linear. What you see on a Kanban board is really a completely linear process. You always know what the next step will be but in design work you never know will I go back to an empathy phase, will I go back to interviewing people, will I go forward to ideation because I have my person already set up. So you never know if I go backwards or forwards in design work, so that’s really annoying to developers in a way. So swim lanes don’t help!
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook