BT

Amr Elssamadisy – Safety
Recorded at:

Interview with Amr Elssamadisy by Dan Mezick on Aug 02, 2013 |
18:44

Bio Amr Elssamadisy, founder of Agile Culture New York and author of the book Agile Adoption Patterns: A Roadmap To Organizational Success, is a software development practitioner. He works with development teams of all sizes to learn and use new technologies, adopt and adapt appropriate Agile development practices, and focus their efforts to maximize the value they bring to their organizations.

Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

   

1. Hi, we’re here at QCon New York City 2013 with Amr Elssamadisy, Agile coach at Industrial Logic. Welcome, Amr. You and I talked a little earlier about something you referred to as a missing core element or ingredient in the implementation of agility in this world. Tell us a little bit about that.

Sure, thanks for asking. So, I’ve been doing this Agile thing for a while, since 1999 and I’ve helped hundreds of teams adopt and adapt Agile, some of them successful, some of them not so successful. And I’ve had experiences with teams that were successful, make good friendships, talk to them a couple of years later “Joe, how’s it going?”, “Well Amr, unfortunately it didn’t last, we had some problems with the organization, with the culture and it was kind of shut down”. And I’ve been making things effective, making this Agile adoption effective, is something that I am really very passionate about. I’ve been lucky enough to experience these hyper productive teams four or five times in my carrier already and in looking back I’ve found a lot of missing elements. There are things about human dynamics. There are things about culture. Most of them are invisible, they’re not code, and they are as important - if not more important than the technical practices themselves. But one thing that is more core, more base than anything else is safety. And I’d really like to explain that. I’d like to show the world through my eyes and how I see that the lack of safety and the way Agile is designed almost has the seeds of its own destruction and we’ve got to focus on creating safety to get the results from Agile teams.

   

2. Yes, this is really interesting. Over the years there have been vocal proponents of Agile who talk about it really being a learning machine. For example Chris Matts wrote about this several times and you and I have talked about learning as an essential ingredient in successful agility. What’s the role of failure in learning and how does that map to safety?

Thanks, Dan. So, I’d actually like to step back a bit and talk learning. Learning is the biggest single base part of software development, whether we’re using Agile or Waterfall or anything else, we learn and the faster we learn the faster we produce software. Many of us have had the experience of losing some code that we may have worked weeks or months on and rewriting it at a fraction of the time. And there are other things, we learn about each other and so on and so forth. So, learning is huge. And if we can increase our ability to learn, we can increase our ability to produce great software, productivity, quality, the whole thing. Now, Agile, when it works really well, those teams that get it, they get those 200, 400, 500% improvement in their productivity, those teams have figured out how to learn and they learn from failure. Agile, whether it’s Scrum, Kanban, XP, any of them, it’s all about iterative loops and experimentation and doing something and failing and learning from it and doing something and failing and learning from it.

   

3. Yes, so can you drill into experimentation a little bit and the role of that in learning and what do we do with experiments that go terribly wrong?

So, in general, in the Agile world the idea is we keep those experiments small so we have small failures. And we look at them, we confront those failed experiments and we say “Oh, OK. I wanted this over here, I didn’t get it so let me inspect and adapt and try to solve it again from that new information that I’ve learnt from the failure”, that’s when things go right and when teams can learn from failure, nothing can stop them.

   

4. Can we do experiments if we’re afraid to fail?

And that’s it. If we’re afraid, if we’re unsafe, then we can’t learn. We can do experiments but we won’t get any of the benefit because what happens is teams end up going through the motion. Some examples: there are teams that when they do Scrum the say “alright, we are going to do these five things this iteration” and they get three of them done and they say “alright, good job team, we did our best” or if they are doing two week iteration they say “let’s do another third week so we don’t actually call it a failure” or there are teams that do daily work, daily cycles and say “alright, we are going to up the level of quality” yet by the end of the iteration, when the deadline comes, they don’t, they cut corners and they call it a success. Teams and individuals are very uncomfortable with failure, they feel unsafe to fail, and if they feel unsafe to fail, they game the system and they don’t get any of the benefit.

   

5. Is this especially acute in software development where we get paid for right answers and it’s a very left brain type activity and expertise is really paramount and know how, knowledge? Is it like a huge colossal train wreck to actually not give the right answer?

You know what, I think the short answer is yes but that’s not only in software development, that’s western culture in general. We are taught in school - right answer, work alone, you’re graded, and if you don’t get it right the first time you fail. And so we are predisposed as a culture to be averse to failure, to feel unsafe when failing and failure happens at multiple levels and if you don’t feel safe, there are so many ways we can feel unsafe in failing. For example, we’re working with a really good team and there is this ace on my team and I say on my daily standup “hey, I’m blocked on this thing” and he says “you’re blocked on that? That’ll take me five minutes”, I shut down, I’m unsafe now to share my failure. If there is a disconnect between business and development and we miss a deadline. Or you know what, Scrum, we thought we were going to run a velocity of 30 but we are only running a velocity of 20, are we safe to communicate that? Will we get fired? Will we have problems? Will business and executives allow space for that? Unfortunately, the fact of the matter is because we don’t explicitly focus on failure the answer is no for most software development teams in most organizations. Go ahead.

   

7. That’s interesting. So, now let’s talk a little bit about a drill down into safety. So, can you define safety for us a little bit so we can have a vocabulary as we go forward and use the term?

