We just do it!

Today I had to drive my daughter to her Karate class. We got on the car and while driving, I started a conversation:
Me: How's school
She: OK. Nothing special
Me: How's that "Talk show" going?
She: Good. We are ready for it but we haven't done it yet. Right now we are busy with something new
Me: What is the new project
She: A debate
Me: Interesting!! On what?
She: Should we have internet at school or not
Me: Hmm!! What side are you? Pro or Con?
She: Don't know! Teacher will decide that when we have the debate. We are preparing for both
Me: You already prepared?
She: Yes. We have a list of pros and cons
Me: When is the debate?
She: I don't know. Our teacher is extremely smart. He knows that if he gives us deadlines, we will procrastinate and then rush at the end. So we just do it!
Me: Hmmm. So if the debate is tomorrow you are ready and if the debate is next week you are ready?
She: Yes. We have the list of what we want to debate for each side.
Me: You know this is Agile?
She: Oh no! (facepalm) Agile again!!
Me: Yeah, it's actually an high version of Agile
She: Hmmm (noticing signs of feeling cool and hip on her face)
Me: See, the way companies work is like: We need to do X. So they sit down and plan for it, how much would it take, when should it be ready, and so on. And then there are these other kids that just like you, they just do it and figure things out while they are doing it.
She: Yeah, our teach is smart. I will tell him about this :)
Me: You know, I will write a blog about this and you can tell him to read the blog.
She: When will you write the blog?
Me: When I get some time
She: You never have time. Make some time to write this!

And here I am, writing this blog :)

Following "Little Prince"'s advice, I will translate this for the adults.

This 6 grade class is doing Continuous Delivery!
The previous project "Talk show" is a feature that is DONE. It is in production, Deployed but not Released yet. The teacher has not decided to actually run the "Talk show" but kids are ready for it, ANYTIME!
The new project, "Debate" has already started. Kids don't know when is needed, but rather than ask for deadline, they just started working on it. They have already a list of pros and cons to consider. They can improve on those (Refactoring!), but at anytime, they can have a debate and discuss about having internet at schools is a good thing or not. Even this new feature, is deployed to production but not released. The stakeholder (teacher) can get a sense of what kids are doing because he can see them during the day, he can hear their conversations, he can understand if they are ready for it or if they need more time to refine it.
Maybe the first project, "The talk show" will never happen. After what he has seen during the preparation, the teacher might make a decision that this talk show might not bring up the point he initially wanted to make. Or maybe he is just preparing the stage while they are working on the new project. So when they Release the "Talk show" everything will look awesome (think of this like the Marketing or Ops prep work before a Release). 
Meanwhile, kids are working on the most important work for the moment.
Kids did not stop to ask for deadlines because they know the teacher will not give it to them. Kids started working on it and started delivering value: an initial list of pros and cons to consider if the debate is tomorrow. The quality of the release is defined by the main stakeholder, the teacher.

Makes sense??

Thanks Mr. Rhienhimer for teaching these kids to "Just do it" and not waste time on procrastination, not rushing last minute, to work on valuable work, to be able to produce success in small portions and increment on that, to value results rather than just to pass the test.

1-2-Experiment

I hope by now you know that one of the fundamental beliefs of Agile mindset is Empiricism. Being empirical is about learning by doing, by testing, by experimenting. Agile practitioners are the ones that usually are avant-garde when it comes to working like this. Or at least this is what we expect.

Well, just like in other areas, even here we have groups. Some Agile Practitioners (AP for short) love experiments. They can generate multiple a day. They love building hypothesis, they love collecting feedback and they love analyzing what they find. I have noticed that when people like these are on a team, focus is mostly on innovation AND creating relationship within stakeholders.

Some other APs are cautions. They support experiments but they make sure to bring up risks and any electric fence we might face ahead. They make sure everyone hears all of these so that some adjustments are made to the hypothesis/experiment to add some safety around. When people like these are on the team, focus is on delivering value AND create alignment within stakeholders.

