Yesterday I was listening to David Anderson on Joe Dagger’s Business 901 Podcast. One of the interesting points were about the differences in Cultures driving to different attitude towards the Kanban Method between the US and Europe. Basically what David and Joe were saying is that there seems to be more traction for Lean and evolutionary change in Europe. The speculation is that Continuous Evolutionary approaches are more aligned with corporate and national European cultures. Europeans think they are more patient than Americans. Americans look for fast results and are more revolutionary. Go hear the discussion – it’s around 03:30-05:00 in the podcast.
This has got me thinking about Israel. Our national and corporate culture is said to in general be quite similar to America. I found this “Doing Business in Israel” article from CommunicAid which enumerates Individualism, Directness, Impatience and Polychronic as Key Concepts and Values. In general, this seems discouraging for alignment with Agile approaches – which encourage collaboration and collective ownership over individualism, focusing and finishing things over the multi-tasking hinted by PolyChronic. At least PolyChronic also means we are easy on the trigger of re-prioritizing, which explains why business agility is quite valuable to us…
Last but not least, we are impatient. And while there is nothing in general agile thinking that contradicts that, once you go to Lean, Continuous Improvement, and using something like the Kanban Method where you need to Agree to pursue incremental, evolutionary change, it becomes a bit more difficult. My experience in the field seems to align with the lack of patience for Continuous Improvement. Most Managers and Executives I see like the Agile concept a lot, think that delivering iteratively is a good idea, but the Continuous Improvement bit gets less traction, no matter how much we try. There are of course exceptions and bright spots shining through, but I cannot ignore the overall trend.
This explains why Kanban as a system is getting lots of interest and adoption in Israel, but not necessarily the evolutionary aspects of the Kanban Method. Disclaimer – my perspective is quite subjective, and related to the kinds of clients that approach AgileSparks. I’m interested in what other practitioners and consultants in Israel think.
With this starting point, you would expect head-strong revolutionary agile implementations. And we are seeing many of those. But the Impatience and PolyChronic traits also lead to losing interest and pace even while doing the revolution. Our attention span is short, and after the initial excitement, we often see organizations not focused on the change long enough to recover from a deep change and addressing all of it’s repercussions. It’s also quite typical to see organizations signing on for the revolution, but even when starting, they start making amends to the reality of the revolution being too much for them. We see feature teams which are not really feature teams. Doing agile, but continuing to work on many many projects because deciding to freeze some of them is a hard decision. Impediments actually requiring some tangible investment or management staff spending time agreeing on something and changing policies, linger.
What I started to think about was a way to learn faster what is the real change pace that the organization can sustain, before diving too deep into the j-curve. Maybe by front-loading tough decisions and seeing if they are made. Maybe by simulating real life scenarios in more depth and making the reality they will face later into the change more tangible for leaders. Maybe by starting with the tough aspects of limiting the work in progress and pull mode at the management level, before going to the teams level. If all of this doesn’t phase the organization and it’s management staff, then they have the right attitude and timing for a revolution. If they get cold feet, a more evolutionary approach can be adopted.
I’m thinking though that there isn’t much value in positioning the approach as evolutionary, at least not to those organizations. If they want an Agile Revolution, we will give them an Agile Revolution, maybe doing it in an evolutionary way.
There are other organizations which ARE dis-enchanted by revolutions, are mature enough to look for methods that are based on evolutionary continuous improvement. They might start with continuous improvement, but sometimes will consider a Revolution of sorts at some point.
I think we should develop more and more ways to recognize what is the best fit for the organization, ideally give the organization the system that helps it understand their own ability to pull change at a sustainable pace. This relates to my short Pecha Kucha talk from LKCE11 about Implementation/Policy Kanbans.
I will continue to think about this topic. Lucky for me I’m seeing many examples of Israeli corporate culture in action, so will have a chance to examine this theory. Help me out by sharing your experience from Israeli or other impatient cultures!
I'm Yuval Yeret. I'm leading the Kanban practice at AgileSparks. This blog focuses on my experiences using Lean and Agile approaches to help organizations and people become more effective.
Holy Land Kanban Book
- My favorite Excel-based Agile Backlog Templates 0 comment(s)
- Scrum Sprint Commitment Rant 0 comment(s)
- Kanban Method – Finding the Minimally Viable Change 0 comment(s)
- So what IS Scrumban? 0 comment(s)
- How does the performance objectives process change in a Lean/Agile world? 0 comment(s)
Tag clouditerations Agilesparks SLA Teams resources classes of service sprint Transition Lean Startup קנבן flow project_management Israel bugs QA Commitment agile testing relationships agile_testing engineering_practices LSSC12 SPC kanban metrics hr MMF RND LimitedWIP greenpepper reading_materials Organization Slack conference Training velocity lean scrum LSSC11 LKCE11 issue_tracking Workshop Cycle_Time test_case_management agile Continuous Improvement
YuvalYeret on Twitter
This work by Yuval Yeret is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.