How to sell scrum and agile in Indonesia?

Hugo Messer
29 October 16

How to sell scrum and agile in Indonesia?

One question that always pops up during my trainings and workshops is ‘how to sell agile and scrum?’. Now there are 2 versions of this question: A. How to sell scrum to your management? and B. How to sell scrum to customers (who are in a waterfall/fixed big mindset)?

I’ll dive into A in this article.

The Impact Of Culture On Agile Adoption

I’ve moved to Bali a couple of months back, so I want to dive into the question with one extra element: culture. Culture is one of my favorite topics as I’ve had plenty of challenges making European customers work with my Indian teams. If you google the question, you’ll come across plenty of articles, the majority written by Westerners referring to their own culture. I have always believed that culture is a big influencer on the success of agile. In order to decide the right approach to ‘sell agile and scrum’, we must understand the background of our ‘system’.

I came across an interesting graph, based on a tweet by Alistair Cockburn. The graph shows the average of 5 scores from Hofstede’s model for different countries.


It’s is probably not scientifically validated, but here’swhy I like it. I have always thought that the key to succesfull agile adoption is the attachment to hierarchy (power distance) within a country (or company, or team). The more people are used to hierarchy, the more they are inclined to wait for ‘orders’ from a ‘boss’. If on top of that, it’s not welcomed to contradict a boss, people have a hard time sharing their ideas. Agile is all about empowering teams to self organize. There is no boss, just some people facilitating the team. To get to a mature level of self organization, the road is longer in a country with high power distance.

To show this in numbers, look at the below table (index 1 – 120). To understand the model of Hostede including the below indices better, you can read this wikipedia page.

PDI = Power Distance Index
IDV = Individuality
MAS = Masculinity
UAI = Uncertainty Avoidance
LTO = Long Term Orientation


Malaysia 104 26 50 36
Guatemala 95 6 37 101
Panama 95 11 44 86
Philippines 94 32 64 44 19
Mexico 81 30 69 82
Venezuela 81 12 73 76
China 80 20 66 40 118
Egypt 80 38 52 68
Iraq 80 38 52 68
Kuwait 80 38 52 68
Lebanon 80 38 52 68
Libya 80 38 52 68
Saudi Arabia 80 38 52 68
United Arab Emirates 80 38 52 68
Ecuador 78 8 63 67
Indonesia 78 14 46 48
Ghana 77 20 46 54 16
India 77 48 56 40 61
Nigeria 77 20 46 54 16
Sierra Leone 77 20 46 54 16
Singapore 74 20 48 8 48
Brazil 69 38 49 76 65
France 68 71 43 86
Hong Kong 68 25 57 29 96
Poland 68 60 64 93
Colombia 67 13 64 80
El Salvador 66 19 40 94
Turkey 66 37 45 85
Belgium 65 75 54 94
Ethiopia 64 27 41 52 25
Kenya 64 27 41 52 25
Peru 64 16 42 87
Tanzania 64 27 41 52 25
Thailand 64 20 34 64 56
Zambia 64 27 41 52 25
Chile 63 23 28 86
Portugal 63 27 31 104
Uruguay 61 36 38 100
Greece 60 35 57 112
South Korea 60 18 39 85 75
Iran 58 41 43 59
Taiwan 58 17 45 69 87
Czech Republic 57 58 57 74
Spain 57 51 42 86
Pakistan 55 14 50 70
Japan 54 46 95 92 80
Italy 50 76 70 75
Argentina 49 46 56 86
South Africa 49 65 63 49
Hungary 46 55 88 82
Jamaica 45 39 68 13
United States 40 91 62 46 29
Netherlands 38 80 14 53 44
Australia 36 90 61 51 31
Costa Rica 35 15 21 86
Germany 35 67 66 65 31
United Kingdom 35 89 66 35 25
Switzerland 34 68 70 58
Finland 33 63 26 59
Norway 31 69 8 50 20
Sweden 31 71 5 29 33
Ireland 28 70 68 35
New Zealand 22 79 58 49 30
Denmark 18 74 16 23
Israel 13 54 47 81
Austria 11 55 79 70