And then there are the other APs, with a high level of caution.Their experiments are usually big, well analyzed, verified on google after hours of research, and with many metrics to measure success. When people like these are on the team, innovation will not happen any time soon and team values rules and tools. Yes, the team will achieve expected results but will not break new ground. After all, most of what they did was found on google as something that others had tried before.

So, personally, I have started looking at the team behaviors to understand what kind of agile practitioners are in the team, starting with the coaches. This helps me to understand where these teams are strong and where they have room for improvements.

Yes, I can hear you saying "Yeah but... ".

Let's consider some of these "but-s".

• Team is not in an environment where experimentation is supported 
• People on the team are worried about consequences they might have individually
• Why experiment if someone has done this before?!
• People on the team are not agile practitioners
• There is too much regulation around what we do
• Our client is not a StartUp, is an old, established business
• We like to experiment but our manager doesn't
• I don't like experiments. Tell me what to do
• ...

If you try to understand the root cause of each of them, we will end up in tow big groups

• Fear
• Fixed mindset

You can hear Linda Rising about the Fixed mindset, so I will talk more about Fear here. But there is one thing I want to mention. Fixed mindset has a hard time with experiments and will pull back others on the team that do have a Growth mindset and want to experiment. Try to keep them limited on the second group of APs. Listen to their concerns, adjust when needed, but don't hold back on trying something new.

Fear
Can be of losing job, losing credibility, losing a bet, losing a client, losing a deadline, losing relationships, losing money, losing opportunity, losing control, losing time....
It's all about losing something. And this is on all levels. Individuals are feared to lose any of the above. Same for teams, managers, organizations, enterprises. At some level, someone has fear to lose something.
There are 3 zones we can operate.



The Safe zone, where we are compliant, where everyone agrees, where we are "covered" on all sides.

Warning zone is where we start pushing boundaries and we do things that are risky, experimental, might fail or might win, test relationships. It is called Warning zone because what you are doing might piss-off some people around you but you will not lose your job, you will have other chances even though they might come with more surveillance and control.

Danger zone is where we have pushed our limits a lot and we have made a lot of people uncomfortable with the new system we have created, where we are trying things that were not imagined could happen and where we might lose the job.

The bigger the fear the more we stay in the Safe zone 

As you might notice, Safe zone is the smallest zone. Because we are safe, we do achieve results but everything is under control, soundly managed, practices followed to the dot, tools trusted and everything is supported with proof that someone else out there has done the same and is working. We are used to put this category in "waterfall" but I think this is visible on Agile teams as well. These are the teams where scrum is done by the book, where any idea that comes up needs to be googled and find support before using it, where there is value on doing things right until we find that we were doing the wrong thing.
From my personal experience, this zone is where I learned the least and I was scared the most. It might sound counter intuitive, but that one company I worked where I played on the Safe zone all the time, was the company where I was fired after 1 year. I did everything Safe, and when the first change came up, I was the one that lost the job. Not the ones that were trying. And that was the last time I worked on the Safe zone in my career.

And then is the Warning zone. This is where we TRY.
This is where we start questioning things. This is where we try to do things that are not found on google, where R&D begins, where discovery is the way to achieve goals. We discover what will the manager say if we try something new, we discover how the product will look if we try something different, we discover if the client will like our suggestions, will discover which one is more important between time and money.I believe this is the zone where most successful Agile teams operate. They do go sometimes on Safe or Danger zone, but Warning is their comfort zone. This requires courage, purpose, desire and support. I can tell you many stories about being in the Warning zone but it might take a while. What I will tell you, is what I have found when being in the Warning zone:

Warning zone is not as scary as it seems when you look at it from Safe zone!

The more comfortable I have grown to be on the Warning zone, the more I have grown to learning, creating new relationships, have integrity, face challenges, create proofs rather than search from others and, GSD (Get S&!t Done). Yes, I do analyze, I do research, I learn from others but I do not limit myself to that. I create. I do work that others will search on google and repeat after me. I will ask for forgiveness and will try again with more knowledge.

