“Dear management, we’re already agile”

Agile is good, but we need management support for it“. “Agile adoption should start from management“. “Our agile adoption failed because management didn’t support it“. You hear it all the time, right? Indeed, such claims are everywhere. For example, 7th VersionOne’s State of agile survey says that in 63% cases initial agile champions were from management and also 31% says that management support is the biggest barrier for further agile adoption.
Well, it seems to me more like excuse then like a real barrier. People sometimes forget that bottom-up approach to agile adoption is all legal. Mike Cohn in his book Succeeding with Agile call it a “natural” approach.

I think that one of the reasons for such view could be that people don’t start from principles, but from practices. Starting directly from practices like Scrum could make you believe that you need deep organizational changes to start your agile journey. And organizational change needs, you guess – management support. What’s even more interesting that another reason is waterfall itself. To be more precise waterfall’s big upfront planning rule. It’s a kind of thinking legacy built into our brains that everything, including agile adoption, should be planned in details to succeed. And such big upfront planning and big decisions need, again – management.

Well, wrong.

Agility is a set of principles applied not only to an organization, but to people, too. Uncle Bob goes even further from here and says that “TDD is a personal decision“. Such a thought can be applied to some other practices and principles like kanban, pair programming, refactoring,…
Everyone should be aware that adopting some agile principles DOES NOT depend about management. I was a part of a team that tried and succeed in adopting Scrum without explicit decision and guidance by management. You can start tomorrow. No excuses!
It will happen that your manager will come back from some conference or training and will ask you to adopt agile. Put yourself in a position that you can say: “Dear boss, we’re already agile”.

8 Monkeys in a Cage – a Mura Learning Game


Last time when I was teaching Lean, I found myself in trouble. The topic was to teach students about 3M principles: Muri, Mura and Muda. As always, I planned to do some practical learning games. There are a lot of games about Muda, some very good about Muri, but very few about Mura. Additionally, we were in a very small classroom with computers fixed at desks, so I was in trouble finding some good Mura learning game appropriate for my situation.

So, I created my own Mura learning game which requires only a projector, a piece of paper and a pen. Even a projector is not really necessary if you print monkeys and give it to students. The game itself is improved through multiple sessions and it seems to me it is a solid Mura learning tool. That’s why I decided to publish it here and at tastycupcakes.org.

Here is a game description:


Mura is one of three fundamental Lean principles. In short, it’s about unnecessary variations. It states that people are more productive when not dealing with unnecessary variations. Playing this game should help people to feel a situation when variation is unproductive.


20 minutes


  • a projector and a presentation
  • 2 pieces of a blank A4 paper per student
  • a pencil for every student


Give two blank A4 papers to every participant. Ask participants to draw “cages” on their two papers, so that monkeys can move in later. Every side of both paper should be divided by two lines resulting with four equal squares on each side of both papers. After this, every participant should have a total of 16 cages ready.

Tell participants that in this game they are not competing each other and not competing against clock. The goal is to feel the difference and to discuss it at the end.

The Game

Put a slide 2 (the one with four different monkeys) at projector. Tell participants to draw these four monkeys in cages onto their paper. They should do it by drawing monkey no. 1 in a top left cage, monkey no.2 in a top right cage, monkey no. 3 in a bottom left cage and monkey no. 4 in a bottom right cage. After this they should turn the paper and repeat drawing of 4 monkeys. Give them 5 minutes for it.

Now, put a slide 3 (the one with only one monkey) at projector. Ask participants to take the second paper and fill in another 8 cages, but this time always with a same monkey. Give them 5 minutes for it.

The Learning Point

Ask some of participants how they felt during the first session (with different monkeys) and how they felt during a second session (with only one monkey). What was faster? Which session was more stressful?

After this, let them understand that a task was to draw 8 monkeys, not to draw 8 different monkeys. So it means these variations were unnecessary. Also, it is important to say that a real reason why they were faster during a second session was because they learned how to deal with this monkey.

Help participants to correlate this situation to a real world examples:

  • one of the worst situation are unnecessary variations in product backlog. It generates stress and makes us less self-confident during estimations. That’s why we need a balanced flow
  • it is relatively often that people implement multiple, slightly different implementations for a same problem. We don’t need such variations. In that case, we should use “a same monkey” – a component
  • ask participants to add more real world examples of unnecessary variations

Is there Anything Special when Adopting Agile in a Bank?

Ever heard about large or mid-sized bank which is a fully lean or agile organization? Hm…

