Gerard Chiva is a highly experienced Agile transformation coach, but this definition is too narrow to describe his true value to the companies he has been working with since 2009. His strong background in software development and vast practical experience as a certified coach and in global corporate management roles have allowed him to stably build high-performance agile teams (mixed and distributed) in large enterprises and wider organizations.
In our recent AMA session, Gerard answered questions about innovations planted in large corporations, the truth about working with virtual teams and the future of Agile methodology. Enjoy the highlights!
On uncovering Agile coaching
I learned about Agile years ago, as a development manager at a big company. I read three books then: The Lean Startup by Eric Ries, Management 3.0 by Jurgen Appelo and Coaching Agile Teams by Lyssa Adkins. All of them were an inspiration.
I LEARNED a way of doing things that was completely different from what I had witnessed and been part of, and it looked like the future.
I started applying some of these concepts within my teams as a development manager, and it worked.
I realized that I wanted to practice that not only in my company, but everywhere else. I decided I could make an impact on the world, if not by changing the world itself, at least by changing organizations.
Profile
Gerard Chiva, Agile coach
3 books sparked his interest in becoming an Agile coach
15+ years of experience in enterprise software development at all levels, including management roles
8 years in the field of Agile coaching
Now I’m doing my best to make people happier at work. I also teach organizations to be productive and innovative while caring about their customers.
Humans spend a lot of time in organizations, so I thought, if I can change how organizations work, maybe I can make a better world.
On introducing a culture of innovation in large corporations
FOR ME, THERE’S NO DIFFERENCE BETWEEN ORGANIZATIONS WITH 20 OR 2,000 PEOPLE. The most common problem is that companies are so focused on their day-to-day work that they forget they need to innovate. They are so busy managing their own generated waste that they don’t have time to improve and innovate.
From my experience, in order to do things differently and innovate, big organizations need to work in a different way and take a different approach.
I’M NOT A BIG FAN OF CHANGING CULTURE IN ORGANIZATIONS. It’s very difficult to do, and, even if you can do it, it takes a very long time. Structure comes first; culture follows. The problem does not lie in people not being innovative or the organizational culture being bureaucratic; it lies in the structures, processes and systems in place that stifle innovation.
You need to start at the highest level possible, because we are talking about a significant change in the way decisions are made – decentralization, the way leadership works, autonomy and trust against control, and self-organizing teams. Appointing a chief innovation officer won’t help you innovate more.
Innovation is something that happens; it’s not something that you create or design.
In order to scale innovation, companies need to decentralize. The ways we work, manage and collaborate need to change. You need to set up an environment that allows innovation to flourish.
Having set up the innovation department, some companies just apply to it the same mindset and the same rules of the large organization, but the department won’t be successful this way. When I hear “innovation,” I immediately start thinking about Lean Startup and the movement started by Steve Blank and followed up by Eric Ries. They suggest the following: create your own startup and manage it with innovation accounting, VC funding and cross-functional teams. Use Agile methodologies and apply the lean startup method.
Fund like a startup. A traditional company is funded with an annual budget, but here budget controls and targets don’t work anymore because they are rigid and generate unhealthy behaviors.
Set short-term objectives. Say, ‘Hey, guys, you have $1 million. In three months, we’re going to see what you have done. If you’re progressing, you will get more money. If you don’t, you do something else.’ These guys manage their own budget.
You need to work on trust. You need to work on people.
You need to set up systems where individual performance is not as important as the performance of the team. People have more freedom. Every idea is welcomed. You need to test your ideas.
SET GOALS WHERE A TEAM HAS TO DEFINE AN IDEA AND TEST IT PRETTY QUICKLY. And then move forward. Once the problem is solved, the team needs to achieve a product market fit.
Then the teams learn if the market is willing to pay for this product and if you have the capability to grow into it. The goal is to achieve a product market fit.
It’s not a culture of blaming; it’s a culture of experimentation.
On the future of Agile
There are a number of trends in Agile that we will see in some years’ time.
In recent years, we have seen a movement of scaling Agile. Different frameworks have been appearing such as Nexus, LeSS, SAFe and Kanban, each with the purpose of scaling Agile across the whole product development organization.
The next step for Agile being made now is organizational agility. Agile is no longer about product development; it concerns the whole process and organization. Finance, legal, HR – everything must work together as a complete, adaptable and agile organism.
True business agility is not only about the production or the operational side of the company. It’s also about the strategy, management, decision making, governance and structure – everything.
Careers will not be going up or going out. Instead, they will go across. People will change roles more quickly. There will be less specialization and more crossovers between roles.
On the reality of virtual teamwork
The concept of stable teams that stay together for years is going to decrease drastically in the coming years. We’re going to see a lot of distributed teams and volatility everywhere. You need to prepare for this.
If you are on two different floors of the same company, you are already a virtual team. So, with virtual teams you have to do exactly the same as you do with collocated teams, but more.
WITH REGARDS TO REMOTE TEAMWORK, ONE ISSUE TO DEAL WITH IS DISTANCE AND ANOTHER IS TRUST. Trust is important for any sort of team, but with virtual teams I think it’s key. And, also, distance. Humans are wired in a way that, if something is close, we like it, and, if something is remote, we don’t like it as much. This is how our brain works, and we need to overcome that.
Everything is going to be disrupted in the following years. And the companies that don’t go this way are going to be… They can start counting the time.
Advice on establishing relationships within a distributed team
1.Use icebreakers
Use warming up exercises related to vulnerability and trust. Because vulnerability and trust are key aspects for any performing team.
2. Be proactive
If you set up 50-minute meetings with your team, take at least 5 or 10 of those minutes to work on trust. Always. Forever.
3. Recreate office moments
At 8 a.m., instead of starting working, you can have a coffee. You connect with your cameras, you have a coffee and you talk about what you did yesterday, or anything else on your mind. This creates bonding.
4. Ditch email
Email is bad for virtual teams. Call people. Use Skype, Hangouts or Slack – whichever tool allows you to see each other.
5. Meet in person
If possible, schedule a quarterly face-to-face get-together. Obviously, you’re not going to be working together all day, but at least once in a while, you get together, do some work together and some teamwork too.
6. Begin knowledge-sharing sessions
Schedule 20% of your time with your team to share knowledge. Dedicate Friday mornings to prepare something and share it with your colleagues. Let anyone in the team present something different every week.
7.Prepare a team charter
We prepare a charter with the vision of the team, the mission, shared values, working agreements and the main goals for the team for the next year. You can do that using a great tool such as Miro. It’s something that you need to do for any team, regardless of whether it’s virtual or not. And it’s an important task for coaching teams, too. I like using a behavioral profiling tool like the DISC assessment, which categorizes your behavioral profile and helps your teammates understand the communication preferences of their colleagues: how they want to be treated, how they prefer to work and their style of communication.
8. Be appreciative
We shouldn’t have to say this, but everyone needs a reminder. “Hey, thank you for helping me. Thank you for doing that thing yesterday.” This also creates bonding and trust in teams.
On the excitement of Agile coaching
There is one great book from Daniel Pink where he describes three key motivation factors: mastery, autonomy and purpose. And I think I have those three pretty well fulfilled by working as an Agile coach.
I’m agnostic to the methods, but not to the mentality or the mindset.
1. Mastery
I try to learn and adapt every day. Every customer is different and every person is different. You learn a lot from new situations and people. It’s a journey of continuous learning.
2. Autonomy
I’m a freelancer and my own manager. Nobody tells me what I have to do or what I am supposed to do. I set my own objectives, and that’s pure autonomy.
3. Purpose
The purpose is to make organizations or workplaces better and help people be happier in the end, combining different methodologies to make the best experience for the customer. I meet different people working in different organizations and doing different things.
I combine methods, frameworks and tools, such as Lean Startup, Scrum, Kanban and also scale frameworks like SAFe, LeSS and Nexus. These methods depend on the customer and the context. I combine all of these things together to provide the best solution I can for my customers. I use Agile frameworks, Agile transformation and coaching teams (collocated and virtual) and apply tools such as Miro to work with distributed teams.
