It looks like you're new here. If you want to get involved, click one of these buttons!
Last year, my friend Thierry Sanders wrote a whitepaper about the top 5 obstacles to innovation in Indonesia. You can download it here.
Please provide an email address where we should send the download link.
Yesterday one of our new trainers asked me what the 5 obstacles to adopting agile are in Indonesia. (He actually asked what are the top 5 ‘mistakes’ people make, but I don’t like the word ‘mistake’ (I’ll explain why in this article)).
Here is my top 5, based on my experiences helping Indonesian companies become agile in the past 1.5 year. Plus some ideas on how to make things work despite these challenges.
In most companies, people at lower levels are the ones who want to make their companies agile. Some of them become true agile champions and start moving things. The CEO or CIO in most cases buy into ‘agile’ over time. ‘Most other enterprises do it, so we should also do it.’ If they hear about it often enough, they’ll put it as one of the strategic directions for year 201x.
Once it’s on the strategic priorities, Mr or Mrs ‘C’ expects the rest of the organization to follow through. And they go on to their business as usual. But this isn’t the way it works.
Agile can roughly be seen from 2 angles:
A. We change the way our software teams operate. We select a few pilot projects, train the teams in scrum and let them do their ‘IT game’ different. We do this because we want more successful project deliveries. We want IT to deliver ‘faster’ and ‘in time and budget’.
B. We want our enterprise to become agile. We want to become more like a startup instead of a big institution. We want our enterprise to launch the fintechs of the future instead of the startups disrupting us.
If we follow path A, which is where most agile journeys (logically) start, we empower our people to run into obstacles. What the teams soon face is:
I could make this list a lot longer, but I guess you get the picture.
If the leaders are hands off and expect teams to solve the puzzle, all the above examples will stifle the initiative. The only way to clear obstacles is a high level sponsor with the ability and the guts to remove the obstacles.
If we follow path B (which I believe should be the ‘end game’ of any agile journey), C level support has to be even stronger. The journey is a long and big one and needs a complete cultural and structural overhaul.
Thierry described the following in his whitepaper:
“Many employees have a fear of making mistakes, but maybe worse still is the fear of admitting to having made a mistake. This problem doesn’t only arise in my presence as a foreigner, it also happens between operational staff and their Indonesian superiors…….The point here is that innovation requires a large dose of trial-and-error. Making mistakes and being able to identify mistakes is key to the innovation process. You cannot innovate if mistakes are not identified swiftly. If done swiftly the business can act on it, or make mistake identification part of the process. Innovation is learning, learning is innovation.”
I’ve never understood this. We are born naked. We learn how to walk by falling down and getting up. We need to fill our time (and eat some food), hence we start working to earn a living. Things happen. Why should we be afraid? If we make a mistake and our boss gets upset, so what? Whose problem is that? If he’s so upset he fires us, then what? I’ve learned that in most cases, we’ll find another job. In worst cases, we don’t find a job but we’ll somehow manage anyway. What are we afraid of?
Now the big thing in agile is iterative work. If we want to launch new products, we follow a lean startup approach; we build a minimum viable product (FULL of errors!) to test initial user feedback. Based on that feedback, we learn what the users really need. We build the next version (with slightly fewer errors) and we continue that cycle until we hit product market fit. This path is about experimentation. And experimentation means we’re assuming things will go wrong. We will make mistakes. But that’s the only way to learn what we must build.
The change towards agile should also be a journey of experimentation. We try a new team setup, run 2 sprints, learn from how we operate, make changes and keep iterating. We try a new contract with a vendor, see if it works, learn from what doesn’t work and we work towards a ‘good contract’.
If people are afraid of making mistakes, they’ll not run such experiments. In the best case, they’ll run it, but they will prepare everything to perfection, which will slow down everything.
To change this fear, we need to change people’s emotions, behavior, mindset. Leaders need to accept failure and give positive feedback to encourage more learning. Managers should become humble, dropping their ‘authority position’ and coaching people on experimentation and fearlessness. We need to TRUST our people.
People are used to being told what to do. From a young age, we become ‘followers’. First, we listen to orders from our parents; then the teacher; then our bosses. Agile is about self-organization. We assume we have a team of motivated, smart people who best know what to do to get the work done. We remove the manager and instead put a coach to help people self-organize.
Most companies start their agile journey by adopting scrum. Scrum has some ‘tell me what to do’. But it also has a lot of ‘figure it out yourself based on your own context’. And the way we adopt scrum holds the key to the kingdom. If we brainwash our people with ‘too much scrum’ and add a lot of ‘this is how you should do this’, then we’re telling them what to do. Some scrum experts love doing that. Most people in teams love it as well because it’s what they are used to. Someone tells them how to ‘do scrum’.
An example question I recently got: ‘As a scrum master, am I allowed to talk to stakeholders to clarify requirements’? Now there’s a couple of answers to this. Some scrum experts will answer: ‘No you cannot do that, because that’s the role of the product owner’. Great, thanks for the rule, I’ll follow it! Another answer (the one I’d give) is: if you think that’s the right thing to do, by all means, DO IT!. Maybe the PO is busy and you need to get some input. Walk to the stakeholder, ask him the question, deliver the answer to your team and get on with your work.
With the second answer, we’re motivating people to do what’s right. To self-organize without being stuck in ‘rules’ or ‘this is the way this ought to be done’. And that’s where you want to go.
As an executive, you sit in a room with 15 other smart C-level people. Thinking about the move to agile, you’re assuming that it’s your monkey to solve. You need to figure out how to change the structure of your company. You need to implement a new standardized process (scrum+?) to tell people what to do? And once you’ve nailed it all, your people can follow that and we’ll be agile. Right?
My belief is that you should start by killing the ‘tell me what to do’. You start with a few teams that are smart, highly motived and ready to self-organize their work. As a leader, you stop thinking that you need to take all the monkeys. You refuse to tell people what to do; instead, you let them drown and support them with a coach until they know how to solve their own monkeys. The only thing you need to do is provide them with the support they need. And you remove all the obstacles they encounter.
Big enterprises ‘collect’ rules, documentation and policies. The bigger a company gets, the more bureaucracy we create. Combined with the fear of breaking rules, this bureaucracy often becomes a major blocker for agile change.
One of the topics that comes up in every discussion I have about agility is ‘documentation’. If you work in a financial institution, there are many different types of documentation. We need to comply with the regulatory bodies; we need to comply with the internal documentation requirements. Agile values working software (or great outcomes in an non-IT setting) more than documentation. The principles of agility imply that we need to go out and reduce the time we spend on documentation.
In my view, bureaucracy and documentation stifle change and innovation. If we want to become more agile, we must encourage breaking the rules. We need rebels who go out and question why we need to create certain documents. We need negotiators to go to the regulatory body to discuss lightening up the documentation workload. And we need powerful executives who dare to change the rules in order for teams to become self organized; for procurement departments to change the way they contract vendors; for hour sheets to be abandoned; for kpi systems to be modified or killed. If people want to become agile, but nobody dares to touch these topics, the change will be long and hard.
The ‘cheap’ route to becoming agile is to tell teams to adopt scrum by themselves. You allow budget for 1 training and after that expect them to solve the puzzle by themselves. The internet has enough resources to self-learn everything.
Companies in the US and EU have been moving to agile for over a decade. Looking at the way they changed might tell us what path to follow. If you look at the cases, they all follow a large scale program with a mix of training and coaching. Most hire the trainers and coaches from outside. Some develop internal coaches, (initially) supported by externals. Either way, this costs money. If a company is committed to this change, it has to invest in hiring experts to make it happen.
What to do about it?
I like simplicity. The first thing an enterprise need is to see the change towards agile itself as an experimental, iterative journey. Anybody trying to follow ‘steps or a process to become agile’ hasn’t understood the true nature of agility.
What we need are a few ingredients
With these ingredients in place, the journey has a strong basis. At each stage of the journey, different topics will come up. In the early stages, it will be mainly about coaching the pilot teams towards success and sharing their outcomes. It will be about coaching those teams on trust, self organization, willingness to experiment and change things. In later stages, topics that come up may be contracting, documentation rules, removing layers of hierarchy, the changing role of leaders. Similar to scrum, the framework is simple, but the implementation is hard work.
Post Published By: Hugo