Processclerosis

I began working with a customer rather recently whose line of business is software development for very large banks. my relationship with them began with a training course on lean-agile project management that led to coaching. 

They were very happy and proud to have reached CMMI L2 one week before I began working with them.


The CEO agreed with my recommendation to bring Kanban in and after two days of training we began working on a new, small project. As result of their new CMMI status there was an executive decision to display large posters with their current processes throughout the company to bring visibility and ensure everybody followed process.

I decided it would be good to begin with the creation of an actual Value Stream Map for the project. The team created it based on their CMMI process, as expected, and discussing the action details for the project.  The resulting VSM is shown below. The orange cards are the steps, the blue cards are one per stakeholder, and the yellow cards are actions; so we have 8 steps with between 4 and 9 stakeholders per step and between 3 and 17 actions per step. In total there are 90 actions.

Most of you might be thinking something along the lines of "wow, is that a small project?" I was equally puzzled so I asked one of the team members to explain it all to me (I was at a meeting with executives while the map was being created). What called my attention from her explanation was that only two of the action cards actually had to do with coding! There were a few other technical actions but over 80% of the actions had nothing to do with the project itself and everything to do with process. As in, non-value-added process.


I decided to guide them through questions to help them realize the tremendous amount of waste they had but nobody in the team, including the manager, saw an issue with their process. I then asked them how long it would take to do the coding... and they said it would take at most 30 minutes (their bet was 10 minutes). So we have a 90-action process that requires up to 9 stakeholders for a customer request that takes at most 30 min of technical work.


It was clear then that they were still high from their recent CMMI L2 accomplishment and weren't seeing the obvious so I asked them to create a Kanban board and use it to manage the project flow making sure to quantify their actions from day one. This meeting took place on a Tuesday and the intention was for the project to be done by Friday or Monday at the latest. They revealed that some DB work also needed to be done and that would take several more hours of work so it appeared as if the value-added work was to take in reality less than one day. My recommendation was to get the information as directly as possible from the customer, implement the code with the proper testing and deploy it. Their CMMI process should've considered lightweight solutions in agreement with the size and complexity of the project instead of having a one-size fits all process.


I had one remote meeting a few days later to see if they had finished and to use the quantification gathered to help them realize their process needed improvement. But they hadn't even written the WIPs on the Kanban board, which we had already determined, and even less using it because they were focused on just executing away. This showed how the company is yet to properly use tools and methods and how and what they had accomplished with CMMI was being seen as an after-the-fact formalization to comply with governance. The second meeting took place three weeks later only to learn that they have 82 items in backlog and 26 in progress and 3 finished --new action cards were created. Then they made the mistake of changing the Kanban board to look the way they want things to happen and not the way they are actually happening, and the clear opportunities for improvement were being lost by their decision to remove the columns where delays were happening. I had a long conversation with them to modify the Kanban board and to work on those improvement opportunities because their delays were precisely due mostly to them and if nothing was done then the small project is going to end up taking over a month! The quantification gathered so far showed very clearly the high level of waste by the large number of actions yet to be processed and the long cycle times.

I emphasized on the need to make sure the Kanban board is a mirror of their reality and that by removing columns they were letting go of amazing opportunities to better the quality of their work and the lengthy cycle time. Most importantly, they were ignoring to consider everything that's happening around the board, their decisions and actions, or lack of them, and the impact it is having in both customer satisfaction and the economy of the project.


Quantification began 8 days late, when the project was expected to have been done. There are plenty of opportunities for improvement, some very important ones related to their customer, but internal changes need to happen first before they can talk to the customer and make agreements to improve.

Note: I Had the opportunity to show the VSM photo to Hillel Gazer and he commented that this is a very common problem in  organizations that do CMMI and the problem is due to a combination of a poor understanding from the organization and in good measure because maturity evaluations are often done by-the-book instead of based on understanding to help the customer do it right.


I'll write an update as this project develops and how the company matures.

--- Update: as of Nov 4, 2011 the project is far from finishing. The company indicated over a skype meeting I had with them that the delay is because customer approval is the bottleneck. They are not being proactive towards helping change behavior even when now they count with data to present their customer the economic impact this is having for everybody. Curiously, they themselves are reluctant to change and seem to want Kanban to magically improving things without any changes.