1. Ashley, what brings you here to Agile? What are you giving back to the community this year?
There are two primary presentations I've been involved in this year, supporting a couple of others, but yesterday afternoon we did a presentation called "Has Anything Changed?" and on Monday morning we did one called "Scaling up by scaling down". "Has anything changed?" is less presentation and far more workshop. The idea is we've changed our terminology, we've added a lot of new buzzwords in this community - product backlogs and product owners and all the great terms we have from XP, from Scrum, from Kanban.
But how many people really have a significant difference in the results they are getting? The workshop was all about saying "What are the problems in your team? How about we face some of those problems and solve them?" Instead of me just giving advice, we put the people into groups and apply the brain power in the room and work together, catalyze people to solve their own problems. That's a lot of fun.
I'm a great fan of getting immediate results and I'd rather have the people walk away with something they know to do different and they are doing it right away. That was the focus there. In "Scaling up by scaling down" you start with the assertion that it's impossible to have an Agile organization of any scale - team, division or company - without having individuals behaving in an Agile manner. The scaling down aspect is focusing down on the individuals, on the interactions, on that principle we've said since the beginning of this - we value individuals and their interactions over process and tools.
The process is still important, the tools are still important and in large scale engagements, any time we want to adopt Agile in a cross-continent multi-side situation, there are environmental factors we must deal with. Behind all of them, the thing that keeps us from making progress is individuals and their interactions. That was all about helping teams go from where they are to being high-performance teams by focusing on the small.
There is a focus to get to results. I'm not quite sure which comment you're talking about. I'm a little lost there, but why the focus on scaling down? Simply because many teams that we've worked with and we hear similar reports from others, have adopted all the buzzwords, but none of them right behaviors. They think they are doing Scrum, they think they are doing XP, they think they are doing Kanban, some think they are doing FDD and really they are doing what they used to do and applying a different vocabulary to it.
The focus on scaling down is a focus on individual behaviors. Specific example - Ken Schwaber has made several comments that Scrum exposes problems, it doesn't solve them. Just a couple of days ago I was chatting with a couple of people who wrestle with the interaction with their product owner. They are not getting a clear sequence in their backlog, they are not getting well-defined stories. They are really not sure what to do with that situation.
They had an "us and them" attitude towards the product owner that was impairing their ability to even to make progress in their relationship. They are not facing the real problem, they are viewing it as the product owners' problem, blaming them and sweeping a lot of pieces of the issue under the carpet. Really, the group is not doing Scrum. They've adopted the term "product owner," they've adopted the terms like "story," "backlog" and so on, but as they start to adopt Scrum and that surfaces those issues, they are not facing those issues and addressing them.
They are sweeping them under the carpet and with varying levels of consciousness they are "adapting" Scrum to the point that it isn't Scrum. The focus on the individual really has to do with us having the courage to face the problems that come up and the courage to commit to deliver meaningful results now and not keep postponing those results.
That's an interesting question, Dave. I think there are two places I can go with that. Is that an example of form rather than substance? Yes and no. I'm sometimes a little disappointed with the amount of energy we put in this community into debating Scrum versus Kanban. In particular that debate seems to get a little religious in some cases. I would assert that for anyone who really understands Scrum and is really doing Scrum there is so little difference between it and Kanban as to be irrelevant and vice versa.
Anyone who really understands Kanban, there is very little difference between it and Scrum. Yet, there are people who are misapplying Scrum, focusing on all of the stories in one sprint at a time, running them in parallel, not understanding the concept of continuous flow and work in progress. These people are missing the point. The disappointment to me is that we focus our debate on process A versus process B rather than understanding what it really takes to make them both go.
There is an adoption maturity issue. People start with Scrum; I don't expect them to have everything perfect on day one. I'd rather that we look at what they are missing. In this case it's continuous flow and low work in progress, the team focused on priority number one story. I'd rather we have a look at those gaps and we correct them rather than looking at those gaps and saying "We need a different process." I think we have a little bit of in-fighting in the industry there in a way that's not necessary.
I'd rather see us put that energy into making a difference than fighting process A versus B. On a different level, is it an example of people avoiding the focus on the individual? The yes part of that is yes. Why is it that so many Scrum teams miss some of the key points that Kanban brings out better - continuous flow and low work in progress being a point of reference there. It's because as we go in and we start working on an issue and a problem surfaces, we stay with our same old habits. We don't really look at the problem and address it together.
We have many teams doing retrospectives and changing nothing or their retrospectives are all about "Here is what we need everyone else to do" and not "Here is what we are going to do to make it better." It's not "Let's make this thing even go the other way." We can pick on Scrum and say Kanban gets this thing about continuous flow and low work in progress better in general. We can pick on Scrum because it started earlier and it became visible earlier and has more people on it. And therefore there is more misapplication because the community is much larger.
If Kanban had gotten there first and Scrum had gotten there second, I'm pretty sure we'd picking on things in the opposite direction. The question is "Are we really focused on value? Are we really focused on delivering immediate results right now? Are we really focused on noticing the issues that come up that impede those results addressing them now? Are we afraid to speak up? Are we afraid to call a team meet on the fact they are operating in an ineffective way?
Are we afraid to have an open conversation with the "them" in the "us and them" and treat them like humans and work through the issue together? Those are the things I think are really stopping our progress.
Do I see this big problem? In a perfect world, I'd love to see this all happily marching in lockstep towards a productivity nirvana. I guess I'll look at the full half of the glass here and say that if there is a group of people passionate enough to say "We need to get together and take something and try and make it better" it's great. Does their splitting off means there is a problem with the Agile community? No, I don't fundamentally think so.
If two different communities decide to start having a war with each other "My way is better than your way," I think that's misdirected effort. But I don't see that happening in the case that you talked about. If there is a piece of the Agile community that a group of people think they want to make better and they are passionate about it, then great. Let them make it better. If they choose to adopt another name and umbrella, I guess I have other things to focus on there. Really I haven't thought about this question a lot.
The reason I haven't is because one of the things that we frequently tell our clients consistent with the message we're talking about here is to focus on yourself first. If a group of people want to go make a change in the Agile community, go start another movement, that's fine. If I find something and that bothers me, the first thing I'm going to do is to look me and say "All right. What is it that I want here in this situation?" And am I taking responsibility for that? Am I treating them as humans, or an "us and them" situation and dehumanizing them?
Is there a productive thing we're moving together on? What's my role in making us more productive? In the case you just decided "I don't personally find any big gap, nothing that makes me angry with them for being angry and going doing something." I'm glad there are more passionate people working on making the world a better place. At the point I have an objection to it, I'll figure out how to take ownership of that and get involved and see if I can direct it in a positive way.
5. What exactly do you mean by personal Agility? Do you have a Manifesto?
I don't have a manifesto although this seems to be the thing to do in this business, doesn't it? When I talk about personal Agility there are a couple of things that I mean. I'm talking about individual skill, things inside of me that allow me to respond effectively to what's around me. There are a couple of elements Christopher Avery and Bill McCarley have done some work for many years now that's been voiced in the Agile community before on an area called personal responsibility.
They've studied what are the ways that we as individuals avoid taking responsibility and avoid taking ownership - when we blame others, when we justify and say "This is just the way the world is" or we go into shame, beat ourselves up -- where we're focused on beating ourselves up instead of solving the problem. Or when we do things from a sense of obligation, doing what we feel we have to as opposed to fully taking ownership. Those are things that are normal and natural and keep us from taking ownership or taking responsibility.
Any time we're in those places - blame, justifying - things I've just named, we're not learning. We are trying to cope with things as they are, but we are not learning, we are not growing and thus we are not able to be personally Agile and respond well. That's one element of personal responsibility. A second element that I've alluded to a couple of times is how we view others. I've referred to "us" and "them" which, Dave, I know you are well familiar with that pattern.
To explain this, I would just ask people "Have you ever been in a conversation with someone where they were saying all the right things? They are smiling, their body language is good and you just know in your gut that they are completely insincere." You are getting a story that just has no reality whatsoever to it. We've all experienced that at some point in some way. Someone comes across a slick and just in our gut we know something is wrong with them.
What I'm talking about here is there is a difference between at one level what our behavior is, what we're doing and at a deeper level our way of being internally, how we feel about things. So I can do some action whether it's talking to you about dinner tomorrow night or whether it's being deeply involved together in a sprint planning meeting or anything else. I can do something coming from two totally different attitudes. One is an attitude where I view you as a person, a partner in the process, someone that I need to work together with, cooperate with.
The other is where I view you as an object, as a non-human or an obstacle to what's going on. And if we're supposedly working together and we're smiling at each other and doing the right things going through the motions in our meetings. But I'm coming from this place where what internally is I'm viewing you as an object. That will come through to you and it will communicate in many cases far more than my words do and it will damage our collaboration. The second element of personal Agility is my way of being.
There is a very fine book on that topic from the Arbinger Institute, called "The Anatomy of Peace" that goes in much more depth in this idea of the way of being. That's the second one. Both of these so far are simply about me maintaining the ability to see what's around me accurately and respond to it effectively. When I mess up either of these two things, I lose my ability to see a lot of what's around me because my vision narrows, I'm too busy blaming or something like that.
A third element is my ability to simply face the truth, to confront. In the workshops we did the last couple of years, at the conferences there are some exercises we did with groups to help people understand that if you and I sit together and face each other to work through some issue, we usually think that the content of that issue is what we're feeling stressed about. But if we simply sit down and face each other and take away all the content and look into each other's eyes from arms' length away and we're silent that's an extremely uncomfortable thing for people.
The act of facing another human is a confrontational thing. When we add to that the content of us having a potential disagreement, then that begins from there. If I can't deal with the discomfort of simply facing another human or facing that situation, if I don't develop the skill of being able to confront, then I'll never have the ability to respond to what's coming up as Scrum surfaces problems for me. I'll never be able to approach and resolve these problems in any kind of a personally Agile manner.
There are other pieces of more details that we can go into at a finer level, but at a surface level it's about individually taking ownership, responsibility. It's about approaching those around us from a perspective seeing them as humans as opposed to obstacles, and it's about maintaining our ability or increasing our skill to face the truth as it is today, even if it's uncomfortable and then do something about it instead of the avoidance pattern we are offering. In a nutshell, that's personal Agility.
The way we cope with it is by going after specific results. If we sit down with the team and say "Let's do some team therapy" first of all, there are very few teams that are going to buy that story to start with. There are very few managers who are going to say "Let's fund the team therapy." That goes on from time to time, people are willing to go out and do a ropes course or whatever it may be for team building, but my preferred approach to solving those problems is to get in the real game.
Let's build the team by winning together, let's not build the team by going off and doing a totally different activity. Let's sit down as a team and take on something we need to accomplish together - the bigger the better. By taking on something bigger, something ambitious, it forces us into a context of having to deal with those uncomfortable issues. As soon as we're in the context of having to deal with those uncomfortable issues there is something practical to deal with. Now it's not soft fuzzy stuff. It's the problem right now.
The opportunity, whether it's you or me or an Agile coach somewhere, really comes when the emotion comes up, when the challenge comes up in the project. If a team never has any emotional issues, if they never have any stress, any tension, then you have one of two things going on: either they are doing a good job of lying to you and you are not staying around enough to see past or they have very low goals. There is no stress; they are not outside their comfort zone. Stress is a magnificent thing. We learn when we get outside our comfort zones.
The approach to it, from my perspective, is simply crank up the stress a little bit by raising the bar, elevate the goal, do something truly worth doing, then get in and see what emerges in the team and every time there starts to be a point of friction don't let it get swept under the carpet. Look at what's happening in the team. If they are dealing with it, it's great, but as soon as they aren't able to deal with it, as soon as they want to sweep it under the carpet, as soon as somebody wants to walk out, there is the point to engage on.
We engage from the perspective of "Let's have a worthy target right now. Let's deliver immediate lasting results." And then let's handle the emotional obstacles that come up along with the physical tangible obstacles that come up. They are not really two different things because what really happens is the tangible objects come up, the obstacles, the objections and they've been around for decades in the most organizations. They are not new because we're doing Scrum or XP or whatever. They've just shown up because Scrum exposes those problems.
Then we start dealing with that real tangible object, the tangible objection or obstacle, the thing that's not working well right now. The example earlier was the product owner who's not functioning. We've never had effective requirements moving through. It's just now it's obvious to us. Unless we start trying to deal with that, we run into the emotional issues behind it. We know we didn't have effective requirements falling through, why did we never bring it up? Why did we never have that conversation?
What is it about me that keeps me from being willing to say to you "Dave, this isn't working right now. We need something different here. How can we do this together?" It's all about driving to immediate results and then handling the soft stuff in a context where it isn't soft stuff, it's extremely tangible, it's extremely real right now. In fact, it isn't soft stuff at all. It's very hard stuff and that's why it's a problem.
I think the answer is obvious right off, but I'll say yes and then let me amplify that a little bit more. If I want to help you with your problems, I'd better be able to deal with my own problems. It doesn't mean I'm perfect. Perfection is a journey, not a destination, just like Lean is a journey, not a destination. We'll always find more ways to reduce, I'll always find something else to work on, but if I can't face my own challenges how in the world am I going to help you face yours.
I do think we occasionally run into situations where we get sucked in to try and help someone else with their issues, simply because it's easier for us than facing our own issues. One of the small nuggets that I have learned along the way that I've really appreciated is whenever I see something happening with someone else that I start to feel really irritated about, I stop and I look at myself and I say "What is it about this that irritates me? Why is this individual irritating me? What is it about them that I'm having a problem with?"
Then I ask myself the honest question: "That thing that I see in them that irritates me, do I do it too?" My experience with that is that the things that find irritating in others are merely reflections of weaknesses in me. It's one of the best ways I found to identify those things that I need to improve on. Do coaches need to be personally Agile? Absolutely. We all do. In fact, I'll take this a little bit further. There is an industrial age mindset that has carried over in the software environment and it's horribly broken.
It's the notion that the workers are a machine and there is management and there are the workers. If we're flipping burgers and doing an entirely mechanical task, there might be truth in that, but when you are doing knowledge work, when you are doing product development everyone must have leadership skills. We talk about self-organizing teams. They won't self-organize if there are no leadership skills in the team in every individual there. Personal Agility matters because this whole self-organization thing is about self-leadership.
The immediate results that we're after require self leadership as well as group leadership. Does a coach need personal Agility? Yes. Does a programmer need personal Agility? Yes. Does a Scrum Master need personal Agility? Yes. We all need this. What's the opposite of personal Agility? It's the inability to personally respond effectively to the issues and obstacles that are coming up.
Oh, I might be. I'm sitting here at the conference with a whole bunch of people that are because many do view Scrum, XP and these approaches as being about process. There is some truth in that. The fundamental value in the manifesto that we cited earlier was we value individuals and their interactions over process and tools. Let's take the analogy step further. If I'm looking at a machine, that machine breaks down into a lot of small pieces - gears, belts, pulleys -- things that all have to work together. That machine works because all of its individual parts work. People aren't quite as deterministic as a gear in that machine.
In fact, Alistair Cockburn said very nicely in the first edition of his book "Agile Software Development." I think the phrase was - "Them's funky people." That was the heading for a section. In order for us to be effective, if we want to view process as a machine, we have to make it work with the sub-components of that machine. If we apply the assumption that everybody is as deterministic as a gear in that machine, it will fail. Because people are not as deterministic as the gear in that machine. We need to work with a little different bounds there.
Would I completely reject the notion of process? Oh, no. In fact, [W. Edwards] Deming made a comment that over 90 percent of failures (I think the exact statistic is 94 percent of failures) are in the system as opposed to the individual. There definitely are environmental aspects, process aspects, many things that matter there. We can set up an environment that encourages people to behave in very poor ways. We can also set up an environment that encourages people to behave in very effective ways. Process does matter. We simply need to recognize that this process is executed by human beings and we need to make sure that we treat each other as human beings.
We need to make sure that our expectations of each other are clear and we need to make sure that we have the skills as human beings to operate within that process. To the extent we fail to develop those skills it's like putting broken gears in the machine.
I don't necessarily try to predict the path that far out. He's many years ahead of me. I have a great deal of respect for Jerry Weinberg; he's done some wonderful things. I'd recommend his work, his books to anyone in the Agile space - it's very complementary. I will say I do not see myself as extracted from software as Jerry really has done and the reason is because software gives us the context here. If I wanted to go be a therapist like someone you referred to earlier, I would have done that.
But the beauty of software is that there is something we're supposed to deliver right now and it's just extremely tangible. Solving the human problems that are barriers to immediate and lasting results, while working in a context as a very tangible problem we are supposed to deliver on right now, is in my opinion (at least for the moment) a far more effective place for me to work on solving those individual problems. So, no, I don't see leaving the software field for the reasons that Jerry has.
Kent Beck's comments about transcending the process are really at a team level of XP level in the way that I asserted earlier that you cannot have an Agile team, an Agile organization, an Agile company without having individuals behaving in Agile manners and being Agile. In that sense I'd say it's one continuum. We as individuals have to get past the rote following step stages into the effectively practicing stages and beyond that into the fluently combining things together. A lot of that has to do with the things that we're talking about here today.
A lot of this has to do with many other things - technical skills, understanding the different things we're combining. There is a presentation coming up tomorrow here at the conference on Shu-Ha-Ri, which Alistair Cockburn has written about the stages of learning and really is the transcendent stage. The assertion in the description for the session tomorrow is we as a community are stuck in Ha. We're in this practicing phase, we're past having to follow every step but we're not transcending. It's an interesting question that you bring up.
Ultimately, we as individuals not only have to be expanding and growing in those ways for our teams to. But more than that, it's a matter of us going from a view where problems are the bad thing and the obstacle to a place where problems are something we deal with and get on with. Then, moving to (there is order in all the transcending phase) where problems are gold, they're a treasure. We love when one comes up because it points us to the next thing we need to work on. It would be a problem if we didn't have something we need to work on.
It's about an individual and the organization getting to where we turn these problems into huge assets. We take the specific context of a real software development problem, find a really thorny problem in there that's keeping us from going somewhere and we don't just get past it. We say "How have we created this problem? How are we holding ourselves here and we let that problem be the mirror of that shows us what we need to do to grow as individuals and as a team, and then we turn it into a tremendous asset. That is (to use an old metaphor) an organizational alchemy, that's turning lead into gold in our organizations. That's transcendence.
Two comments. Let's talk about the "don't lose" part before we talk about the "play-to-win" part. There is a colleague that I've worked with for some time who was at a PhD program for a while and he left that program eventually. The program that he was in was very process focused and he had experience with Lean and Agile techniques before he entered that program. Early in the program he heard one of the key professors in that program say "It's all about process." We've got to quit dealing with individual variation, we've got to tighten the process.
This research program that he was involved in was all about how do we use processes as a vehicle to squeeze out individual variation and ignore those factors and get to where we can ignore those factors. My colleague jokes that it took him far too long to figure out that he had a severe mismatch of values with that program. The first thing I'd say is "Let's get the right goal here. Let's recognize that software development is human. Let's understand that computer aided software engineering is computer aided and humans are still involved.
Let's not take on the wrong goal, let's understand the relationship of process to people and let's acknowledge the people part of it. To anyone in academia who reacts negatively to that statement I would say that we have a deep values mismatch and I'd love to have a conversation with them because that's frankly where I think damage is being done in the industry and in education. I think we, occasionally (maybe more than occasionally), lead people through programs and let them graduate thinking it's all about technology and it's not about people.
Now let's talk about how to win and how to move forward with it. We know this as we hire and recruit people that most university programs are really good at creating individuals and really bad at creating teamwork. If you are in academia or if you are in school and you collaborate and reuse, that's called plagiarism or cheating. In industry, if you fail to collaborate and reuse you are so ineffective and so inefficient that you destroy your team or organization's capability. I'd like to see a lot more team type work in academia as opposed to individual work.
I'd like to see people put in the situation where they have to perform in a team context. I'd like to see more communication going on. But all those things aside, I could go further; I could ask everybody to take psychology classes or something. I don't think that's profitable. I think that we discover the degree to which we need to work on these skills by running into real problems in the real world. Would I like people to work in team situations as opposed to individual situations in order to create context for the problem to emerge? Yes.
Would I like to go sit them down in theoretical class to deal with psychology in another individual context? No, I don't think that solves our problems in the industry. Let's put people in situations that are closer to real industry situations. Situations that require team work, preferably situations that set a very high bar a very high standard that compels people to grow. Let's pull people out of their comfort zones and let's cure the stereotype of software development as being a sole geek in a cubicle sport because it's not.
It's very much about communication; it's very much about collaboration. Our success as an industry hinges on our ability to communicate effectively, to clearly identify what is the value we are here to produce together and to see every obstacle to that as an opportunity to get better.
I've know you for a long time and we can talk for a long time, I have a lot of fun with this. I guess the only thing I would say to anyone who happens to look at this I challenge everyone in this industry to set a higher bar for yourself, to set a higher bar in terms of delivering real tangible results your customer will pay for. I'm talking about measurable value. If it doesn't translate to dollars, you are not doing something valuable unless you're in a non-profit. That's a very confrontational statement.
But let's look at it from the Lean perspective - there are things that directly contribute to value and there is everything else. Lean calls that everything else waste. Our job is to continually figure out how to refine the way we work to reduce that waste and put more of our energy into value. I challenge everyone in the industry "Figure out how can you deliver more value today?" and I do mean today. I don't mean next year, I don't mean next quarter. How can you deliver more value today? The key to doing that, will be to look at all the things you are doing, as a team as an individual and do less of them.
We're not going to deliver more value by doing more; we're going to deliver more value by doing less of the things that don't deliver value. Set a higher bar, set a higher standard, hold yourself accountable to it, be willing to be accountable to others and let's go somewhere worth going.