Sure. Safety is a wide area. One way we can take a look at safety is through personal safety and culture safety, if you will. Personal safety is a mindset. There are some of us who feel safe in a burning building, there are some of us who feel unsafe crossing the street, that’s personal and there are things we can do about that. Most of us are not at either end of the spectrum. And then there is the cultural safety or the team safety, our expectations of us and how we deal with each other. That example that I gave of the ace going “Ha! I can do that in five minutes”, that’s interaction, that’s safety within the team and in the organization. The idea of getting fired if we don’t meet a pre-imposed deadline, that’s cultural safety. And so there are two things that really affect our feeling of safety and this is what it comes to, it comes to our feeling of safety, not some objective measure, it’s very subjective.

   

8. So, safety is an irrational quality. It’s an emotional, largely irrational, quality?

It is, it’s emotional. And the thing is we dismiss it because it’s emotional, yet it undermines us. If we don’t focus on creating safety, it undermines our ability to do great work, period, end of story.

   

9. Ok, so we know the problem. We’ve defined the terms. What are some practical things we can do around interactions, activities, protocols that can help us develop safety in the now, in real time so that we can keep that fresh?

Some things that we can mention, there are many, our time is limited, I’ll mention two or three and at the end this is an open conversation and it’s an invitation to the community to focus on this and really look at this missing element that’s impeding our success. So let me come back to your question, what strategies or tactics can we do? Well, I said there is individual and interpersonal. On the individual level, there is a mindset, a mindset of when there is a problem, do I believe that I can get past the problem, and if I believe I can get past the problem then it’s usually safer. And one way of looking at that is for example Christopher Avery’s responsibility process model. He basically takes three levels, I won’t go through the whole thing, but it comes down to “are you coming from ownership or are you not, are you blaming others are you doing things because you have to?”; that’s a choice, that’s a mindset, if you can get yourself in the mindset of ownership, “I own what happens to me”, that’s a safe place to be, that means if something happens around me I don’t feel helpless, I can choose to respond to that.

   

10. The model is I’m responsible for all of my results?

I’m responsible for all of my results. The more we can be in that mindset, the safer we will be.

   

11. Ok, cool. Now what about interpersonal techniques we might use?

What about interpersonal techniques? Well, one of the ways we feel unsafe with people around us is if I feel they’re out to get me, they’re going to attack me in one way or the other. There is a simple but very effective mechanism called “Check In” from Jim McCarthy. And when we convene any meeting, when we sit down and work together, we check in, we say “here’s how I’m feeling, mad, sad, glad or angry and I am in”. And a very simple exercise like that, if you can turn it into a habit it creates an intention, an awareness that “hey, people aren’t out to get me, I know, Dan, you are having a bad day, you are mad because something else happened, not because of me and maybe James over here is angry because his car broke down this morning”. And being aware of our intentions and each other’s feelings creates a safe place.

   

12. Can I opt out of disclosing my emotional state or is it mandatory in the check in?

Checking in is a wonderful way to create safety and a wonderful way to give the message that “hey, nobody’s out to get me”, I know it sounds paranoid but that’s what the little voices in our heads sometimes say.

   

13. Yes, I get it. So, if I reveal some of my emotional state, you can feel more safe?

Absolutely. If you’re vulnerable in front of me, then I don’t feel bad for not being perfect and not having a great emotion.

Dan: Right, and you don’t have to guess my emotional state.

And I don’t have to guess your emotion, I know your emotional state and I know why.

   

14. Ok, so during check in can I opt out of disclosing my emotional state during the check in protocol?

Absolutely, you can opt out of anything. And you know, opting in and opting out in general in anything is one great way to create safety, “I’m there because I choose to be there”, it’s also a great way to encourage ownership in the people that participate with you.

Dan: Beautiful. So, my next question about check in is if I can check in, that seems to imply I can check out.

You’re not stuck. You can always check out, and it also creates safety. If you verbally say “I’m out” and you give a reason that doesn’t leave me wondering, “Oh, what happened, why did Dan leave?” Without verbally announcing what you are doing and feeling, it leaves us to guess and when we start guessing that has a good chance to create lack of safety. So announcing, in general, announcing your intentions and feelings is a great way to create interpersonal safety.

   

15. It takes guts to do that if there’s not a formal structure in place, it takes guts to actually express what you think and feel, right?

A18 It does, so it does help to have a formal structure in place. I know you are alluding to Jim McCarthy’s core protocols, so checking in and checking out are two of the core protocols. And in general, if I were to even step back, by having clear agreements on how we work together, whatever they be, the core protocols or anything else, we make it very clear our expectations of each other. If I know my expectations and what I can expect from everybody else and what my responsibilities are, that also creates a safe space. So, there are many, many ways to do so. And the fact, here is what I am saying, here is the story that we have. Learning is absolutely mandatory to high performance software development teams, period, end of story. Agile works well some of the time. Agile works well when we can increase our capacity and our ability to learn. The main way individuals and teams learn in Agile methods is through failure, but failure is inherently unsafe. Failure is difficult and in today’s business world we are trying to adopt Agile methods to get the great results in an unsafe environment and with people who don’t feel safe, and so it fails to get those results. We get at best incremental improvements, not the great improvements that we look for. So what do we need to do? We need to make things safe. It’s the base. It’s the base for anything and it’s the base for learning. Without safety you cannot learn effectively from failure.

Dan: Ok, so this sounds like a call to action to the world wide Agile community around safety.

It absolutely is, Dan. At Industrial Logic we’re working on it, we’ve been experimenting with it for months. I know people like yourselves and Josh Kerievsky and me and a few others in the field have been going towards this. But this is a call to action. This is so obvious. It was invisible, but it’s so obvious to us that to learn from failure we need to be safe and we are not directly addressing safety. So this is a call to action and a hope that we, in the Agile community, can start focusing and figure out how do we make things safe because, you know what, we are not getting the results that we want for ourselves or the people we want to help. And we can.

Dan: Very interesting, Amr. Thank you very much for your time today.

Thank you for your time.

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT