In 2006, my first kanban based project involved setting up a Personal Kanban for a team of 12 developers. Since we were just starting out with kanban, we had no idea what to expect. I did know a few key things though.1. I wanted the customer to have real-time information about what was going on2. I wanted no more status meetings3. I wanted no impedance whatsoever between my development team and the customerSo, we did the following:We set up a kanban in Groove 2.0 (a collaborative platform developed by Ray Ozzie) and shared that with our client. This meant that our client could see our kanban any time they wanted.I gave my client full access to all my developers. In other words, anyone from their side could contact anyone from my side any time they wanted. They were on our chat rooms, they had our Skype addresses, they had our phone numbers. Any time the client wanted access to anyone or anything at Gray Hill Solutions, they could have it.I allowed the clients to come to our daily stand-up meetings and fully participate. They directly participated in the selection of work, the phasing, and its constitution.The upshot of this was that the customer has, through the kanban, a real-time warning system that we may be doing something that required discussion. The fear - of both my developers and the client - was that this would create endless discussions and nothing would get done.The opposite happened.The client understood where we were and what we were doing. They could look at the product any time they wanted. They could see the kanban. They attended the 15 minute meetings so they knew of any challenges we were facing.Additional conversations were rarely necessary - because everyone already knew.The kanban itself gave the client and the team such a high fidelity of information, all we ever needed to talk about was real changes in the backlog or design decisions. In other words, all we had to talk about was value.