I have been an Agile practitioner for many years now, and was one of the early adopters of Lean thinking and Kanban for software teams. During that time I have observed remarkable improvements at the worker level, at the team level, and at the program level.
However what I haven’t seen when using these methods is a real change in management thinking, which has left me curious.
I am fortunate that over the last few years I have been able to hear opinions and stories from a community of Agile, Lean and Kanban practitioners; in those conversations I have seen a pattern.
People tell me that having applied either Agile, Lean, or Kanban, or some combination of the three, it has led to great results at the individual, project team and program level, matching my own experiences. We see many of these examples being written in books, presented at conferences, posted on blogs and message boards. All good.
People then go on to tell me (usually in the corridors at conferences, or over a drink at the bar, or over email) that it isn’t as successful as they would have liked, because they have been hindered by management; they tell me “management doesn’t understand the benefits” or “it’s the fault of the managers not to get it“. There is lots of talk of “bloody middle management” or the “frozen middle (management)”.
I hear of many Agile, Lean, or Kanban interventions that begin at the team level, starting off successfully, but which then bump into management who either kill it, limit it, or do nothing to help improve it.
People complain to me that “the Product Owner never shows up to the planning sessions or standups” or that “the stakeholders and managers never show up at the product demos or showcases” or that “they just don’t understand what will happen if we don’t pay down some of our technical debt”, or that “the management have received training but their behaviour hasn’t changed, they still do what they used to do before”.
I’m told thing like “managers still want us to be seen as busy all the time”, or “management has promised it will be delivered on a certain date without consulting us”.
Even those Agile, Lean or Kanban interventions that have executive IT support struggle to go beyond IT. I’m told that “the business isn’t engaged” or that “the business can’t dedicate someone to our team” or that “the business just doesn’t understand the benefits this will give them”. They also tell me that “Procurement are hindering us” or that “Finance and the budgeting process is hindering us” or that “It doesn’t fit within HR’s role profiles”.
Here is such a good video summing all of this up
http://www.youtube.com/watch?v=4u5N00ApR_k
People tell me “if only they would change, then everything would work as I want it to”.
Thought leaders tell me that making the work visible will provide transparency and an environment of honesty. This in turn will build trust with stakeholders and management. Transparency could mean a story wall, a Kanban board, published policies, information radiators, charts, metrics, data, product demos etc.
From my observations this new visibility has certainly increased awareness, and increased dialogue, but I have not seen too much evidence of it changing management’s underlying assumptions about the design and the management of the work. “Showing” isn’t the same as learning.
I hear from other practitioners that after they have left an organisation things start to revert back to how they were before, often not a complete reversal but certainly a back slide.
What I have learned through these conversations is that regardless of whether you are using Agile, Lean or Kanban it’s the underlying thinking; management thinking, that needs to be addressed. All of these methods are only as good as the thinking behind them.
I am curious if you have seen the same observations I have listed above, have experienced the same limitations, or have you experienced a change in management thinking via the use of Agile, Lean and Kanban. What other positive results have seen from your usage of Agile, Lean and Kanban beyond the team level and where do you see their limitations?
As a footnote, my curiosity into all of this has led me to search for the roots of traditional management thinking. I have made some amazing discoveries. These will be published shortly in a series of Webisodes on this blog.
Agile, Lean, Kanban, and System Thinking 
Right on David. We’ve helped dozens of organizations transition to agility and have seen the symptoms you describe many times.
There were exceptions were management were engaged energized and not surprisingly these are the great successes.
We are currently trying to require much more engagement by requiring managers to be the change agents and coaches. This slows down change at first but makes it more sustainable and eventually speed picks up. I call it pull mode change…
I recently read the Toyota kata book and I think it holds a lot of promise for this important topic.
David, great post. We can only guess where you are taking this, but you’re right, the tools aren’t enough. Even the mindsets aren’t enough – or at least there’s a failure of mindset if blaming management is the best we can do.
Tools, techniques, principles and even underlying mindsets are all teachable but I see insufficient emphasis on deliberate change management and the kind of leadership necessary to pull it off.
@Yuval, “requiring managers to be the change agents and coaches” is cool, but still, it’s only a technique. Let’s be more explicit about leadership, perhaps more honest about just how hard it can be. And share what works!
Absolutely – I think you have to start your change with managers – if you get them on board you’re good to go – if you start bottom up – as in XP/Scrum your bound to fail
I think that a culture of fear and blame is the enemy of agile. Managers in these cultures spend a lot of time building documentation and processes to defend themselves from blame and punishment when things go wrong. They know it has a price but they are much more concerned about defending themselves from attack than they are at achieving something of value. After all success has s thousand fathers but failure has only one.
Nice post.
I’m struggling with these problems as well. As a change agent and manager in my organisation I don’t find it difficult to sell lean or agile practices to developers but struggle with managers. Partly because there is resistance to change but also because it is a tougher sell. Also, most presentations, books and blogs seem to target developers or people already converted. Does anyone target managers specifically?
Non-agile thinking is so ingrained, with baseless, traditional assumptions and beliefs about “what is best” holding primacy, that non-agile culture now has armies of people with a vested interest in not being agile. It’s their job to prevent agile development. It’s not only management that is to blame, either. Try delivering agile to customers, clients and funders.
I concluded some time ago that the only way to be agile is to work in a collaborative work environment, where there might be a guiding creative vision, but no management as such, with no funders (so the work has to earn its own way by released increments) and with customers that are only too delighted to join in the collaboration. If anybody dissents, the whole thing evaporates. It also places a burden on developers and product owners to consider security, privacy, performance, commercial aspects, intellectual property, interaction design, graphical design, etc. and it is a fact that most developers only know and care about writing code.
Unfortunately, to compound the difficulties faced by agile software development, software construction is still so intricate and painstaking (i.e. slow) that even vast numbers of collaborators can only deliver tiny,insignificant, unsatisfactory increments of business value in the first iterations and this is where customers and clients lose their nerve. Hollywood tells you, in the movies, that a single guy, in a lost weekend, can tap out all of the code for Facebook, while drunk and blogging. Releasing four incomplete, un-styled web pages that permit super secure login to an as yet un-realised web site, in increment one, gets you nowhere.
So to me, to create great software, first you must change the culture both inside and outside of the collaborative enterprise and you must change several key business assumptions. Indeed, assumptions about money and value creation also have to change.
The software community has failed to change the minds of all of these other groups of people whose minds must be changed for agile to succeed. That’s an unfortunate fact. In my view, thought leadership in software development needs a wider audience, remit and scope. It is, in fact, a socio-political-economic question, not one about software development alone. Pretending otherwise will doom the whole thing to failure.
But you know this already though don’t you? The posts you did a year or so go about Vanguard network days, really well written and I learned a lot from them, those, surely show that you know?
Lean/agile etc, don’t go in at the level of thinking, but at the level of the system, one step down from where it has to go to make sustainable change.
Things don’t change unless people change.
Anyone who thinks that Agile or Lean can be a technology driven (or worse: technology only) approach is setting themselves up for a fall.
Both actually primarily address problems for *business*, that manifest themselves as apparent issues in technical delivery. So my question is: while skunk works proofs of concept are useful, why don’t we drive Agile/Lean via the business, and have the business require Agile approaches from the (already sympathetic) technical team?
I suspect that it’s because we’ve evangelised Agile particularly through the technical community. I think that community now overall gets it; so time for a switch of emphasis. Stop holding technically-focused Agile conferences. Start attending the business conferences and push it there, based on a business perspective and focused on why the business needs it.
Incidentally, True Lean (which many ppl approaching via Agile haven’t seen much of) has deep roots in W Edwards Deming’s thinking, which strongly emphasises that management must fundamentally change to enable the entire organisation to reach and surpass its potential
Click to access 14_principes_Deming_LMS_Patchong.pdf
Thanks for plugging the video. 😉 Nice blog post!
Without wanting to stir the pot, I have to be honest in my feeling that Agile people lean too much on rhetoric to drive change. Management needs more if its going to make fundamental changes .. but so many people see the collection of real data as “waste” or “anti Agile” that they self-defeat. Time and time again I speak to teams working long hours to try to succeed with agile (at all levels of the organisation) under ludicrous commercial constraints and/or management expectations who are “too busy finding a way” to step back and figure out what they need to do to tackle the root cause .. which is typically changing the fundamentals of senior management thinking.
@Mark, when we start using language like “changing the fundamentals of senior management thinking”, isn’t that also rhetoric? But you’re right, we need to step back and work out some concrete steps. “Deliberate change management” to quote my initial comment.
@Mike, mea culpa 🙂 Perhaps the words I was searching for instead of “rhetoric” were “emotional or qualitative arguments”.
Changing management thinking is simple — you need to engage with managers first 🙂 Most sales guys will tell you that the first step to get someone to listen to you is to win their trust first.
Unfortunately, a lot of agile change initiatives take the position that we (developers) know about management better than you (managers), so let us tell you how to do your job. [Imagine if a manager told you what design patterns you should use based on something heard at a cocktail party — how would you react?]
Secondly, to engage managers, you have to appear as a management thought leader in the places that they trust – Harvard Business Review, Forbes etc etc
Finally, managers want success stories from their friends. When they hang out with Jeff Bezos he tells them about his management philosophy (Amazon is a highly command & control organisation) and the great results its had. If they had met Steve Jobs, he would have talked about putting in place a strictly hierarchical organization & top-down innovation. So, unless there are case studies from organizations to rival these two highly admired companies, they aren’t going to listen.
I think this is the key point – I’m sure a lot of managers would struggle with being basically told what to do by their employees, especially if their processes have worked fine over the years. The only way to encourage uptake of this sort of thing in my opinion is with a lot of tact (and if you can convince them it was their idea, even better!)
We have seen the same slow adoption with our business side. We are a very large organization (Fortune 100) that has been moving towards Agile methods for the past three years. Fortunately we have strong advocacy from our senior leadership, that appears to be gathering steam among midlevel managment. It is from this tier that our POs will be assigned. To date we have found a fairly significant gap in knowledge with our business partners in understanding Agile/Lean concepts. What has helped is a mandatory training program for business participants before an Agile project is allowed to commence. This is a two day workshop on the basics of Agile followed by a one day focused agenda on being a successful PO. Results vary, but at least they understand our language and their responsibilities. We have also made it a responsibility of our Scrum Masters to assist the PO in their learning.
With experience our business managers are learning the values of the Agile method. The most difficult for our managers to conceptualize is the Kanban. We have tried Kanban primarily in support roles and have found it to provide less benefit than other methods. This is mainly due to the fluid nature of the process and our limited ability to provide the business with reporting that they can internalize.
There’s certainly a great deal to know about this topic. I really like all of the points you’ve made.
Ooh! Now I’m looking for that series into “the roots of traditional management thinking”. Is it about yet?
I’m still writing these. Should be published mid of this year…
Look forward to it. Thanks!
I am a technical manager and am leading the charge for kanban adoption in my team (and am becoming the kanban evangelist at my co). I find that its hard to break the developer’s frame of mind to limit work much more than it is for me to avoid wanting to pile work on them. I would love to get your feedback/thoughts on my latest blog post on the topic: http://www.everydaykanban.com/2012/03/22/what-do-you-value/
There is certainly a great deal to find out about this subject. I really like all the points you have made.
Hi David, thanks for sharing your thoughts, they are really good, and your presentation at LKCE conference was brilliant!
I started to work with Agile in 2008 as a devevloper coach, I was introduced to Scrum by a Canadian/French guy when I was working for Nokia in Beijing, I started to use it, as we was really in trouble to keep up with all the challenges we had, I was doing something that I do not recomend, but it was the only possible thing for me to do at that time, I was a SM, a PO and an architect in our 5 man team developing – it was increadible how well it worked (and this was China!). We was building Ovi Life Tools (http://en.wikipedia.org/wiki/Nokia_Life_Tools) on S30 (low end Nokia phones) with 5 people in shorter time with better quality than they did on S40 – and everyone in the team was amazed about the result of Scrum (or more like a variant, but close).
I was so happy about the result that I started to work as an Agile coach in Nokia, I returned to Copenhagen and was coaching 20 teams (too many) and building CoP with SM and PO – In Nokia the Agile thinking was coming top-down, which made it possible to work with the challenges that we was facing.
I started to work as a section manger at Sony in 2011 and still had the Agile coach mindset, but now I also had the Power to introduce the changes that I had to work so hard for as a Coach – I have introduced many of Dean L. ideas (worked with him at Nokia) and some of my own, unfortunally we are not in an Agile organization, our surroundings is Waterfall driven, and this is causing “some” challenges, but we are trying to mitigate it as much as possible and have manged to shield the teams now, however we will not get the full value before we start to work as you describe.
I totally agree with you, to get the full value from Agile, you need management support, the best results that I have seen is when it comes top-down, it is so hard to do bottom-up, specially when you work in large companies (500+, we are 170k), it was also a challenge at Nokia when it was top-down, but the commitment and support from management was so much better.
Sure they do! Especially Kanban method, or, to be more precise, Scrumban, turned out to be very effective for me and my team. Earlier we used pure Scrum, but it did not work smootly. We needed something to manage workflow and we found the solution in the connection of this two great Lean approaches.