Don’t Be Like Water, Be the Water
(white paper submitted to LeanKanban University for KCP)
You’re a task manager working on a project that’s slightly disorganized and frustrating. Your team isn’t complaining because they’re professionals but none of them are really happy. You could carry on with your current process without much fuss but you know your team isn’t operating at maximum efficiency. Sure they’ve formed, stormed, normed, and performed but they’re not performing the way you think they could and more importantly they think they could. Part of the reason is outside of your immediate control. You have authority over your team but you’re not at liberty to implement changes to the project processes or SDLC, which uses some kind of hybrid Waterfall/Scrum/Agile methodology. It’s not easy tracking the work down—where it is in the process, who has it, and how long it’s been there. Requests come in via email, during meetings, or through conversation in the hallway. You’ve got some tools at your disposal—a shared drive, SharePoint—and the possibility of adding an open source issue tracker and maybe an automated test tool but you know they aren’t the answer. Then one day you read about something called Kanban.
***
Don't get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.
Bruce Lee on the Pierre Burton Show
(https://www.youtube.com/watch?v=fHAUsN4PBrc at 15:36 mark)
In the fall of 2013 I took a Kanban Coaching Professional Masterclass with David Anderson. As we broke for lunch after a morning session it occurred to me that Kanban reminded me of Bruce Lee and his art of fighting (Jeet Kune Do). I mentioned that to David during the break. After lunch the first slide David showed was of Bruce Lee and he went on to discuss how Kanban was like water. The morning session no doubt led to my epiphany. Bruce Lee’s famous quote is informative not just for its content but for its own flow. In a matter of three or four sentences Bruce Lee’s suggestion to “be like water” became “be water”. In Kanban being the water is the beginning of a transformation.
The Art of Changing Without Changing
So you read about this Kanban method and realize you’re not going to be changing anything in the beginning. It’s like Bruce Lee’s art of fighting without fighting except you’re going to be practicing the art of changing without changing. You decide to follow the Kanban method. The first step you take is to map the workflow for one of the applications your team is responsible for testing. But then you decide you’re not going to just map your workflow. You’re going to include the workflow of areas outside your control. You include development and deployment. You don’t tell the development team what you’re doing. Not yet. You’re just going to be the water.
You’re not going to ask for any new tools either. You’re going to use what you already have. You configure SharePoint to work as a kanban board (See Figure 1). You tell your team that for this one application they’re going to have to use this board you put together. You explain the board and the idea of a pull system to them. You’re not changing anything, after all. You’re just giving them a new way of seeing the work. You update the board for the developers based on what’s planned for the next release. You ask your team to pull work from the Ready for Test queue into the In Testing queue and when it passes all tests you pull the work into a Completed Pending Approval queue. After a few days your team wants a board for the other applications. Just a few days. Not months. Not weeks. And you realize something has already changed.
You create kanban boards for the other applications being developed. Everything everyone needs to know about the status of the work is on the boards and the team recognizes there’s no need to have meetings about what they’re working on and where the work is in the workflow. You cancel all meetings except for one operations review meeting you hold near the end of sprints. You’re already getting leaner. The team has jumped into the water and started flowing along with you.
***
When I first encountered Kanban I wasn’t sure what to make of it. I thought well this is simple but is it too simple? You’re starting with what you do now and evolving incrementally. What could be easier than that? And you’re building trust. Maybe that doesn’t sound like an easy thing to do but if you and your team are conscientious, engaged in your work, focused on delivering quality, and you make and keep that promise to stakeholders then it’s not the most difficult part of the job. This trust is the key to making evolutionary (and sometimes revolutionary) changes for the better. If others trust that they’re not going to drown when you tell them to jump into the water then they’re more likely to jump into the water.
Limiting, Prioritizing, Balancing
You’ve got your team flowing along with you now. They see the value in actually seeing the work. But there are still grumblings from them about the requirements and development teams for some of the applications. It doesn’t seem that the requirements team knows what to prioritize. They’re trying to fit everything and anything into each release. Work is going back and forth and by the end of the release some of it is half-finished and half-tested because there’s a big push right before the release date to get everything in. Sometimes releases get pushed back. So you have a conversation with the requirements and development leads and tell them that your team can’t do all the work they’re asking them to do. . You remind them that your team is focused on quality and want to deliver the best product they can deliver that provides the greatest value for the client, and the way things are going that’s definitely not happening. You suggest that the releases occur every four weeks instead of every six weeks since less features are going into each release—delivering more often will avoid the perception that you’re not giving the client as much as you used to. The two leads trust you because you’ve earned that trust and they accept your recommendations.
So what have you done by telling them your team can only do so much work (can only have so much work in the In Testing queue at any given time)? Have you told them that your team is lazy? That you need more people? No. What you’ve actually done is limited your work-in-progress. Your WIP. And once you’ve done that, prioritization falls naturally into place. The other teams now have to prioritize which features go into the release. They don’t know that you’ve limited your WIP. They don’t know that they’re starting to get carried along by the water. You tell a couple of the developers about the board and ask them if they could start using it. They do because they trust you and after using the board for a few days realize how much easier it is to track the work and see the workflow. You’ve started carrying other people along with you.
***
Maybe it’s not easy to see how limiting WIP increases flow. But once you’ve decided to limit WIP it becomes apparent. Where work once piled up and created both a quantitative (increased unfinished work) and qualitative (frustration/apprehension) roadblock, in its place you’ll find a smoother and more harmonious workflow. After our team became involved on a project for the National Children’s Study working with a survey development team (CRIS), I mapped the workflow, put a Kanban board in place, and eventually convinced the entire team to limit WIP in various places along the workflow. The survey development team had never been able to finish any of the surveys because they always brought in new work before any existing work was completed. In the prior six months they had delivered zero defect free surveys to the field. After we became involved and convinced them to limit WIP they were able to deliver four defect free surveys in our first four weeks on the project and continued delivering surveys at the rate of one a week.
The Secret is Out
You’re visually managing all of your work. You’ve gotten your team flowing with you. The development and requirements team are flowing too but they don’t realize they’re in the water and that they’re also starting to become the water. They’ve started to prioritize their work because you’ve limited WIP. They’ve even magically started balancing demand from the client because they’ve changed the release schedule from six weeks to four weeks to three weeks and understand that in order to hit that mark they have to make sure they’re not taking on more than they can deliver. And most of this occurred because your team built trust and a decision was made to limit WIP.
You meet with the development and requirements lead to ask them if they like the way the process is working. You decide to tell them what you’ve been up to and why releases are being delivered every three weeks instead of every six weeks—on time and with improved quality. You show them the kanban board your team and some developers are working from. You explain how it’s become a unifying concept. How it’s broken down the walls between the two teams and how anyone can take a look at the boards and see exactly what’s going on. Nothing is hidden. You explain to them how the decisions they’ve made have improved the overall process and that you’d like them to start using the boards and the Kanban method also. But they’re a bit perplexed. One of them says that nothing’s really changed. The team’s just doing the work faster. You explain Kanban to them. Explain how they limited WIP without realizing it and the dynamic effects that one decision had on the development effort. They’re still unsure but they can’t argue with the results. You tell them that you’ll show them Kanban. They decide to use the boards and ask everyone on their teams to start using the boards. You’ve got them all in the water now and without having to get any directive or charter from the top. You’ve implemented change and process improvements from the middle—quietly and without incident. You have a meeting to explain Kanban to the entire team and reach consensus on the need to come up with some explicit policies. You tell everyone that the transformation isn’t over, that there are never solutions but only countermeasures to the multitude of issues that will pop up. You show them cumulative flow diagrams and explain how they can help identify constraints and how constraints can be dealt with in order to continue improving. You’ve implemented the Kanban method without anyone realizing it until it was too late and everybody is in the water with you. The company went from using Kanban in stealth on one software development effort to openly using Kanban on all seven of their software development efforts.
***
When I first introduced Kanban to management for the prime contractor our company subcontracted to on the National Children’s Study, they unfortunately got out in front of my effort and put up a large piece of paper on the wall outside one of the PM’s offices. I believe they wanted me to implement Kanban but I also believe I never really got the authority to do so. The board became my board of shame because no one used it. I hadn’t told anyone about Kanban and that Kanban itself was much more than simply a board. Eventually the large piece of paper came down. In the mean time I had mapped the workflow for all the development efforts occurring on the floor (each effort was slightly different and that was okay because Kanban accommodates these differences). I configured SharePoint to create a Kanban board for one of the development efforts that my team used. After a few days they asked for others. In less than a year Kanban was being utilized by all the development teams on the floor and they came to understand how the pull system and limiting WIP positively affected the quality and quantity of their work. And not only their work but their work environment. My team was less stressed. The developers were happier. Team cohesion and collaboration flourished. We had time (slack) to work on coming up with better ways of doing our work.
As Kanban became openly accepted on the floor I decided to map the value stream for the most important pieces of work produced by the organization for the project—a deployment package that consisted of five packages.
I mapped the current state value stream to show where in the process we might be able to improve and found areas (unfortunately outside our political control) where delays could be eliminated (See Figure 2). At the time of writing this paper the documentation team on the floor has requested that I map their value stream in order to determine where they can make improvements and to show them how to implement Kanban for their workflow.
At our company’s corporate offsite in 2013 I gave a presentation about Kanban and explained to them how Kanban works and how it worked on the project I was working on (See Figure 3). At our company’s 2014 corporate offsite I gave a presentation on Value Stream Mapping and how it can be utilized to focus a team’s continuous improvement efforts (See Figure 4).
The proposals for the last two RFPs our company bid on included the Kanban work we did on the National Children’s Study (we won both—one for mobile application development at one of the largest trade unions in the United States: the International Association of Fire Fighters and the other for functional testing/PM work at the United States Patent & Trademark Office). Kanban has started to gain traction within the company I work for. Moving forward I will continue to be a strong proponent of Kanban, explaining its benefits for projects, teams, and individuals. But the best way to show the efficacy of the Kanban method is to actually put it into practice and be the water you want everyone to jump into.
Figure 1 - SharePoint Kanban Configuration
Figure 2 - Value Stream Mapping
Figure 3 - Kanban Presentation
Figure 4 - VSM Presentation
value stream mappingKanbanThis
