Bio Rachel Davies is co-author of the first “Agile Coaching” book and works in UK as Agile Coach at Unruly. Internationally recognized and presenting at industry conferences worldwide, Rachel started out working as a software developer and has been an agile practitioner since 2000 applying a range of agile methods including XP, SCRUM, Lean/Kanban, and DSDM. Follow her @rachelcdavies

Sponsored Content

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

Well, I think Kent Beck’s choice of naming the approach extreme programming was one of those things where it grabbed a lot of attention at the time, people thought “oh, wow, I want to be extreme”, and it was a time when snowboarding was becoming popular, that kind of thing. But actually, from an organizational point of view, saying “we want to be extreme” is really hard to get accepted, especially when a lot of the practices were countered to sort of the traditional management thinking; so for example, if you said to a traditional manager we want to have people working in pairs, they would think you will probably get half of the work done if you’re working in a pair; so calling it extreme programming at the same time made it I think perhaps hard for people to introduce it in organizations.

I think so, yes, and then also people started to abbreviate it to XP and XP didn’t necessarily mean much to people, so I think that at least when people talk about scrum there is a feeling that it is about a team and it feels that people have associations that potentially good, they think people playing well together. Whereas extreme programming sounds a bit worrying.

Absolutely. And I think at the time there was a lot of dogma with XP, people were saying, if a team struggled to adopt XP, then people would be saying you are not doing all of the 12 practices, it became quite religious and what happened when the other agile approaches were seen on a more equal footing was that people started to introduce retrospectives, which is quite a crucial thing. So the team that I was working in, they had been working and really trying hard to adopt all of these practices in the book, but they hadn’t had a retrospective until we heard about it at the XP 2001 conference and then we tried it out and it was very cathartic and we adopted retrospectives into our approach from then on.

So that’s one good thing, I think there has been lots more discussion and knowledge shared about how to do agile practices; for example, how to facilitate planning and estimation and standard meetings is now better known, and I think it really is better known through programs like Certified Scrum Master and those kinds of things, I think that has really helped get some of the practices to be done well.

Ben: So in that sense, the intent from the manifesto writers that we are discovering better ways to develop software is actually working out.

I believe so, yes. I am not an anti-agile person, I think bringing the word, people wanted to be agile whereas before that it was lightweight, “do you want to be a lightweight? not necessarily”, “oh, but you don’t want to be a heavyweight, either”. So it was bringing terms and language in that helped people to introduce these ways of working into their organizations.

Yes. For me, I believe, the best and most effective way of being agile is to have a small team of very capable people and have them closely collaborating. When people want to scale agile into an enterprise agile, I actually think it’s something they want, we want good stuff, we want to have it for everybody, but actually if you throw a lot of people who are less skilled at it and introduce a lot of communication overhead, having people in time zones where there is hardly any overlap, having those time zones for cost reasons; I’ve worked somewhere with an investment bank where they had the programmers in London and the testers in Moscow and Canada, and it was really not easy to do work with them because of the time, and even the testers in Moscow didn’t have video cameras or things like that, they didn’t have a phone on their desk, they had to go into a special meeting room if they were just to use a phone. So you can have people trying to scale it up and also trying to cut costs, I don’t think the combination works very well. I believe that if you have a small team of very capable people, they can actually probably do as much as five or six teams, so it’s worth the investment. But it is actually very difficult to hire and that’s one of the things that we find, to hire people who really thrive in that environment it’s tough, so I can understand why people do it.

Ben: So the power is in the team, in the collaboration, that’s what makes things work.

I think so, because what you are trying to do, you want to create collaboration, to do things quickly, you are not working in a phased approach, you actually have continuous activity, you are doing research and design and development and testing, all in parallel, you need those people to be close together so they can talk to each other without having overhead and delays; and so the more distance you introduce between people and the more people you try to involve, the harder that becomes, there is a cost to that, it’s a cost overhead. And I think sometimes that cancels out the benefit and you can see some quite painful installations of agile scaled up, perhaps in an inappropriate situation.