For the last 12 years I work in a bank. Also, for the last 4 years I push hard agile adoption with some other colleagues. During this period I gave some conference talks and discussed with colleagues how to overcome resistance and to break barriers that lurks when adopting agile in banks. But recently, I found myself thinking is there anything really special when adopting agile in a bank or not? Is there something that should be treated as a special case or banks are only a prototypes of a large traditional organizations?

The first “special obstacle” candidate that came to my mind is a traditional project management. Oh yes, banks have a very long history of project management and most of them are doing it in a very traditional, non-agile way. Since this traditional roots are very deep and Project management offices (PMO) are very important, it is very hard to change things and introduce agile development. Many people think that their skills will not be needed once an organization shift to agile, so resistance is very strong. Of course it’s not true, but it lasts long to break this misconceptions. Because all of this reasons, traditional project management in banks is a large obstacle for agile adoption. But, it is not unique for banks only. I can imagine a lot of other organization types with a same problem. Just to mention a few areas: masonry, science, state administration,… So, zero points so far. Our first candidate is a high hurdle to jump over, but is not special for banks.

Any other candidate?

Yes, Regulatory Compliance. From the first moment when it came to my mind I had a feeling that is much more “bank special” then the first one. For those of you unfamiliar with this term (lucky you:), corporate regulatory compliance is an obligation to follow rules defined by governance or by some internal acts. In case of banks, you can imagine that there is a lot of such rules to follow. Recently, when financial industry was a cause of some economical problems, these rules became more strict. Also, fighting against terrorism and against organized crime added more rules to follow. The result is a lot of regulations that slows down business process. So, there is a great impact to agile development because you cannot remove impediments. Yes, the bad news is that it’s almost impossible to eliminate this waste from inside organization. Regulatory compliance is like a phase of the moon – you cannot avoid it. These rules are here to follow. Sometimes rules will change, but not because of agile coach wish:). So, our second one is a real beast. It is not 100% special to banks, but almost it is! I’m not aware of any other industry which is so much under pressure of regulatory compliance like financial industry.

Let’s try to find some other special obstacles. Here comes a weird one – reputation risk. What? How’s that connected to agile adoption?! Patience, you pure and simple bank client, you’ll find out soon:). Reputation risk is a “mother” of all risks (or at least an “oldest brother”:) in a banking industry. There is not a single bank invulnerable to reputation risk. So, every single thing connected to a possible reputation risk is treated as a high priority. For those with no experience in banking it may be unusual. For example, imagine that avoiding one hour downtime of branch offices is more important then launching a cool product. Weird, ha? Now imagine that external agile coach who is leading agile transition, unaware of importance of reputation risk, produce a big one… What would happen? A whole transition process could fail because of discredit…

Maybe the last one is a bit overstated, but it shows these little differences that could be extremely important. And for sure, there is more such specials. Some will say that all industries have its own differences and they’re right. But, banking is different in a different way. This differences are often unexpected and possibly very harmful for an agile transition. So, knowing this special cases can be of a vital importance for agile transition process.

Coexistence Model between Traditional PMO and Agile Development

I know there is a lot of debate if coexistence between traditional PMO and agile is possible. A friend of mine usually say that being agile or not is pretty much the same as being pregnant or not – you are agile or you are not. Instead in this way, I like to think of this topic like agile is an art of possible. Sometimes is just not possible to adopt all agile practices, because of a thousands of reasons. At least is not possible in short time and for a whole organization.

A month ago I was involved in an initiative to establish such coexistence between traditional PMO and agile  development. It is a quite large organization where agile development grown bottom-up, so a number of development teams already practicing agile (mostly Scrum) for some time. Because of a good results, a consensus in high management resulted in initiative to better organize work between PMO (which is still organized traditionally) and agile teams. After a discussion, I proposed a model like this:

An idea is to enable agile teams to function as much agile as it’s possible inside large organization which is still mostly organized in a traditional way. So, let me explain this idea:


Every agile team is responsible for a single product (application). Notice that I did not say project, but product. Every agile team has Scrum master (SM) and Product owner (PO). So, this part is fully agile and use Scrum.

From the other side, there is a PMO. A PMO will designate a Project manager (PM) for every project they decide to start. PMO is influenced by stake holders, some boards etc. This is a traditional side of story.

So, where is the bond between these two sides? An idea is that PMs will work with all POs whose products are related to a particular project. PMs will influence POs to adjust their Product backlogs to fulfill project goals. Also, PMs will do all administrative project tasks and generally all job that they are familiar. At the same time, development team is isolated by SM and they do their job in an agile way.

Some early results of such approach are very good. A good thing is that only PMs had to modify their behavior, but only partially. Another important thing is to look at this model only as a step in a process of making all organization agile. Any other goal doesn’t make sense.