Have you ever found yourself in accidental Kanban on software development project? When the developer is efficiently managing his own WIP (Work in progress), and driving forward changes without clearing with the business? Not ideal, as a manager should be dealing with the WIP, and changes to plan should be by consesnsus. Developers like this don’t grow on trees, so there has to be a way of designing new processes (process fast becoming a dirty word, but as yet no effective substitute) to steer projects on a Kanban course.
Kanban introduces improvements in momentum and sustaining that momentum. It is a methodology for managing CHANGE – it is not a project or development methodology. As with any methodology, the simplicity of the fundamentals belies the underlying complexities. Managing WIP cannot be slapdash or applied weakly. Software development has careered forward in wake of Agile, and took hits on quality. With stakeholders and developers (supposedly) more actively testing, testers became an almost endangered species at some points. With shorter, smaller scale web projects, sometimes testing was victim of budget or time constraints. Quality is not omitted as a default, but degrees of success can be achieved without dedicated test resource, even on badly-run projects. In manufacturing this would not be possible for long-term (even short-term) survival.
Quality Assurance has long been in manufacturing industry, and carries weight at every stage of the process. In the thinking of end-to-end path to product from requirements, QA transcends industry – but for some reason, despite it’s lucrative nature, software development remain in a delivery-panic mode. The holy grail became how to make products as quickly and as marketable as possible. In the efforts to shorten the journey there have been compromises, mainly on quality. Though “We have had to cut the testing budget” sounds a lot less alarmist than “We have had to increase risk compromising quality”. I used a similar style recently, when defending case for proper validated HTML and CSS code (traditional back-burner task). In response to pushback I said “OK, so we are all happy with not fixing the invalid code, that may also be causing performance issues?”. OK, melodramatic, but I was just making a point.
With Lean IT, you can streamline development to be relevant and efficient – and Kanban is very effective way to manage the development cycle. Kanban ensures that rules are in place to streamline flow of requirements to code to production. It is oriented around concepts of ultizing your resource and skills, without overusing them. The review and improve in continuous flow is essential for this to work, and therein lies the biggest challenge for IT with Lean methodologies.
What struck me most about Kanban was in the implementation challenge, within different country and work cultures. The UK, along with others, had problems with the Agile ethos, and that was due to many cultural factors. For instance, there is a general lack of openness and transparency in British business. So concepts of learning through mistakes looks logical, but implementing it in a culture where failure is to be avoided, and In the US, they tend to have a more team-oriented way of thinking. Communication is a big deal in Lean and Agile thinking, and it’s importance and definition varies from country to country and industry to industry. The trouble is we can still get away with a lot in software development, and I speak from experience in development. To produce code of quality and robustness is difficult to demonstrate to the customer – it has no instant gratification for someone who will judge based primarily on what they see. But the customer can have visibility of the processes that transfer what that ask for, into end product.
What Agile suggested with a nudge, Lean/Kanban drives home with a sledgehammer – transparency, communication, adaptability.