I'm Amr Elssamadisy, as you said. I've been in the software field for 20 years. I started developing as a developer in the C++ environment, hands-down coder. I was introduced to Agile development a little over 10 years ago now. It was on a Java project that was failing. We learnt about XP, we rewrote our project, it saved our butts and since then I caught the disease and I've learned more and more about it and as a consultant, I've been helping people get from here to there, what is Agile and then how to get there. My passion and my focus has been on practicing Agile development and really getting the value out of it and helping people do so.
Absolutely. I'm currently at Gemba Systems and all we do are Agile adoption initiatives. I'm very focused on how to better help people get from "I want to do Agile development" to actually doing it safely and getting the value out of it. My real focus these days, as I look back on 10 years of what we've been doing is this stickiness portion of it. There are a couple of models out there today. Model no. 1 is you come to software consulting company and say "Sure, we'll help you. We'll give you 20-30 people to augment your team and help you out and they are the experts and they'll work with each of your team 1-1".
They'll be there for an amount of time - that's expensive, number 1, but even if it's past the expense, often times what happens is when that ex-team of experts leave, things go down the chute. The home team, the company, the client is really used to the experts being there and by the nature of that type of consulting, I think we do a lot of harm to our clients. We don't help them stand on their feet, we actually - I don't think on purpose - hurt them in the long run because they are so used to having the expert or the guru there. That's model no. 1.
Model no. 2 is "We're going to be here and we're going to be with your team in the beginning and then maybe we'll come back at the end of your iteration in a month and be there for your demo and retrospective and help you kick off" and so on. That sporadic involvement also has a problem, it also isn't sticky, but for a different reason. In those long times the team stray left and right and it really takes time and a lot of feedback that's not there.
Over the long term, there are always success in both models, but the majority of them also have the same problem - they stand up on they feet, but eventually they don't see the great values. They may be a little better, but not significantly better. That's really what I'm focused on these days, this stickiness aspect and that's what we've been working on. What we found is that a focus not on the practices, whether it's the practices here or the practices just being there for a long time. The focus on the practices and the Agile software development practices themselves is not enough.
There's a layer below that that doesn't necessarily fit in the normal definition of Agile Practices that people in the community, like Christopher Avery whom you interviewed earlier this week and others have been talking about, that are really mandatory and if, by luck, the individuals of your team have ownership come from responsibility and don't blame each other and know how to deal with confrontation very well. Tobias Meyer, yesterday, in the interview, said that Scrum is really good at showing you the problems that are there, but if you don't know how to react to those problems, as individuals on the team, it falls down.
In one model you don't see the pain, because you've got all these people helping you and you don't see it until they leave. In the other model, because the experts come in so sporadically, it's really hard and difficult to deal with these human issues that transcend Agile development. They are actually everything in what you and I do at home, what other companies do. These human skills of being able to confront problems and deal with them, of being able to take responsibility and not blame folks, because when you are in blame or you are in obligation you are really not going to do a lot of work. You are not going to get to high performing activity.
There is improvement, but the high performing activity that happens and happens a lot of times by accident, when you look at it, it's either of these models working, but with teams that have these skills naturally. There are many of us that either have learnt or have these skills or have the natural talent of dealing with problems and confronting them instead of blaming them. To get back, that what we found is the key.
Again and again and again that's the secret to making things sticky, that's the secret. I had a presentation with my partner Ashley earlier, called "Scaling up by scaling down". We believe that's the key to scaling up, by making sure that the people, the individuals on the team, before they have these Agile practices, before we're talking about Lean, that they have the necessary individual skills to deal with problems.
You are right. There are several talks in the conference this year and more so than last year, that are focused about this. I believe next year there is going to be even more, as Dan Mezick, who we interviewed earlier, said, he'd like to see a lot more of that and he sees growing interest. That's a really good question - the question of how do you do it? And the question of "Are we on a verge of another breakthrough?"
Let me answer on the verge of another breakthrough first. The answer is "I don't know". As we said, these are human skills, these are human things that have nothing to do with Agile. When we are talking about we want people being responsible and taking ownership and stepping up to the plate and understanding how to confront without fighting. Actually, see a problem and say "OK, there is a problem. How are we going to deal with it?"
Can we actually grow organizations where people do that? By the way, this is a skill that isn't only for work. If you learn this skill, you take it everywhere in your life. The question is a little intimidating to me "Can we get past our human nature and grow and be there?" More of us, a significant number of us are like that, I have a big question mark on that.
I'd like to think so, but it's not a small problem. At least we are aware of the problem. If the beginning to solving a problem is seeing it and knowing that there is something to solve, that leads into the "how". On the interview on camera it's really hard say how, but we can take, for example, learn about learning. There are categories that we need to know. We would benefit a lot to know when we learn the most. It turns out that, as human beings we learn significantly more when we are passionate.
If we're not or we couldn't care less or we're burnt out or we hate our job and so on and so forth, we don't learn a lot. In fact, learning is a very big part of software development and many people say it's even the bottleneck, like the largest part of software development is in learning. So, learn about learning, if you will, and create an environment where you learn. That's a whole area and category into itself. We also want to learn about how we act as individuals.
Christopher Avery's model is one of the many, but one the useful models taking ownership, being aware of how we react as people, when we have a problem - "It's not my fault! It was the camera crew's fault!" and then moving up until we really take ownership and do things. That's another category - individual responsibility and ownership - and it's not new. Christopher Avery's work is new when it tells you "All right, here is how we can go from step A, B, C, D and to get to responsibility", but responsibility and ownership, these are values that we've known for thousands of years. I don't know, I think as human beings we can't succeed without them.
These are values that are known. There is the other part hard about confrontation and facing reality and accepting what is and moving on with it. Meditation - you can go to Eastern schools of thought. There are many things that are there. The categories are there and these aren't really new sciences that we're discovering. It's really all things that we've always known, but for one reason or another, they are not part of our lives and we've never seen them as part of business or even important to business.
I think the key is recognizing that "This is important, necessary for successful businesses, for that hyper productivity, for those teams and those organizations that blow everyone out of the water". That's what we need. As long as we're aware of the first step, as long as we're aware of the problems, there are many solutions to each one of these problems that we've had in our history, anyway, because they are not new problems.
It is and it's simple, but extremely difficult, not easy. These ideas that we've talked about are simple ideas, things that we've grown up with as children and that we knew and that we know and we know as cultures. This isn't just American culture or Wester culture, this is all over the world.
5. The thing I see you are excited about is we've identified something, how do we get there?
Exactly. How do we get there? Start focusing with the individual responsibility. Teach people, learn about it yourself and teach and the hard part of these is I can't lecture you and tell you about it. I can tell you about it and perhaps, if I learn it and know it and model it, you can ask me and I can tell you how to exercise. This comes with exercise, this comes with doing. What the real power in this is, is it sheds a light on the hyper productivity. It's not just an Agile and the techniques. Agile and the techniques and good and well, but they are not sufficient. When they are built on top of the lack of these things, they are going to fail like any other thing. You know what? If you have these things, you are going to succeed Agile no matter what or anything else.
It's very good that you asked me that. That means I should clear something up. I'm not asking for people to be confrontational, I'm saying that people need to be able to confront the problems. There is a slight distinction there. In our stereotype of confrontation, we think "OK, somebody who is - if you will - a hardass, you can't get anything past them and so on and so forth". In a way, that is what I'm asking.
What I'm asking is when we work as groups, as individuals and we agree to do things for each other because we're working as a group, whether it's a self-organizing team or not, and then you fail to meet a particular thing that we agreed upon, I need to confront you about that. In that way, we need to able to confront at an individual level, we need to be able to confront at a team level and organization level when something is not working, then we need to learn the skill of how to say "You know what? This really isn't working" and go from there.
I just wanted to clarify that, first. How do you get from here to there, because confronting a problem is very difficult, it's very uncomfortable. A lot of times, when we're confronting something, we're angry inside or, in psychology terms, we're flooded with chemistry in our brains. We have adrenaline, the chemistry in our body really doesn't allow us to think very well, because we're going to the fighter flight mode. It takes practice and there are a lot of things that we can do to confront issues outside of work as practice.
One simple exercise is to find a colleague or friend and then just sit and stare at each other, face to face, for 5 minutes. People who confront very easily and have a high tolerance for confronting, will say "OK" and will happily stare you in the face for 5 minutes, but for the rest of us is very uncomfortable. That's one exercise. You can do it again and again. Fear of speaking to crowds, fear of public speaking is a big confront for many people.
Go find places where you can do public speaking. It doesn't need to be anything specific, but it's really the practices. Find things outside the work, where it's not dangerous and confront them and face them, so that you are used to saying "Here is reality. Now what do I do about it?" and get past it. I know that sounds a little hand waving, but often times is really that simple. Again, simple but not easy because it very uncomfortable to confront. Confronting doesn't mean fighting, it doesn't mean giving people a hard time, but many times it will be perceived as a hard time, when something goes wrong and you call it, then great!
Now let's tie that to Agile - that's the key to this self-organizing team. A self-organizing team only works if it's able to recognize something and deal with it. You want to recognize and respond to change. A lot of time, responding to change needs true recognition and true recognition means you are able to look things in the eye, look in the mirror and say "This is really true. What are we going to do about it?" And we move from there. Another thing that leaders can do; I'll steal from all of the presenters.
We interviewed Pollyanna Pixton earlier, and what she has to say about leadership is you need to stand back and not tell how. If somebody comes to you with a question, you say "Great! I understand. So what are you going to do about it?" That's a lot of confrontation right there. What are you going to do about it? It's true. That's one way that you, as individuals and as teams confront and learn to confront, become very comfortable with confronting reality and saying "All right, what are we going to do about it?" It has nothing to do with software, but yet it is key to successful software development. It's key to successful self-organizing teams. It's key to this hyper productivity that we're always looking for. You can be polite and confront also.
And you bring down and you bring up the perfect point. Trust is another one that really to be able to confront, you need trust. If you have trust, it becomes easier. How do you build trust? You build trust - this one is simple, but not easy - by making small promises and living up to them, making a little larger promise and living up to it. Trust is built in a spiral. Be careful of breaking the trust because as soon as you break trust, you go right back to zero or even before zero.
Trust is very important. These are things that we've known and we know as human beings, we have to. If I feel safe, if I trust you, then I can say "You know what? We have a problem. We were expecting to do x, y, z - these things have changed all around us. It doesn't matter whose fault it is. What are we going to do about it?" You are right on. Trust is extremely important. If I were to point to another place where you see this, "The 5 dysfunctions of a team", a very famous book in business, the bottom of the pyramid is trust.
Confronting is the third step in the pyramid - I don't have the whole thing in my head. These are things that are not "the organization will trust". -No, we as individuals build trust in the organization and in turn, the organization builds trust in us as a team, as we succeed. That's where it ties in the Agile and it's helpful. Agile is constantly very iterative.
In stand-up meetings, we have this iteration - every day we stand up as a team and say "I, as Amr, am going to work on this task and I commit to get it done by tomorrow". Tomorrow I get up and say "You know what? I didn't finish this task" and I get up next day and say "All right, I've got the task" and so on and so forth. That's how is an iteration, which is longer, anywhere between 2 and 4 weeks. Again, cycling, promising to do something and delivering. That's a huge way to build trust and it's most common, but individuals first.
9. So, it's good for the Agile community, but then it's also good for the individual?
It's great for the individual. They'll enjoy their work more and they'll learn more, because if you are passionate about something, if you want to wake up in the morning and go to work, that's a great sign you are doing great. If you stay in bed and you keep turning the alarm clock off and you don't want to head out, that's an indication that something's going wrong. This is what's great about the Agile community - it's almost self-selecting. We've been lucky enough to attract a lot of people that have these talents, that aren't necessarily aware of these talents, but as soon as you see them, this is what they do, this is the people who they are and that's the secret, really.
I strongly believe that's the secret to the very significant successes early on where we saw an order of a magnitude, 10 times faster - the XP teams and the Scrum teams and so on, because those types of people that were on the team came up with this, had the passion, it was something they spread to the rest of the team. They did very well and they had that. As Agile grew, we thought it was the practices; the practices were part of it, but it's this underlying foundation that's the key to all of these.