As an example, let’s compare the Netherlands with Indonesia. The Netherlands scores 38 on power distance, Indonesia 78. This causes longer adoption cycles for Agile, because we need to change behavior (if we can). On individuality The Netherlands scores 80, Indonesia 14. This might actually be a stimulant for Agile, because people value teams over individuality. In the Netherlands, people tend to be very outspoken, pursue their own interests. In Indonesia, people feel as if it’s one big family and they are used to operate within larger groups.

Company culture

A second lense we can look through is the company culture. This is influenced by the country culture, but can obviously also differ. I found this article by Paul Ellarby of SolutionsIQ helpful in this context. Look at below picture, based on the model by William Schneider:

Organizational Model Based on Orientations

You can use this model to put your company into one of the quadrants. Then you wonder: how can this help or block me from selling agile to my management team. The article gives more background on how each quadrants makes it easier or harder to become agile.

Tell Me How To Sell Agile

The above illustrates there is no proven path to selling agile to a management team. Every situation is different and things change. Fortunately, if you’ve bought into agile, you’ll understand that. So if you’re dedicated to the cause, you’ll jam with different practices and experiment, adapt and keep going.

Before I move on to the practical stuff, there are 2 points I want to make about your starting point:

A. YOU have to go for it!

Here’s the most important thing: YOU have to do it. I’ve ran many trainings and workshops and the larger a company gets, the more I hear this: ‘yeah these are great ideas, but it’s too hard to implement in our large firm’ or ‘if I come with these ideas, management will just put it on the pile and let it rot’ or ‘our policies are too much based on project based work with written processes we need to comply to’. Being an entrepreneur I always feel a knot in my stomach when I hear this. I think we all need to rebel, we need to determine our cause and then go for it, letting nothing stop us. If we don’t act because we see roadblocks, nothing will ever get better in the world. So before you start asking management for change, pledge to go for this 100% yourself.

B. A two-day training is a rockstart!

The creators of scrum; Jeff Sutherland and Ken Schwaber, both designed certification programs. In both programs, the ‘entry level’ training is ‘Certified scrum master’. They have thought about the above extensively and came to the conclusion that the scrum master is the ‘evangelist’. The below picture from Roman Pichler shows how this evangelising role works:

Although there is a commercial taste to the whole certification program, I have the following experience. I heard about scrum some 7-8 years back. I thought ‘there we go again, another hype’ (I’m never an early adopter). Then I kept hearing of scrum and decided to read some books about it. That triggered my curiosity and I decided to take a CSM training. The two-day training was a turning point for me. After that, I was fully convinced that my development company needed scrum to service customers better. I started sending some of my Indian colleagues to the CSM training and from then on, we gradually moved towards scrum and agile completely.


Now Some Practices That Can Help

Because I like practical ideas, I’ll just shoot some that I’ve learned or stole from others. You can figure out how to jam with them. And remember, this is a change process, which takes time, patience and practice (I like this short article from Jeff Sutherland about selling change).

1. Proof That It Works

Most managers don’t care about methodology or process, they care about results (more profit, happier customers). You could go to them and say ‘I found this great way of building better software: scrum, can we implement it?’. Now the manager will probably say ‘oh wow, that’s great. By the way, did you complete that functionality we discussed yesterday, cause I’ve got a customer calling me every hour about it’.I believe in ‘asking for forgiveness afterwards instead of permission upfront’. Instead of selling anyone on scrum or agile, get your development team’s buy in to a new experiment. Then start doing it and show your management the results. If you’ve got management that is anyway keen on forcing you to follow their process, you can ask for permission to do an experiment (don’t even mention scrum or agile). Work in short sprints and show tangible results (i.e. shippable software) to your management team. Earlier they had to wait months to see anything. Any manager has the experience of impatience, waiting for functionality while hearing ‘it will be ready soon’. He’ll be delighted with the stuff he gets after each sprint.

To show a real case of this strategy, I did a short (written) interview with Mardi Vester, working in a startup on Bali:

1. How did you decide that scrum was good for your company?

I understood that Scrum methodology is good to implement, because the project gets split into small parts and the timeline (deadline) gets divided into sprints (10 working days). The components like backlog, story board and retrospective make the team understand what is the target and obstacles that they might face, so everyone can share ideas about the solution. I think every company or team that has a product (target), can benefit from implementing Scrum. I heard from my friend that he also implemented it in his family with his children ;)

