00:29:25 video length
Bio Dan Mezick is the president of New Technology Solutions Inc, a consulting and training firm delivering agile coaching. NewTech delivers agile and Scrum expertise to organizations of all sizes. Dan is also the organizer of Agile Boston, the author of two books on software development, and a software patent author.
Agile 2009 is an exciting international industry conference that presents the latest techniques, technologies, attitudes and first-hand experience, from both a management and development perspective, for successful Agile software development.
Thank you for having me, Amr. I'm here this year as an organizer of the conference with the manifesting Agility stage and I'm also talking a couple of sessions this year. Previous years I've had a session or 2 and previous to that I entered the Agile community in 2006 with certified ScrumMaster Training from Lowell Lindstrom in Chicago and I'm just strangely fascinated with all the things Agile.
I do have certain beliefs about Scrum, some of those have been changing this week, as I talk to others, but my current belief is that Scrum is a great starting point for folks that are new to Agility and then from there they can do some improvisation, after they'd mastered some of the values that go with Scrum.
3. You've been telling me that you are really passionate about several ideas and you and I have had conversations way back and you really want to tell us about group cognition and how it applies to Agile. Is that so?
Yes, last year I spoke on the hidden life of groups and in that session I described the theory of group relations and the psychological basis of the theory and also the academic underpinnings of it. I noticed that many times in some Scrum coaching, some of the reading I was doing in group relations seemed to be evident. Some of the dynamics and patterns that I was reading about in this work were evident in these Scrum teams. I found myself compelled to go to a conference. In 2008, I attended a group relations conference in Monticello, Ohio, in October 2008, which caused a dramatic shift in my thinking about groups and my role in the groups where I participate.
I can tell you a little bit about the conference. The conference basically explores the role of authority in a group setting. You are put in various groups of various sizes in the course of a week and there is a lot that goes on, what’s studied it is, the behavior of the participants themselves during the 4 or 5 day event.
What that actually means is that in these conferences they create a temporary institution that has all the trappings of a real institution, complete with a politics and some of what we might consider dysfunctional behaviors. We go there and explore how we take up our roles in the groups that we participate in, how sometimes we are drafted into roles without our consent by others in the group and how sometimes that's not the best role for you to take up.
It is other roles that you can take up that can be more effective. For example, if you are often the person who seems to be drafted into a leadership role, that's very foreground and the group tends to depend on your leadership style or whatever. Sometimes it's good to reject that and to refuse to be drafted and to play a role that's more facilitative or, in general, more conducive to the group's task.
The reason why you care is because a lot of the latent or sort of undertones of the life of groups can generate tremendous amounts of waste, that are at odds with the stated task. Let's say we get together to produce software and we're not aware of these patterns and dynamics that are going on as an undertone under the stated task. The whole time that we're there to participate in accomplishing a goal, we're also busy basically attempting to survive as a group.
That can generate a lot of waste, as a group looks for a leader who would help the group survive indefinitely. For example, on software projects, if the group is in a spot where the stated task is not foreground, that's all just pure waste, and the only way to get out of that is by using and Agile method that focuses attention on the stated task. This is actually why a lot of Agile adoptions fail, because the group is generally more interested in the undertone than the stated task.
7. Now it becomes interesting. What I hear you say is these group behaviors, the understanding of how we think and how we relate to each other as human beings is an underpinning to everything that we do and stated Agile projects fail because they are unaware of this?
For example, if you are consciously aware of these undertone dynamics that are in play where a group is basically seeking a way to continue to survive as a group, you can bring that to attention of the group, if the group's advanced and if the group has basic understanding, you can simply refuse to participate and thereby bring in the group closer to the stated task and further away from the distractions.
8. In our history in software development, if you will, there are people who have had these talents, and people that have not and what you're saying is we need to study this more, so we can learn it and we can all do it, even if it's not intuitive to us to do that?
Yes, if you look at our work, we do a very complex thing - we build complex abstraction: software and then, it's rarely done in isolation, it's always done in teams. People, by nature are complicated. When we get into a group, we have a lot of complexity. It's important for us to understand that the complex nature of our craft, working in teams, building an abstraction, there are only a few ways to actually do that right and we've learnt that in the Agile community - there are certain practices.
These practices that we do can speed up the work and understanding of where we are as a group in terms of how we learn as a group, our shared understandings about who we are, our role in the group, the role of the authority, all of these things that we are fully conscious about, as we are participating in teamwork, we can understand we're drifting, get back on track and complete our work.
Yes. A great example would be Scrum’s short loop - the Daily Scrum. The Daily Scrum produces a resolution of drift, as I call it, of only one day, so you cannot really be distracted for more than one day without your group knowing that you are distracted. Scrum puts its attention harness on the work. Each day we go back to the work and we ask the 3 questions and that rivets attention on the stated task. There is a behavior that's actually, in some sense, imposing of discipline over attention.
We are not generally not aware of our participation in group process - that's actually a theme that comes out of a group relations conference. You'll find that, unknowingly, we are participating in some very primitive emotional behavior at the group level.
We may minimize them and focus attention as a group on the stated task to complete our work.
One of the things that I'm really keen on is education and learning and of course, cognition is a big part of that. One of the ways to really accelerate Agile learning is through the use of Agile games. These games take various forms, they teach various lessons, but basically, words can be very polarizing. When we say words like PMP or PMBOCK or Scrum, CMMI, ScrumBut, Product Owner, Scrum Master, Daily Scrum, these types of terms can be very polarizing.
On the other hand, if you are invited into a room where games are taking place, in a group setting and as soon as you walk in the door you are getting a set of playful materials, like cards and some dice and some paper and some colored pencils and all the rest of it and you are asked "Please join one of the tables and participate in the game. Here is this short list of rules about the game. Go and have some fun!" It drops your filtering process, there is no polarization, there is not about opinions or positions; you're just involved in a game.
Now, we are focusing our attention on a certain task with others, we're taking in a rich set of information and we're getting some learning in an experiential way. That's a very effective way to accelerate Agile adoption. Most of us understand that and games are well developed in the community. What I've been working on is using the game as a pretense for understanding the willingness of all the participants to actually do Agile.
13. Tell me more.
Imagine a world where the rows are the participants and the columns are their behaviors during the game episode. If, for example, you sent out an email, did they respond? If they responded, did they show up? If they show up, do they participate passively or did they participate actively? If they have authority in the organization, that's pretty important information. If they're behaving passively in their participation of the game, yet I have some authority in the organization, that's a pretty strong indicator that the person doesn't have underlying beliefs that support Agile adoption.
14. You are saying we could use the game almost as a meta-game, not the people playing the game themselves and what they learn, but for us, running the game into understand the behaviors and how ready or unready?
I call it willingness testing.
The game is a pretense for understanding the relative willingness of all the participants. Let's say that we have a person who's participating actively. After the first iteration, they are asking questions, after the second iteration they get in the game, after the third iteration they have an insight, they are the retrospective on the game. They are expressing their insight in the class. That's a pretty strong indication that's you've got a live one there, who at least holds the values and probably has some underlying beliefs that support those values.
At the end of the day, it's all about the willingness of the participants to engage in Agile adoption. Everyone is at a certain place - they are either at a certain spot that they might be moving, they might be static or they might be moving forward. Over time, you have this game - let's not call it a game - I like to call it a simulation.
We're actually operating as a psychologist as we attempt to implement these Agile practices. I think that we need to all acknowledge that.
Isn't that a very strong indication that we need to be focusing on psychology at the group level and also individual psychology in terms of beliefs and values? If you think about Agile, it's a set of behaviors, the practices are, in fact, behaviors, usually group level behaviors. But the individuals have to be willing to participate in those behaviors. If they don't have underlying values that support the behaviors, it's not going to be lasting.
Right! It's really a kind of pyramid - at the top you have behaviors, in the middle you have values and then at the bottom, the bedrock of it all, is what they actually believe and a great example of this would be the belief in prediction with software projects. If you hold that belief, it's extremely unlikely that you'll be able to implement Agile because the very essence of Agile invalidates your belief about the certainty of prediction.
At the other extreme, if you believe prediction is futile, until you have some statistical data on 3 or 4 or 5 iterations, then you are in a spot where you have the supporting belief for almost all the Agile practices. We're engaged and we're asking people to engage in belief change, which is probably one of the most painful things you can do as a human being - engage in belief changes. This is literally what we're asking our customers, clients and colleagues to do.
When you say belief, usually that triggers a dotted line to religion or some form of spirituality, but we all have beliefs. For example, we all flew here to Chicago. None of us got on the plane unless we held the belief that the plane would arrive safely in Chicago. That has little to do with religion, yet, it's a belief you must hold to get on the plane. It's the same thing here with Agile adoptions. If we ignore beliefs and values and just focus on the behaviors, we're not going to be effective. So, under the pretense of an Agile game, which we'll call simulation to sanitize the term "game", under a simulation pretense, we as Agile professionals can clean a tremendous amount of information about the person's values and beliefs by watching them behave in an Agile game setting.
What we do with the information is we map the landscape of willingness in the organization. Their level of willingness to adopt Agile, not just Agile behaviors, but Agile beliefs, because, at the end of the day, any lasting change is going to be based on that.
One of the things that's very interesting is that you can take that information and you can map. It's not a political landscape, it's more of a willingness landscape. You can see, for example, where there is going to be resistance and where there might be strong resistance. For example, if a manager has authority in the organization and they are behaving passively during the games, that's a pretty good sign that you've got some resistance there.
If, on the other hand, a manager who has some authority shows up, is initially skeptical, goes from a passive role to an active role, expresses some Aha!s and insights as the games and simulations go on, and then they are kind of jazzed about those insights and they have a shift in their thinking, that's a pretty good sign that you are well on your way with that person. That person can probably help you loosen some of the nuts and bolts that need loosening.
Right. Pay attention to their willingness behaviors, use the game as a pretense for understanding, observing their relative willingness to the behavior in the game and then, from there, you got a real good read on the whole organization or at least the people that you are going to be touching as you are attempting to implement you Agile adoptions.
There are actually hundreds of Agile games all around the web. For example, I met Portia Tung and her colleague Pascal, who have a lot of very interesting games that teach queuing theory, theory of constraints, other principles. The game doesn't actually matter as much as getting all the participants in the room in observing how they interact with each other and the game activity.
25. The Agile community is evolving and what I hear you saying is these are things that are evident in your stage, but these are things that I've read very related things, not necessarily exactly what you've been saying, but Kent Beck has been talking about principles and beliefs and Linda Rising has been talking about bonobos and our emotions and what we're hardwired to do and what we're not hardwired to do. There is a minority, but from my perspective I see the leadership in the Agile community really starting to pay attention to this. You told me earlier that you're seeing the Agile community change and evolve and you're definitely part of that. I also understand you are part of the PMI Agile project. Is that also part of the evolution of Agile?
I think it is. If you look at the PMI, if you look at the world in general and you talk to an IT manager and you ask them "Have you ever heard of Agile?" or "Have you ever heard of Scrum?", usually they might have of one of the two of those, but not know exactly what they mean, but they've heard of them - so, we've penetrated.
26. What is the PMI?
The PMI is a non-profit body, focused on project management. It's a professional association of almost 500,000 members across 72 chapters.
They are probably the largest user group in the world. The PMI runs fantastic meetings, is focused on the PMI Project Management Practices. Right now, Agile is the hottest thing in project management, so it's not like the PMI can any longer ignore Agile and in fact, it has now established the Agile Community Practice as of Agile 2009.
Yes, I am. I'm one of 14 folks who were involved in the mission, which is to bring Agile knowledge and skills to all practitioners world-wide. We are authorized by the PMI to do this and we have launched just this Tuesday, we have a website and a plan for the coming 6 months at least, but the reality is how we organize work, how we do work and what the work actually is, is emerging as we speak.
29. It sounds like an initiative with huge potential - 500,000 PMI members - Agile being very hot. Outside a very hot, many of us actually believe that we are actually very effective. Can you tie this together? I've been listening to many things and I know there is a common thread - cognitive psychology, Agile adoption with Agile games, the PMI really is about Agile adoption for the PMI folks, isn't it?
Imagine a large firm that has say 500,000 members - not employees, but let's call them members -.
I'm not sure about IBM, but say they come to you and they say "We really want to know more about Agility. We really need some guidance and we'd like you to help us. Oh, by the way, each one of the people in our organization influences at least 50 other people in businesses all over the world. Would you be willing to help us with that because I think we need some assistance." That represents a tremendous opportunity to take Agile ideas, concepts and principles to the entire business world and that's got to be about the most exciting Agile project I can imagine.
We have a public wiki, which you can access if you Google "PMI Agile" and you look for Agile-PM.PBWorks.com
We are authorized and sanctioned by the PMI, we are literally a charted community of practice in the PMI and we are eager to enlist the entire Agile community in bringing Agile knowledge and skills to the PMI. With that kind of mandate in charter we are absolutely looking for folks in the Agile community who find this intriguing, who believe that the world is better off with Agility than without and are willing to invest maybe 2 hours a week in doing some small tasks that help advance the work.
We certainly have our opportunity. One of the challenges of our project is that it's a distributed project across every time zone, it's a non-IT project staffed with volunteers with no known end date, fuzzy requirements and ever changing and emerging opportunities to basically complete our mandate to bring knowledge and skills to PMI practitioners. As such, it's a great laboratory for bringing highly adaptive Agile skills to a very complex problem. That, coupled with the monumental potential of the project, is what really gets me going and that's why I'm involved.
There is one thing I'd like to share and that is the Agile conference goes off every year, folks in the community come here and we interact socially and we socialize learning together and we do all this wonderful group thing. This year, the conference has authorized space for 2 new areas under what's called "The manifesting Agility stage" and that's Agile and non-IT domains and cognition and psychology. I'm really eager to see those promulgated into next year's conference.
The non-IT domain is a specially interesting with the dotted lines to the PMI and especially in the light of Alistair Cockburn's keynote about Agile 2.0. The way we are going, we've not just penetrated Agile terminology, but we are starting to move into non-IT domains with Agile principles and concepts. That's an extremely interesting time for us in the community and it means that we need to get really good at socializing Agile concepts and principles across many axes and many different communities and be able to speak the language of these communities in a way that allows them to receive these Agile ideas.
That's an extremely interesting area that I'm eager to see continued. We have authorized space for psychology and cognition and for Agile and non-IT domains. For the very first time, and I'm eager to see the community coalesce around these topics and really develop the work further in the coming years through the conference.
My main recommendation would be to take a look at the PMI Agile projects and take a look at group relations theory in general, Google it, learn about it, attend the conference. Group relations - it's extremely interesting. There is a huge amount of overlap. The conferences are completely experiential, they are very here and now. We conduct retrospectives during the conferences, what just happened and we go on and look at that. One of the things that go on in the conferences is the role of authority in group life is explored in a way that's both meaningful personally and your role in the groups of what you are a member. I would strongly encourage folks to check that out.
36. This group cognition, group relations recommendation that you make, when would it be useful for a team or an organization to actually go in and learn about it? Would it be in the beginning when they are learning? Do they need some experience in Agile to really get a lot out of it? What level of maturity would you recommend they'd be?
I think an Agile professional who's been involved in Agile coaching and Scrum coaching and ScrumMastering for at least a year would get a tremendous amount out of it. ScrumMasters in particular are to be observant and to pay attention to the group and often ScrumMasters speak to the group as a whole. This is exactly what goes on in a group relations conference. When you participate in a group, the consultant speak to the group as a whole, never to an individual.
This has very interesting dotted lines to ScrumMastering. It's very similar to what the ScrumMaster does and I think that those who manage iterations are responsible for being a friend to the team, patrolling the border of the team, managing the team's boundaries and related authority. These are extremely interesting conferences for folks who are drawn to that kind of work.