What about the Danger zone? This is where we go to the Moon and back!
This is where fear has no place. This is where innovation thrives and where fixed mindset feels threaten to death. The only place they might go is Warning zone. Safe zone is the least preferred one. As you can see, this is the largest area. There is room for so many things to do here. But with more Power comes more Responsibility. To be comfortable in the Danger zone, you need to be comfortable with the possibility of losing big or winning big.

This is where the "crazy ideas" come from.

And we know that some of them have shown us that they were not that crazy. This is not a zone where majority of individuals or organizations hangs-out. This is for the brave and for ones we call "anti-social" because they work for a cause, not to be nice. If you are there, use it with care and with responsibility, and love every minute of it.

Still with me?

If you are or want to be an Agile practitioner, EXPERIMENT!
If you are not experimenting, stop and ask yourself why.
If you have a Fixed mindset, start working on creating a Growth mindset.
If there is fear that stops you, TRY and push yourself to Warning zone.

Offshore part of Agile

I recently had a two week trip to India.

First week was at the Agile India conference where I was happy to be one of the presenters (See the value). AgileIndia was a good conference with interesting speakers, interesting content and interesting format, every day having a different focus. The topics for each day were Leadership, Team Culture, Enterprise, Devops and Lean startup. Here some of my impressions:
- There were a lot of people that attended the Leadership and Culture days. The spirit was more about learning, not a lot of questions or challenges.
- There was a lot of interactions and discussions around technical topics, although the number of attendees went a little down.
- Just like on any conference, there were people that were advanced and was hard for them to find new things, and then there were people that were on the early stages of their journey
- People like to have fun! At the end of one of the days, organizers brought in a musician that had created instruments with stuff thrown away. He was fantastic! He made everyone play music and be in the rhythm. But it took a couple of Canadians (Ellen Grove and myself) to start the dancing. We just let the Genie out of the bottle because everyone got up and started dancing. There was no way you could stop them! That was as close as I got to an Indian wedding, and was awesome :)

In a nutshell, I got the feeling Agile is in good hands in India. People want to learn more about leadership and product building, and when it comes to technical it is a lot about how-to's and where can we get more of it.
Congrats to Naresh Jain for organizing this conference and for starting a controversial discussion around "Collaboration has gone too far, people need alone time"  ;)

The second part of my trip was in Hyderabad, the other "Indian Silicon Valley". Between Bangalore and Hyderabad, there was a lot of knowledge on how to build software and services.
I had the chance to meet some really great people, talk with them about their challenges and get to understand the offshore lifestyle. In Bangalore I noticed some people leaving work at 10PM and I felt terrible to think they are staying to work late in order to talk to us, to have some overlapping hours for our sprint planning or standups. But then in Hyderabad, I learned that people start work late and stay to work till late. Good! Glad to see that there is a balance there. 
I heard a senior manager saying : I need to treat my people well or otherwise they can find another job tomorrow, just down the road. That made me think that our offshore teams do not have any lower standards from what their peers in North America or Europe have, actually might be the opposite. Because of the high demand, managers understand that they can't do anything alone, they need the good and talented people and need to treat them well to keep them.
Most of the work is "Service" based. People have technical knowledge and aim for CI/CD, aim for ways to solve problems technically. And then there is the challenge of dealing with requirements. They really liked one thing I said during a training : "Don't be order takers. Ask for clarifications, for the goal, about the end user". That really stroke a cord on them and gave me a sense of what usually goes on during sprint plannings.
At the end, I believe Agile is understood and is somehow practiced on offshore teams. Because most of the work is defined outside of their circle of control, they can only influence the solution. They  implement practices, frameworks, automation, UX and whatever client asks for. But they can only influence solutions. Control is not in their hands. And maybe they do not want that control.
The other interesting part is that due to demand, the cost of "offshore people" is growing. Hiring talent is not easy. Keeping them is even harder. I believe that "having offshore teams to reduce cost" is already a big lie. With cost going up, with overhead expenses, delays and hidden cost, there is no savings in that old strategy. I think that right now, offshore teams have grown and are mature to handle more than services. They need to enter the circle of control, not only influence. They need to become real team members and part of decision making. Otherwise, offshore strategy will prove to be a huge loss that we didn't know how to use well.