2. What was the first thing you did to get started and how did that turn out?

Well, I learned Scrum in my previous company. When I joined my current company, Scrum was not a new thing for them. They had used it for several months and then stopped. I have no clear information why they stopped it, but I could see management didn’t really know about what the goal of using scrum was and how the company could benefit from it. A few days after joining, I spoke to my senior and he actually liked scrum. He really hated it when management came with the question “when is this feature ready for deployment?”. and he hated arguing with them about why it takes so long and so on.

So before I went to the management, I tried to make the Dev team understand what scrum is and what we intended to achieve with it.
Here a list of things that we started out with:
– We intended to deliver working features in 10 working days (1 sprint). We estimated the teams’ capacity using story points. The commitment for the first sprint was 65 points if I’m not wrong.
– The QA and Developers decided how many features they were going to work on in the upcoming 10 days by voting the points for each ticket.
– At the end of this Sprint we had a retrospective and evaluated our sprint. so we divided the board into 5 areas: keep doing, start doing, stop doing, more of and less of. It is called the starfish retrospective ^_^
Then we kept repeating this thing. usually every 2 sprints we released a new version of our product.

3. Did you try to ‘sell scrum’ to your management and if yes, what happened when you did?

Yes ^_^
There was a day when we (CTO, PO, Dev Lead, 2 front-end Dev and myself) discussed about features that needed to get implemented. After all the details of the feature were explained, my CTO asked: “when do you think this feature will be ready?”. Everyone turned silent and my Dev Lead tried to estimate the time. I then asked ‘why do not we implement scrum?’. So we did it per sprint (10 working days) with all thefeatures broken into small parts. We didn’t tell the CTO ‘when the product will be ready’, but we could all see the progress of the features per sprint. This way we knew the status of this project and we could come out with a new list of ‘features’ for the next sprint.

Well, to get there, we had a lot of arguments and my CTO was really upset at the time, but I am happy even about that, because he gave us a chance to implement it with some gambling were he said: “alright, lets do this scrum, but if fails then no more scrum in this development team!”.

4. What hurdles did you find and how did you overcome them?

There are a few big challenges that we faced:
– First, not all team members (PO, QA and Dev team) understood scrum. I invested time communicating the benefits to all of the team members. Some things that my team bought into early on:

1. A clear list the tickets that will go into a sprint
2. The Dev and QA decide what goes into the sprint, because they are the ones working on those features.
3. Retrospective. All team members used this chance to give their opinion on what we could improve in our sprint. Some comments not only related to the team, but sometimes it pointed to the management. We even introduced a Release party for new versions of the product (each 2 sprints) ^_^

– Sometimes management tried to break the rule by adding new features in the middle of the sprint, usually they argued it was urgent. The solution we tried: We’ll comment that thing on the retrospective ^_^

5. How does management look at scrum today?

Here’s how things worked before and after implementing scrum
– we had a fixed time to release new features
– we never had evaluations for the team even towards management
– we usually needed to work overtime (until late night) to deliver features because we made a wrong estimate

– we didn’t have a team mindset, meaning you didn’t care what the other team members were doing, or whether they needed help.
– we release a new version each sprint.
– we use the retrospective to improve the sprint, company and product
– work is 9-6 every day because the features are split into small parts and it is do able.
– there’s a team mindset. The goal is to deliver the features per sprint. we help others if he/she has obstacles.
Based on the list, our management became happy with our work flow in the development process. Now they don’t ask anymore “when will you deploy these features?”, because they know it already and they can see it on our scrum board ^_^

2. Talk About Value And Profit

Any manager or owner wants to hear how he can deliver more value to his customers. And of course how he can earn more money. Instead of selling management on scrum or agile, sell them on better ways of delivering value. Now there’s a lot of talk about ‘delivering value’ in the agile community and I see few companies who really make the bridge between creating code and delivering true value to users. Here’s some random thoughts: design a metric to measure customer satisfaction.

