1. What brings you to Agile 2010 this year?
Actually, several things. So, my work before the conference started with the Agile Alliance Functional Testing Tools workshop. I was facilitating a community of practice retrospective for them. And then, the conference is starting today so I’m looking forward to going to sessions and I always learn loads of new ideas at Agile. I'm author of an Agile Coaching book and I’ll be running some sessions myself later in the week. One of them is a very new session so I haven’t tried it out in its full format before and the other one is more centered around retrospectives. So, I guess that’s a kind of a broad overview.
2. And what is the topic of the new session?
Agile Coaches Dojo, and it’s really looking at creating a format for helping coaches to learn about coaching styles by seeing other people coaching and really it’s inspired by the Coding Dojo, sort of being a very popular format for teams to learn from each other rather than to learn from a teacher. So, the the idea is that everyone can participate and they can get actively involved and can also see, by being observers, different things going on. So, I tried the small version of it at Agile Open Holland but it was a very small group and Agile 2010 is a huge conference. There are often quite large session group sizes, so I have to work at how to scale it, so that’s the challenge really.
3. Is there a difference between a coach and a scrum master?
I would say "I don’t get hung up on role definition so much". I think a scrum master can coach people. I think a coach can take on some of the responsibilities of the scrum master so you could combine them but I see the coach role as having different responsibilities, really. So, when I am coaching teams I’m actually, pretty often, coaching scrum masters and I’m coaching them to coach their teams, but I’m not trying to change their role name. A scrum master’s role, for example, is somebody who has a particular responsibility within the scrum framework to make certain things happen and I would see an Agile coach as having looser set of responsibilities. So, they are not, kind of, prescribed somewhere "These are the things that you should do". I guess at this stage nobody's certifying agile coaches either. So, that’s another difference.
There is a whole field of coaching and coaching certifications outside the field of Agile software development. So, for example, Lyssa Adkins, I know, has done training in coaching as a technique rather than coaching Agile teams and then apply it in the field of Agile coaching, in Agile teams. However, I’ve just remembered that there is a certification for scrum certified coach. But it isn’t something that there’s training for.
So, it’s something where people compile their experience and there are interviews, that kind of stuff. Now, since I wrote the book people have asked me for training courses and I have now been doing coaching skill workshops. They’re not quite the same as training, I would say. Because there’s a large interaction element and there’s some structured parts but there’s also some stuff which is really driven by the attendees.
And they have been, the largest one I did was for sixty people - and it was for a large telecom company that has a coaching network but I’ve also done it for groups of four people and I would say it works much better for very small groups. Where they’re able to build an agenda together of the stuff that they would like to cover and then we work through that. But I think in terms of certifying people’s ability, I don’t know who would be qualified to do that. So, it’s not something I imagine I’m going to get into.
Dave's full question: There have been some under-currents and dissention in the ranks of the Agile community. One of the biggest one is a lot of people feel that it has been taken over by scrum, by management, process management kinds of things so, that’s why the software craftsmanship movement, for instance, left, or, semi-left. They thought the focus has changed the way from things like coaching and sub-organising teams and programming in favor of these other things. Would you share your view, or what are your thoughts?
I think it’s a really complex area because when you have Agile software teams working together you want people with different disciplines to work collaboratively together. Which means that if you isolate them into conferences here’s the development conference, here’s the business conference and here’s the testing conference you’re not promoting an interaction, learning what things are required in each other’s worlds. So, however, there is so much interest in the people side because collaboration is very difficult.
Coding is also very difficult. And it’s hard to mix an in-depth coding sessions with in-depth people skills sessions. They’re really very different kinds of things. And so, I think there’s lots of interest in the people side and it makes it look like the software stuff, the actual "writing the code" part, is being marginalized but I don’t really think it is. One of the things I forgot to mention at the beginning was that I’m involved this year as a co-chair for the Technical Edge stage which is what I would consider it the most hard-core of the development stages at the conference.
We had a really hard time selecting sessions, we are pretty happy with the program and though we are happy with the event that was picked but we actually had out all of the stages, the most submissions for software development. So, there were a lot of rejections we had to send for really good sessions and so, I can see how things like that might cause people to feel that there’s no place for the software development stuff. But actually there’s an equal allocation to each stage and there’s an equal balance between the technical and the business and the leadership and collaboration area. So, I think, it’s fairly divided up, but people still feel that the conference is about other things than coding.
I don’t know if that gets anywhere near to answering the question. But I think it’s great that there are now more coach retreats and software craftsmanship conferences happening. Last year there was a software craftsmanship conference coinciding with the Agile 2009 conference. They leveraged off the fact that there was going to be a lot of people at Agile 2009 and then have a side-effect, creating a fringe around a large conference is quite an interesting idea.
I don’t know. And one of the difficulties for me in answering that question is that I haven’t been in-depth learning about coaching on its own. That’s not my area of expertise. I have learnt to coach software development teams through working as a software developer and working through those roles and seeing the kinds of things that people get stuck with. Like spending a lot of time learning about how to influence and affect people and how to help people open their mind up to different ways to doing things.
There probably are business opportunities to coach businesses and there’s a whole discipline, I think, of business coaching already outside the Agile arena. But, it’s not something I’m desperately attracted to. I like to stay close to the people who are in the team, trying to create software. And I don’t mean just developers, I mean programmers, testers, BAs; user experience people. It takes the whole combination to create software and what I would be really pleased to see, not only about the software craftsmanship stuff, but there’s also now a new dev-ops kind of movement.
These are people, I’ve started to realize, have been left out of the picture; they are looking to be involved; how can we assist development who is getting more involved in the Agile teams creating the software so there is starting to be user groups at where there was a conference dedicated purely to that topic, earlier this year.
I would, first of all, perhaps pick an argument with you about whether scrum masters are in a role where they’re kind of managing a team. I think if you read the scrum books, scrum masters have a very facilitative role and are very often played by people who are not managers. However, it seems to become the role that Agile project managers seem to want to do. I think there are now a lot of people who have traditional management skills and responsibilities and then they are trying to add this additional scrum master role. Now, getting back to your question, "Are people drawn to Agile coaching?" because it doesn’t seem to have the same power. Is that what you are saying?
Yes, ok. I think people I see, having written a book in the Agile coaching space, I’m kind of following that, if I look on Twitter I have always a little stream of anything that has a tweet with Agile and coaching in it. There’s a lot of interest in the role and I see also a lot of interest because I’m running classes. I see people wanting to do this and they’re not coming to it fresh, that’s what surprised me is that the people who come to the classes are not asking "What is Agile coaching?" they are like "We are already Agile coaches and we want to learn how to do it better".
So, I think there are people who would see themselves more as "We help teams do a transition" and I think the big difference with coaching is that it's a transitionary role whereas the scrum master’s role is you stay with the team and the team always has a scrum master. It doesn’t go away. Whereas coaching, you’re there helping the team improve, and get better although there’s always room to improve and get better forever. The idea is that the team absorbs that coaching capability, that they become more self-coaching and that’s where I would see teams really absorbing and owning their retrospectives and using them to improve things.
Yes. That’s one of the, I guess, one of the sad things about being an Agile coach is that just when the team becomes a pleasure to work with, then that’s when you have to leave because they don’t really need an external coach anymore. And, I have to say that when I’m working, I play the role of an external person coming in and there are also people who are Agile coaches who often call themselves internal Agile coaches and they work with the different teams within their organization, large organizations. So, I said I did this workshop with a large Telecom company.
They have a big coaches network and they have sixty people who are all playing coaching roles and some of those people are the old process improvement people and others are people who’ve worked in Agile teams and enjoyed it and they’ve just taken on this interest to spread these ideas to other teams and to improve the skill levels of the other teams as well.
Dave's full question:Dick Thomas mentions Agile has reached its ten-year half-life and this comes from a lot of different things, you know, objects, patterns, etc. They seem to have this roughly ten-year growth spur which is all upwards and then they go to a ten-year decline. Has Agile really reached its peak or what do you think?
Maybe it’s already peaked. I don’t know. Again I would debate with a number of the things you call out in the question. So, like, for example, the Agile approaches what we call Agile, starting with the Agile manifesto. Lots of those practices were around for the previous ten years, that’s nothing new. I mean, they’ve just re-badge it and said "Let’s play nicely together" when we established the Agile manifesto. Everyone wants to be Agile because it’s a nice descriptive word, but that, I think, creates a lot confusion if they want to be Agile.
We want call things in our existing process Agile, we want new Agile document templates and things like that and that’s pseudo Agile. And I would say pseudo Agile is kind of going on nicely. I wouldn’t say that always translates to people really getting what people mean when they put the Agile manifesto together. Like, you look at whether teams are actually applying those principles behind the Agile manifesto. A lot of the time they haven’t quite got that far. And so there are probably a lot of organizations which will dip into the new trend and re-badge stuff about how they do things, but they don’t fundamentally change.
And there is a smaller set of organizations that fundamentally make a shift, move much more to collaborative ways of working, collaborating with the business and it’s really hard to get a sense of what the trend is around the industry. Because you can hear lots of things at conferences like these, but there’s a certain amount of marketing hype because there are vendors. There are sponsor booths and so it’s hard to get to the underlying story about what’s really going on.
Dave's full question: The Agile manifesto is clearly about principles, some values are kind of creep in between the lines, and they were there. There were no practices in the manifesto. But everything that you see around you today seems to be pretty practice-focused. What would you recommend for a coach: should they become a master of the practice or should they become a master of the values and the principles and the philosophy?
I don’t think that’s an exclusive "or". So first of all, I believe that if you are going to coach people you need to know how to do the things that they are doing. It helps if you have been a practitioner. I think it’s very, very hard to coach people who are doing the job that you don’t understand. I find it a lot easier to coach software developers, for example, than I find it to coach user experience designers because I haven’t really been a user experience designer myself. But I think that if I was serious about really wanting to specialize and work with user experience designers I’d have to go and be in a project and try to do some hands on work, to learn more about how they function.
What are the things that are important to them and I recognize through working with two users experience designers, for example, that there are different things about their job and that they very much see Agile as being something that’s come from programmers. And is about them and about what they do. And me having a development background, it is very hard for me to persuade them that’s not it. Coming back to your manifesto thing and why are the practices missing, the Agile manifesto is clearly, in part, a political agreement, that is about as much agreement they could get in a two-day workshop given people had years invested in writing about Scrum, XP, that they didn’t want to abandon have the unified agile method.
So, I think that’s why the practices are missing. And I think why people at this conference are focused on the practices is because when you go to your organization, you’re very often faced with a very messy problem to tackle and people want practices as tools that they can try in order to crack open those problems. I think that’s why people are hungry for practices. But I think that for a coach you have to have a strong set of core values and principles, as well as practice. Now, I was at the session early this morning where Linda Rising was talking about patterns for customer collaboration. And one of the interesting things about it is that in order to work with a customer relationship you have to go along with those, you have to mirror the kinds of things they see as important.
The kinds of interaction they see as important. And it’s very hard to do that if they are not in alignment with your own personal values. So, something that I find is that when I’m working with clients and try to work out "Can I help you?" I very much try to work out "Can I, as a coach, function in this environment". There are some environments that I find pretty toxic and I find that I can’t work there. So, I actually try to find an early sense of, "Is this an environment where I can actually add value, can I function?" and this feels like it is, in some sense, an Agile organization. And that’s led me actually to work with the people who are moving from Chaos to Agile than the people who’re working from Waterfall to Agile.
So, I prefer to work with those web media projects which are open to change and they are trying to find ways to cope with change rather than the organizations that are really kind of locked into a very difficult system to change. And it is possible to move from very heavyweight Waterfall to Agile, but it takes a really long time and a lot of energy. You have to really be sure that there is the appetite for doing that.
Dave's full question: So, you’ve mentioned working with user experienced designers had been difficult because you didn’t have that background yourself. There has been a lot of interest in the last five years, at least last five years on the business side of the house about bringing in design thinking. And you look at what they mean by design thinking and it’s very close parallel if not the same thing as the Agile. A designer starts with the brief, we start with the user story, that’s communication with the customer, and the whole team. Is it time for the Agile community to bring in Jim Kelley? Is it time to bring a Jim Kelly in here as a keynote speaker for the Agile Conference?
Well, I think, that there was an attempt to do that by bringing Alan Cooper in, a couple of years ago at Agile 2008? But, yes, I think we need to be open to bringing in another discipline, and being inspired by those disciplines to think about how we could do things differently. And I think a fundamental thing about Agile is that you are open to improving things. Now if you lock down a method and you say "There are these meetings, this is how long they take, this the format for them" and "These roles and that’s it!" and then we just repeat them everywhere that would be frustrating. And, so, you wouldn’t fundamentally be learning and thinking "How could we do this better?".
So, I think that if we can learn things from how other disciplines do things I think that would be great. And I think somebody who’s working in this area is Jeff Patton. This is one of the reasons he got awarded the Gordon Pask award because he is trying to create a bridge between those user experience community and the software development community, trying to, on both sides, invite people to be a bit more open-minded about how they do things. And I think that’s about that. It’s hard to move people to another direction because people get very entrenched in the things that they feel they are already good at. You know, when we feel "We master this, we are really working it", then it’s hard to kind of go back to being a beginner and learn something that isn’t the thing that you are already good at. And I think we’re always battling that about.
13. Do you have a new book in progress?
I don’t, although I am thinking about writing something that is a bit of a deeper dive into Agile coaching. You would think, you write the book, done, the book-checked, you know, move on but the thing is I’m still really fascinated about how to coach teams in better ways. What are the changes that as an Agile coach you face, and how to help coaches work through those challenges. And I think this is an inner game with Agile coach thinking, about how they go into situations and don’t become demotivated when they’re in these environments. Which can, on the surface, appear very non-Agile. And that’s why people want to do a transition because they realize that by working at the same time, it’s really hard to stop doing what you’re doing and do something else.
Dave's full question: So, the Agile Alliance is promoting this diversity in Agile and at this conference, they’re focusing on women in Agile and I’m not asking you this because you are a woman but is the Agile movement more appealing across gender lines more than traditional software development or do we still see pretty much the same 80-20 split?
Again, it’s really hard to make assessments across the industry. I know that when I started out in software development in the late 1980’s, most of the time I was the only woman on teams and I’ve just got used to that fact and, in fact, I don’t really see people’s gender at all, I don’t think of it like that’s a man person, that’s a woman person and then I interact with them differently. That’s not something I think about. I do find that in an Agile environment, you are more likely to have a better mix but I don’t think it’s necessarily because there are more female programmers, I think it’s to do with disciplines like testing, and disciplines like business analysis have higher quantities of women in them and I think that when you create these cross-functional teams, that ups the male-female mix on the teams.
I think sadly that there are fewer women going into programming, and at least this may be more of a western culture thing because, I think, if you go to countries like India there are actually a much better balance of male-female people in software development so I think it may be purely that the way that people promote the image of software developers alike, programmers alike, like the typical characters you see in the movies as favorite software developers doesn’t attract women into the software development profession which I think is sad because I think it’s a very creative and interesting practice or discipline.
And I really do think that women have a lot to bring but I think there’re so many different other aspects of diversity that are just focusing in on the male-female thing. It’s an interesting starting point for the program but I hope that diversity in Agile programs goes on beyond that and doesn’t just stick with us, we should have more women programmers.
Well, I think the core skills that you need for coaching on top of having some competence in the practices of the people you’re employing. I think the core skills are really those human interaction skills, so listening, and how to express yourself, and what kinds of questions to ask, and things like negotiation skills, and, how to deal with conflict. Those are very useful life skills in general. Now, again, I can’t make broad generalizations. I’m sure there are schools where those things are really part of the study of several different subjects but I don’t know whether they are officially part of the syllabus. I don’t know if in the US you have a core curriculum, I just don’t know about education in that way.
Yes. And it’s just so ironic that people take one route into the profession. Which is to take computer science and computer science has tended to focus on algorithms and structure of programming languages and different styles of programming but you can’t actually employ their skills in isolation. You know, I think that people come into the industry expecting to be able to work away on a project on their own and, in fact, the way software is, we have huge systems that are already there with many different people working on them and the core skill for software developers is how do we figure out what things actually do, and who do we need to talk to and, how can I get the guy over there, to stop doing that to this piece of the code base.
That kind of thing is quite important but it has nothing to do with the kinds of things you might learn in computer science. I think it would be interesting and I’m actually on a panel later this afternoon which is looking at the result, the role of the research and whether people can draw, practitioners can draw things from the academic research that is done and I’m on the skeptic side at the moment. I like the people in research but I don’t find it that useful, not much of it.
I think that culture is so interesting because there might clash of cultures everywhere you go, although we might think there’s a national culture within our national culture; there are also those little pockets different organizations have, really interesting cultural environments so I think that as a coach you have to be pretty adaptive to that. In terms of thinking about that across national boundaries there are definitely cultures or countries that are more Agile-friendly if you see what I mean, that their collaboration is a core part of the way that people of that country like to do things.
And for example Scandinavia or Norway, Finland, Sweden, it’s hot there for Agile, stuff going on and it’s because it’s a really good fit to their culture, but whether that means that you would have only coaches from that culture coaching people I don’t think I can make that extrapolation. However, I think for you to coach effectively you have to be a master of the language and I think that might be a barrier for coaches because if you need deeply listen to somebody and you try to listen to them in a second language, that might be difficult, so, I wouldn’t say it’s a cultural thing I would actually say that it would help to have somebody who’s really fluent in your language.
18. Any burning issues that you want to bring out apart from my questions?
I don’t know. I haven’t got any on the top of my mind. I mean there are always topics that I could bang on about, like retrospective is one of my, I guess, hot burning issues, that I’m so frustrated sometimes to see the travesty that is carried out in the name of retrospectives. And that’s one of the reasons why I’m running a session around refactoring retrospectives in this conference but I don’t really want to talk about it in depth now.
I can give you the kind of micro overview of it. And that’s basically that I see a retrospective as being a game of two halves; it’s like a bridge between one cycle and the next. And teams are far too much focused on looking back than looking forward so, I would just urge teams to spend half the time of the retrospective working out how to make changes to the next cycle. And this is the struggle that people do, they spend, you know, 90% of the time saying "Wouldn’t it be nice if we didn’t do this?" but then in the last ten minutes "I suppose we should have some actions!", quickly writing up some vague actions that they then don’t remember to bring in to the next planning session and they don’t remember to do.
I tweeted last week about being in a retrospective where somebody said "Let’s have a retrospective action to write down the retrospective actions" and it was just one of those comedy moments and because they were having a retrospective and they couldn’t remember what they talked about in the previous one or whether they done those things or not. And that’s kind like step one would be: pick something to do and do it. If you’re not actually making any changes as a result of retrospectives then they’re not effective. So, retrospectives are about creating change and need to connect with how you do the rest of your work.
So, it’s kind of a big area that most teams could improve. And part of the reason that I’m interested in coaching teams and coaching individual coaches is to help them improve in that area particularly because I can see that it has a big difference to the teams.