Agile can feel like a burden when there are things like long estimation meetings and estimation meetings of things that people haven’t had the chance to look at particularly, so a typical developer view might be “oh, agile means I have to go in a room and pick numbers out of the air when I really haven’t had a chance to look at the code” and it feels like sort of torture to put people through this. And so I think that one thing that people could look at to avoid some of that extra ceremony is to look at whether they can follow more of a #noestimates approach, which is kind of a popular approach at the moment, the idea that if you understand the amount of work you can roughly do, the number of pieces you normally do and if you can split your stories down really small, then you don’t need to estimate every single one. So I think that may be a sort of glimmer of hope.

For continuous delivery, I think it’s important really to make sure, in the teams that I work in, that there is a collective ownership that is established, so there are not people who have special rights to do things, we don’t have the idea that the team lead must check everything before it goes live, but there is instead a culture of responsibility so that the people who are doing the work know that they must do it well otherwise it will cause problems for everybody else. So it’s more of a social responsibility for their group so if you build a team who feels responsible for each other and together, it encourages this attitude of discipline and producing good results. Even though it sounds like continuous delivery is all about technical practices, I think a lot of it has to do with a firm foundation of strong team work. In terms of technical practices, there is, nowadays anyway, a far better framework for creating automated builds and deployments and also for provisioning cloud services and all of this kind of stuff, so that it’s much easier to create automation that is fast for these things. Many times in the past it would have been home-rolled scripts to move files around that would be error-prone, so it’s nice to have better tools nowadays. When deploying your code is easy, then people are more willing to do it more often.

Well, I think even when XP was really new, there were few things people didn’t do, there were practices like coding standards and coding standard as a written down standard most XP teams don’t do, but there was also the idea of metaphor and choosing a metaphor of a real world system that represented something about how your system worked and it was something that you could use to explain to your customer or to your user “this is how we think about the system”; and I think that with the C3 project they had this idea of parts and bins and there was this metaphor that fitted quite nicely into how they were putting together this pension system, it was a pension payment system or something like that.

Anyway, it’s actually quite hard to find such metaphors and much more people have moved towards using domain-driven design, so people use domain language, and what we are more careful about now is to listen to the language that the users use and to make sure it’s reflected in our system and to detect when different groups of users start talking about different concepts. One of the things we find, and I think it’s probably true of all systems, is that users are very inventive and they come up with new ways to use our tool, we make a platform for them to create advertising campaigns, and they have all sorts of ways to use it that we may not be aware of if we don’t spend some time with them and they have some cunning little work-arounds, if you do this and do this you get this effect, so we need to keep a close eye on what they are doing so that we can actually make it much easier or sometimes users will develop a suspicion, and this is in the advertising industry is funny because they will go “oh, this setting has this effect on my campaign”, but it’s nothing, they were lucky and they saw a pattern and it’s almost a lucky “if I set this setting this will happen” and it’s not actually true and sometimes it helps to educate them and explain no, that thing doesn’t do that at all.

Ben: Speaking a common language between development teams and the users of a system it’s something that really helps.

I think it’s often tempting to go along the way of “the let’s try a little bit of something”, I actually think it helps to do a lot of it, I would actually say ok, let’s try a whole sprint where we pair program on everything and we write test before we write code on everything and we try and deploy daily if we can, but what people often find is that initially it’s quite frustrating because they would find oh, no, our desks are not set up so that we can do pair programming, we are all using different test frameworks, so it will create pain, but actually in the talk of Tim Ottinger and Ruud, they were talking about if you find the pain, you do it more until the pain goes away rather than you avoid the pain, so I think it is painful to move towards using new tools, but actually if you are just going to try them a little bit, then they quickly fall away, so it’s quite important to try them in the extreme way.

Ben: Yes, again it’s the extreme idea to do it a lot because that is the best way to learn it.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.