If you’re working on a custom software product for a customer, you could ask customers to give you a biweekly ‘grad e’ on a scale of 1 to 10. The question could be ‘how satisfied are you with our collaboration‘ and/or ‘how satisfied are you with the software we shipped to you‘. Or use the NPS score.
If you’re building a product for users, you can use the Skype approach (after every skype call, you get a popup asking you to rate the quality of the call).
rate the quality of skype call
Then show the results to your management. You can try mapping the change in satisfaction after you started delivering in sprints. He’ll get a bi weekly or continuous client happiness score.If you’re delivering software as a service, another approach could be to show management they can invoice customers every sprint. Traditionally invoices are sent only after a project is finished (or with a part upfront payment). This will increase his cash flow and might also increase his profitability. You can go a step further and even link invoicing to the satisfactory delivery of the sprint (that’s a link between the above customer satisfaction measure and the bill). But that’s a hard sell (although the idea might be appreciated).

3. Show What Management Is Missing Out

You can use some industry numbers to show the benefits other organizations are getting from agile and scrum. They’re missing out these benefits by not adopting it. If you show a link between the current pain points of the company. Probably your manager wants A. faster delivery to customers or users; B. more productivity from the development teams; C. to see what’s going on in the team, because he’s impatiently waiting for faster/better results. Now compare that to the benefits stated by 3880 respondents in the 2016 survey ‘state of agile’ by Version one.
You can then go on to show what else other managers like him report as benefits from changing towards agile:
You could get some more graphs and arguments from the Scrum Alliance ‘state of scrum’ report.

4. Show How His Life Gets Better

One thing managers don’t like is ‘micromanagement’. If your manager is still in the old style of managing tasks, strong project control and hierchy, you might show him how your team plans to move towards self organization. The core of agile is about self-managing teams. Product owners show what has priority in terms of customer demand and value. Teams figure out how to deliver that value. As a manager, I would love my team to come up to me telling ‘from today onwards, you don’t need to tell us how to do stuff anymore, we’re going to show you  the results. The only thing we need from you is priorities and clarity on what problem you want us to solve.’


self managing teams

5. Go Beyond Scrum

Another approach is to throw spaghetti on the wall and see what sticks. Start talking about all the stuff other companies are using nowadays with great success: Lean startup, Agile, Design Sprint, Kanban. You can show how these methods produce better results (with reports and data as shown above). You can share that your team has decided to adopt an agile mindset: moving away from the old ‘tell us what to do and we’ll do it following 5 steps’ towards experimentation, flexibility and customer focus.One central ingredient of many agile frameworks like lean startup, design sprint is getting closer to customers. Instead of a team working in isolation on code dictated by a manager, teams get out of the building. Together with feedback from users, they figure out what needs to be built (=lean startup). Or they design a testable prototype within a week, gathering feedback from users to decide whether they are on the right track with a new product or functionality (=design sprint). If I were a manager and my team would say ‘listen, we’ve decided we want to get closer to our users, we want to interact with them and ask them for feedback on what we’re doing’….I would sign the contract right there and then!

6. Take Them To a Training Or Conference

Simple thing to do, which can have a big impact. A lot of manager stay inside their offices and use the knowledge they already have. You could ask them to join an agile conference. Or maybe you can convince them to attend a scrum training. You probably think ‘he’ll never buy that from me’, but remember that you committed to this cause 100%. So you just need to find a way to sell him on this.scrum crash course

7. Start Putting Stickies All Around The Office

Now this may seem awkward, but I believe it’s incredibly effective. Buy some big flipchart papers, a lot of stickies in different colors and markers. Turn your office into an agile cockpit. You can start by creating scrum boards for your software team. But you can also take this beyond software. Make a board for ‘office improvement plan’, ‘ideas’, ‘complaints’, ‘management improvement plan’. Then ask all your colleagues to put their ideas on those boards using stickies. I am sure your manager will love the information he’s going to get from this. And it’s all visible and out in the open. I’ve seen offices where all the walls are covered by special glass to enable everyone to post stickies everywhere. I’ve seen office where people even make boards for their personal improvement plan (like: go to the gym every day to loose 10 kilos). And it works.

8. ?…


I’m sure with some of the ideas above you’ll think ‘naaaah, no good’. That’s ok. The key is: commit to your cause of changing the way work gets done (call it agile or scrum or whatever you want). Then use your imagination to come up with ways to get buy in from your management team. And keep going, keep going untill people either start changing or start calling you a nutcase (that’s when you’ve got their attention and you can really get going!).