Over 10 years as a software developer has taught me that investing in technical skill can only get you so far. In fact once I got to the “average agile developer” stage, further investment in acquiring advanced technical skills was generally waste. Despite agile leaders emphasizing the importance of technical excellence, despite the software craftsmanship movement desiring to see the bar raised rather than lowered, most companies are still making decisions based on the assumption that it is too hard to hire technical excellence, or that you can get more done with a larger number of lesser developers, with a lowered bar. Essentially they are quite openly and explicitly rejecting the premises of the Agile Manifesto, and Software Craftsmanship, in favor of the old Taylorist split between thinking and doing. Even places partially embracing certain Agile practices! It got to the point where management had no interest allowing the use of idea A, or technology B, or practice C, because “no one else knows how to do it” or “yeah but our tool vendor doesn’t support that”, or “I have never heard of that”, or “its hard enough hiring as it is, without restricting ourselves to applicants who know that as well”.
It has been very clear to me, that the issues impeding effective software development are mostly related to the management culture. Even at the technical level, decisions are made that prevent, or make difficult, the adoption of advanced technical practices.
Scrum goes a long way towards improving this situation. It is based on some ideas that really challenge the, what I call, Command & Control, or Taylorist mindset. To a certain extent at least. The concept of having a ScrumMaster as servant leader, facilitating self-organisation, and encouraging inspect and adapt, can really go a long way towards liberating team members from a demotivating work-life, and permitting them a larger degree of freedom to make at least technical decisions themselves. Unfortunately it is usually restricted to the team. The same wall that Scrum builds to protect the team from external influences, also prevents such radical ideas from escaping into the wider organization. The vision of ScrumMasters as organizational change agents, stepping outside the development departments, waving the Agile Manifesto around, explaining to sales and marketing experts that there is a better way, doesn’t seem to have had much effect. Particularly in organizations where software is not the main product, or only part of the product. Scrum works by making problems visible. However it is a fairly focused magnifying glass, only providing visibility to one little link in the value chain. The solutions too, are usually fairly specific, with limits on who can participate in the improvement process, and the optimizations can only be local. Typically a problem causes a decrease in velocity. Someone might get less of a feature on a certain date, or might get their whole feature a month or so later than expected. In the overall scheme of things, Scrum does a great job of shielding team-level problems from the wider organization, and shielding organizational problems from the team.
Kanban, when applied properly, across an entire value stream, does a better job of making team-level problems and organizational problems the same thing. Scrum is fairly mild when a problem occurs. Velocity goes down a bit, big deal. When a WIP limit is hit in Kanban, all of a sudden you can have an entire team either standing around doing nothing, or knocking on the doors of a completely different department offering to help. When problems occur in a (proper) Kanban system, the effects are much more radical than in Scrum. (Of course it is possible to do Kanban inside a walled garden, in a Scrum-like fashion, and not see such radical effects.) This is a good thing. All of a sudden you have a lot more people interested in the problem, and participating in finding an urgent solution. All of a sudden you have people talking with each other, that might not have previously communicated much. It sends shockwaves up and down the value stream, ideally affecting even the customer. In Scrum, it is too easy to say yes to customers. Write another story, and stick in the backlog for later. With Kanban your capability is staring you in the face. You are forced to negotiate with the customers. You are compelled to insist that they review, accept or deploy finished work (and free up WIP) before they can request any more changes. In the best case, your sales people have to face the exciting opportunity of helping to shorten lead times, by saying a simple “no” to customers! “No, sorry, our system is full, we can’t do that for you, but lets look at what we can do, and when”.
But Kanban is still not enough. If you start off with the typical Taylorist, Command & Control, low trust culture, perhaps with a bit of Scrum in the development departments, and simply throw Kanban in the mix, you will very likely make things worse. You will have a system for evolutionary change all right, but in what direction? Chances are the dysfunctional management culture will use the Kanban change mechanism to extinguish what little spark of agility did exist in the Scrum teams. Kanban, like Scrum, is great at identifying problems, but leaves the solution space fairly open. An unprepared management system, combined with the radical nature of the Kanban change management tool, will result in certain types of decisions being reached that will have far reaching, permanent negative consequences for motivation, lead time, costs, quality, ability to react to urgent situations, relationships with customers, overall level of learning for individuals and the organization as a whole, and relationships within the organization. The Kanban community intended Kanban to be used to make things better, but the typical organization will end up using it as a weapon against itself!
In fact I have observed the following occur:
- Cards spend much longer in the “development” column than in the “analysis” and “test” columns, so management assumes “development” is too slow, and requires more detailed time tracking, and imposes fixed budgets per item adding pressure to developers to work faster
- In a retrospective normal workers identify the potential communications benefit from cross functional teams (perhaps oriented on subdomains), asks management (who were too busy to attend) to implement it, management decides to implement teams specializing in technical layers (DB team, GUI team etc)
- Actual measured lead times look unattractive to customers, so management decides to ignore them and continue to promise delivery dates based on wishful thinking
- Management felt the transaction costs associated with user stories were too great in almost all aspects of the system (but great in development), so standardized on mini-projects as the main entity “flowing” through the system, lengthening the time it takes for developers to get feedback, and increasing the potential for waste, significantly
- Defining slack as “preparing for (i.e. starting without pulling) the next item to be worked on”. Stating quite openly “we don’t trust consultants to write tests” and basically laughing at the idea of allowing developers to be involved in customer-facing aspects of the process. “They might say something that conflicts with what is written in the contract, or make it sound cheaper than what we charged!”
and much more… The pattern was clear. Normal employees didn’t trust themselves to help improve aspects of the process that lie partially outside their area. Management didn’t trust normal employees to make decisions, and didn’t accept allowing them to be involved in the implementation of improvements.
Management were just making the same decisions, based on the same mindset that they always did. Kanban forced these decisions to be made quicker, and under the pressure of more urgency. Motivation and relationships deteriorated significantly. Management openly rejected the idea of moving to a high-trust culture, claiming it was never discussed as part of Kanban, or a goal of Kanban. Kanban was supposed to make the software get developed faster and better, reduced lead times right? No one mentioned anything about we managers having to change anything, or anything about culture at all, so we will continue to work how we please, and “you” will use Kanban to get things done quicker.
But this is all fair enough. They were correct. You can’t blame them for thinking like that, as that is how Kanban was “sold” to them. We had 2 initial workshops with well known consultants at the beginning. We discussed our goals. I was the only who mentioned cultural advantages, like:
- Having our development department and project department working closer together according to the same (ideally agile-like) mindset, rather than having one department working according to a waterfall like process, and another one working (at least to a certain level) according to Agile values
- Increasing motivation by allowing people too not only see how their work fits into a wider value stream, but allowing them to actually get involved in other aspects of it
- Enabling and encouraging employees to take on more of the collaborative decision making process, at the level of actual work (e.g. standing together at the board discussing what to pull based on business value etc), and in improving the process itself.
Everyone looked at me like I was from outer space. I think we settled on things like shorter lead times, reduced costs, and better quality as the goals.
I seem to remember going over the first 4 core properties of Kanban, and skipping over the 5th. I also remember being concerned about focussing on the use of Kanban as a static tool, moving cards around the board etc, and I actually asked if we were also going to discuss about what sorts of actual changes we could expect, how they might come about, and whether Kanban can truly stand alone as a useful tool, or would we be better off looking at it as if it were part of some more fundamental effort to improve the management system. I was told the focus would be just on Kanban, and we would not be addressing those points. Even then I had concerns about what this would do to our organization. But you can’t blame the external consultants either. They didn’t know us, they didn’t know what challenges we might face, or how our culture would react with Kanban. They were also under commercial pressure to deliver something that would be accepted by those making the decisions and paying the bills. If they turned up to the boss and said “yeah Kanban is great, it will completely turn the organization upside down. Problems will smack you in the face and force you to confront them and come up with solutions over night. Normal employees will have to be trusted with decision making, management will have to step back and remove impediments, and focus on improving the system according to the ideas of Deming, Ohno, Goldratt and others, forget about detailed project plans, that wont work anymore. Forget about your strongly batch oriented process that you push work into without considering the system capability, Kanban will exert strong pressure to change to a flow based process, and you will have to start saying no to customers to avoid stressing the system, compromising quality and demotivating employees. Oh and you will have to trust the employees more too”. The boss would have said, “I thought Kanban was a cooler type of Scrum, and change was optional and evolutionary. There is no way I want to pay you to deliver that kind of disruption”. Nope. The consultants shrewdly identified what our culture would accept. I think I remember the old “Kanban can be introduced in any culture, and a high-trust culture will simply emerge” line.
What was missing? Kanban can’t be applied to an entire value stream in a low-trust culture on its own. Maybe the consultants didn’t know that, maybe they did. Without paying some attention to issues of culture, and the management system, in addition to applying the mechanical aspects of Kanban, you are severely limiting your chances of success.
Rightshifting is one approach that should always be mentioned as the context in which Kanban can be used to improve the effectiveness of an organization. There are other ideas. Some are fairly old ideas, a little abstract, like Deming’s System of Profound Knowledge. Or more detailed and concrete approaches like Beyond Budgeting. I feel like Rightshifting, and the Marshall Model of Organizational Evolution hit that sweet spot as ideal companions to the tool of Kanban. I won’t try and interpret or regurgitate things here, instead I will urge you to go look at the original material on the topic. In fact I am a beginner myself when it comes to understanding and appreciating the power and utility of these ideas. I have heard about them a while ago, and been only loosely following them since. But recently I have come to think about things and realize I need to pay more attention to what is happening in this area. I think I heard once that you can’t change culture, all you can do is change the management system, and the culture will follow. I interpreted this to mean, it doesn’t make sense to pay attention to things like culture directly, and I lumped mindset into this too. Instead we should simply pay attention to the management system, e.g. things like Kanban, and culture will hopefully follow. There was one thing that didn’t occur to me though. You can change the way you think! The mindset is not part of the not-directly-changeable culture, but it is a basic part of the very-much-changeable management system. Seems obvious, but it really freed me up to pay more attention to a wider set of dials that can be adjusted in the organizational context. The other thing was, and I kind of hinted at this above regarding the futility of a ScrumMaster waving around the Agile Manifesto in the sales and marketing department, and I also experienced it when talking to managers about the direction we wanted to let Kanban take us in (I said we wanted to go in an “Agile” direction, but the managers saw that as being a very software development thing of little relevance to them, who were managers involved in creating products in a domain where software was just a part). I desperately needed a way to communicate where I thought Kanban should take an entire organization, independently of software development. I needed something that addressed the mindset that I guess “Agile” is a software specific realization of. The Synergistic Mindset was exactly what I was looking for, and it can be directly addressed as a new way of thinking. From now on I don’t think I can responsibly talk to teams or organizations about Kanban, without first framing it in the larger context of improving effectiveness by addressing necessary changes in the way we think with the help of the Marshal Model. I think it is exactly the type of model they had in mind when formulating the 5th core property of the Kanban method: “Improve Collaboratively (using models & the scientific method)“
So. How do we learn more about this, and other similar ideas? By getting involved with the Stoos community and attending Stoos conferences. They won’t just be discussing rightshifting, but also things like Beyond Budgeting, Radical Management, Complexity Thinking, Servant Leadership, Management 3.0, you name it. Pure gold for anyone expecting to actually take on Kanban the way it is intended, and expect significant positive results, particularly in an “unprepared” cultural environment.
The main central point for the Stoos community is the LinkedIn group: http://www.linkedin.com/groups/Stoos-Network-4243114
There is also a main site that explains what it is about reasonably well: http://www.stoosnetwork.org/
There is a small get together here in Germany soon, the StoosXChange (I will not be attending this one though): http://stoosxchange.org/tiki-index.php
I will attend the Stoos Stampede in Amsterdam: http://www.stoosnetwork.org/stoos-stampede-amsterdam/
In fact as a manager one of the main parts of your role in the future, as well as designing systems and removing impediments, will be attending events like these. There won’t be too much in the way of concrete “best practices”, as everything is context dependent. You wont be concerned with detailed project plans, or allocating “resources”, or controlling costs. You will be engaging in a community of like-minded professionals, gathering a toolkit (or more accurately a valuekit, or principlekit) of diverse types of ideas, and learning how to experiment yourself, in collaboration with other participants of the system you work in, and coming up with your own tools.
And the world will be a better place for it.