We are here at Agile 2008, with Keith Braithwaite. Good afternoon, Keith. Before we start, tell us a little bit about yourself and your background, please.
Good afternoon. I work in London for a Swiss engineering company and I lead a team of consultants that are focusing on Agile services, consulting and development. Prior to that I was working for a company called WDS Global in Singapore as part of a distributed Agile team - Singapore, UK, US. Before that I was working in an Anglo-Indian company in the UK doing mobile phone software. It gets less interesting before that.
You are a nuts and bolts developer, project leader?
Yes, all those things, consultant, trainer, you name it.
What would you like to talk to us about, today?
I was struck by one of the give-aways in the conference pack - they are these little stickers for you to flare. The one that I chose is one that says "Agile Skeptic" and there is a little prohibition symbol on that. It struck me that everybody here should be skeptical in the strictest sense of the word, about what we are doing. Everybody should approach this in a spirit of inquiry and critique and criticism and to take a measured, careful view of what we are doing and as well as being enthusiastic about the things that we all love to do, which is the reason why we are here in the first place, but with a little bit of ironic distance.
You are basically saying we should be skeptical of Agile?
Absolutely, yes. We should think about what we do, think about its implications, be aware of the responses that the people are having, so the things that we do are not always entirely glowing. I just think a little bit about what we are up to.
You said that we should think about what we do and how people practice it and that not all those who are on the road to Agile actually succeed or get the benefits promised. Is that so?
Yes. I mean we've been going on this long enough now, that the stories are starting to come in about the cases where, with the best … in the world, people have done what it is said to do in the book, whichever book was their reading and the outcome has been a little bit disappointing for them - the promised benefits have not been realized. It hasn't been disastrous necessarily, but it hasn't hit that high point of happiness and contentment that they've been aiming for.
Dwelling a little deeper, what do you think is behind these failures, not successes?
A little bit comes down to misapplication of a body of ideas that are reported in literature because they have been successful in one setting or another and some people are taking it slightly naive that, if you drop it into another context, then it works just as well. There is now an idea floating around that there is a set of Agile Best Practices that you can take off the shelf and, because they are the Best Practices, then you clearly expect the best things to happen - actually not, because they do need tailoring for particular circumstances. There is increasingly these suites of tools that will assist you in doing this. Again, maybe they will, maybe they won't because they work for somebody else there is no guarantee they are going to work for you. Particularly, each of them has a model built in that it supports for how you run your projects, how you plan things, how you estimate, how you track, etc. and if that turns out not to be in a specially good fit for your organization, you are going to struggle. But, you bought the product, you got the books, you should feel as if it's going to do good things for you. People are now slightly surprised when it turns out that they don't just seamlessly fit in the organization and start to make good things happen.
You were saying that there are these Agile Best Practices which are supposed to be the best of the best because Agile is the best. What's behind that?
I think it utterly comes down to a failure to achieve. We can take an example of working in iterations - that's a good thing, we know it's a good thing, it's well established industry practice from way back. If you are going to start doing iterations or whatever you want to call them, you then have to make a decision about how long they are going to be. Depending on which Best Practice you choose, you get a different answer about how long that should be. One set of Best Practice will tell you it should be 30 days, no question about it, there is no debate to be had, this is the right answer, it's going to be 30 days, a little bit of hovering if it's 30 working days or 30 calendar days - nobody seems to be quite sure about that-, but definitely it is going to be 30 days. Other people will say it's got to be 2 weeks.
Other people will say it's got to be 1 week. Other people will say it doesn't really matter as long as it's the same every time. It brings this situation where - as with standards, with the Best Practices, there are so many things to choose from - if you choose the wrong one for the kind of scale that your organization works at, either too long or too short, you will come a cropper. I have seen cases where somebody has come up with the idea that it should be a week and what happens sometimes in those cases is that the team feels that it can't get enough done in a week. They spend Monday morning planning, they spend Friday afternoon doing their show-and-tell and in the middle it feels as if they didn't get anything done.
That's a bad fit for that team. There should be a longer period so that they can get some momentum going so that it feels that at the end of the week they have actually done something and feel very good about it. That's going to rob them of their ability to do a good work. The other extreme can happen as well, where you might say "We are going to go within 30 days, whatever that means", but generally enough, in that 30 days period the team gets lost. They don't have appointed time coming up in the next few days, when they are going to have a chance to celebrate adding value of some sort. They are just keep on dragging on for the month until they get to the big party at the end and it's too long and they lose their way and they don't feel very satisfied. That's going to vary from organization to organization - it's very difficult to predict.
Whoever is in charge of helping that organization adopt Agile or whatever it happens to be, needs to be sensitive to that and make a choice to begin with and they need to be smart enough to assess and let it vary and change every time. If they don't do those things, then they are going to misact on some of that benefit. That kind of thing applies pretty much to all principles and practices and techniques and that bag of tools that we have. It's a matter of making a smart choice to begin with for that organization, but even more importantly, changing it as you go along. Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want some Monkey Bag with our set of Best Practices, that's an indication that there is something wrong you." More specifically, if you want to change them, then you've made a mistake, which I think is quite a dangerous principle to have floating over your head.
Basically, you are saying that there is something in the Agile field with these Best Practices and if you don't follow this particular set of Best Practices, the author of these sometimes informs you that there is probably something wrong with you if you need to change them. You are not doing it correctly?
Yes, absolutely. There is a very strong thread of that through some subsets of the community. There is an answer and your desire to do things differently from that is an indication that either you haven't understood, or you've not appreciated something else and your organization is broken and that makes you want to do things differently, or something of that nature. There is a kind of excessive strength or force in the way these things are performed. You can almost understand why an author would do that.
10 years ago, some of these ideas were new and challenging to a lot of people and there is the idea of the overtone window and you make your statement a little bit stronger than you really want to, you've got space to come back to the thing you really want, and so on. Maybe they were doing that before being generous, on the other hand, perhaps not and in any case, when you read the page, you can't really pick up what they intended, what was that subtlety that they had in mind about the rhetoric. What they say is "Do these things and it will work! If you don't it will fail and if feel like you wanted to do something slightly different, then that's failure all by itself." I don't think that's a very healthy or productive way to proceed.
That's not very Agile, is it?
It's not very Agile. It's not remotely Agile - it's almost the opposite of Agile. Are we going to follow a plan or are we going to respond to change? Do we value individuals and interactions or do we value tools and processes?
Agile being the process, these Best Practices being the process?
Absolutely - whether you call it Agile or you call it anything else if you like, the label is not such a critical thing. The people who were standing around that overhead projector in the fuzzy picture on the website will happily admit that it's a vacuous mocked-in term - fine, but it's useful to have mocked-in terms, you can label a bunch of stuff. Inherent in all the ideas that came together, it seems that you are going to respond to stuff going on and do things differently and adapt and so on. The idea that there is a fixed set of Best Practices that you must follow that it's not going to change seems pretty antithetical toward.
I think what you just told us would bring through with many in the Agile community. At the same time, what I hear you saying is the danger is to those people who are possibly new, and coming in and reading these from what they believe are trusted sources.
Yes, there is an aspect even of these confesses that I find slightly unsettled. I think with the changes to the way the program has been done this year is maybe not going to be quite such a worry for me, but in the past years I've seen gangs of what I think of as "locals" - anybody who was flying less than 3 hours to get here - arriving almost as if they were going on a training course. They arrive all together - they are on a team from the same company. They are going to come here for a week, they are going to sit at the feet of the masters, they are going to learn how it's done and then they are going to go home, back to their jobs and they are going to make it happen, they are going to be Agile because now they've seen how you are supposed to do it.
There used to be a lot of sessions in the program that were around basically education - you don't need to know anything about Agile, come to the session and we'll tell you how to do it. It's not so much that anything that they were taught would have been wrong exactly, it's just that in a pedagogical setting like that, if you are basically delivering a lecture, then you can't be nuanced, you can't say "Here are things you might try, and here is what might happen", "Expect this, but watch out for that" and so on. You've got 2 ½ hours to inculcate some techniques, so you are just going to bash through them. The whole experience processing there is very dangerous because what happens is that these people who are relatively inexperienced in Agile will go "OK - that's how it's done, I get it now".
They'll go back to their day job and are going to say "Well, last week I was at the conference and I sat at the feet of the master and he said 'do this, do that, etc', so that's what we are going to do." Maybe that's OK to get them going in the first week - or iteration zero, or whatever you want to call it -, but if nobody told them - and I'm not entirely clear this happened - "By the way, if you are doing it the same 6 weeks, 6 months from now, you haven't got it" then there is real danger that get stuck in an alleged set of Best Practices that are actually not very good fit for their organization. Everybody is going to get disappointed and that's where all these blow post-things about the horror of meaningless stand-up meetings and so on come from. That ultimately does this all fair amount of damage, I think.
There is a danger to those adopting Agile from taking a set of rules that, as you put it, if you are practicing these same things in 6 months, then you didn't get it. You also mentioned earlier that the people helping them - we name them coaches, we can name them whatever we want to call them - have to be aware of that. It sounded like not every coach is well equipped enough to play that role.
I think there is a lot of trick in that. I remember, in fact, the first job that I had where I was handed the title of coach - "You are going to be the coach for this team". At the time I also went "OK" and I carried on, but we were smart enough to have another more experienced practician to come in to help us with a week long retrospective session that we did after our first year of this stuff. He challenged that, actually - he said "Well, I used to work with Kent Beck and when I think of an Agile coach, that's what I think of. No offense guys but you haven't got it", which at the time was true.
I think there are a lot of people around who are not Kent Beck, but nonetheless, ending up in roles where they are being asked to do Beck-like activities. Perhaps they are not helping as much as they might because what are you going to do in that circumstance? You are going to do the best you can, you are going to fall back on the resources you've got, but it's an incredibly tough and difficult and challenging and quite dangerous role. If you are raw to the experience when you are going into that role, there is a good chance somebody is going to go terribly wrong and you may not notice until it's too late and then who knows what's going to happen - all sorts of bad things and falling back on the books is not going to help you at that point.
It sounds like you need a lot of experience because every context is different and if you've only had one context under your belt - which perhaps some of us do - then you won't be able to respond to that organization's, that team's set of problems.
Yes. The skill of an expert is to choose between the many circumstances that they've seen before that are like the ones that are now and get a handle on what to do next, and what goes the failure mode for that is that they keep recycling the same small repertory of ideas again and again. That is one of the benefits of conferences like this one where people can come and exchange stories about what they did and what happened and then you can build up a larger stock of this experience without having to do it yourself. Basically it takes a long time and a lot of varied experience to get to be competent at anything. It takes about 10 years to get to be competent at pretty much anything. We are fooling ourselves in this community if we think we can do it by reading a book and taking a 2 day training course and then launch your offer to the world - not to prejudice anybody against any particular 2 day training course they might think of going to do.
What we hear is everybody should be an Agile skeptic, not because the original Agile - the fuzzy people in the picture - is bad, but it is morphing and it's taken out of context.
It is morphing, it's taken out of context and it's becoming a commodity - this idea that you can go and buy you some Agile. Unfortunately it's not really a commodity because it has to do with people and their behavior and changing that in complex complicated confusing context that are changing themselves and on and on it goes. There isn't really a way of dealing with that as a commodity. Practitioners are not fungible, you can't merrily swap one with another when one expects seamlessly transitions - everything is the way it was before.
There is a strong desire for that on both sides. Managers in organizations that have IT activities going on desperately want a commodity that they can buy that will make their lives slightly less painful in the realm of getting software done. Truth be told, there are people that would be more than happy to sell that to them if they can figure out how to do it. Maybe we figured out a way to make it look as if we had a way of doing that, that actually has opened the door to some pretty bad failures. Absolutely, the fuzzy guys in the picture, all that stuff is great - it really does work, but at the same time, the onion layers around that eventually end up in a place that's perhaps not as universally valuable as it's marketed to be. We need to have a degree of critical thought about that and be slightly more subtle and slightly more intelligent about how we apply those things.
It sounds like you are telling us there is no really easy road to be Agile in the effective Agile that gives the results that we read about in the articles in the papers.
It's a very difficult thing. It's difficult because it has to do with individuals and their interactions, which is tough - it's a hard thing to deal with. It's relatively easy to get that initial uplift in performance when you first start and get to the point where you can't build and develop software at all, which a lot of organizations can't do. Once you've reached that point of basic competence, to then move on to the really interesting place where you can do well enough on this efficient good control that you can start to have intelligent adult conversations with your business about a little bit of give and take, and so on and so forth. That's hard and takes a long time.
Earlier you said there were 2 things that should make us a skeptic. One was "Here is a set of Best Practices", the other one was "There are these tools" and these tools might not necessarily fit your particular context and that's not a good thing.
Part of the attempt to commoditize Agile, there is this idea that you can buy a tool - there is a bunch of them that you can choose between - and it's going to make everything work, somehow. There is nothing wrong with that if they are the right fit for your circumstance, which they may not be. If they are not, you are in trouble because you know about software that, if it's not doing exactly what it was built to do, you are going to be in a lot of trouble. Each of these tools has an implicit set of practices encoded in it, that's what it facilitates you doing - those are its affordances, they help you do those things not very much anything else.
As with your choice of Best Practices, your choice of tool, if it's inappropriate and you can't change it very easily, it can be extremely damaging. Down to the level of what you call things. Some of the tools have a sort of skinning on them so that you can change the vocabulary slightly, some of them don't, but in any case, the model that's underneath there generally won't change. There will be some concept of what things are called, how they are organized, how they are arranged, which is growing out of some set of practice - I mean they don't make this stuff up, it's based on their experiences. They've got a really strongly set, collection, of practices, the tool won't basically let you do anything else, or only with extreme difficulty.
You paid money for it, generally speaking, so it's going to hard to not use it the way it was meant to be used, if you are going to use it at all. Then, there are 3 possible items: one is you write off the cost and it becomes shelfware and you go on to the next thing - that's not really success. If you are lucky enough that what it does is what you need, then you are fine. The worst case is that you struggle and in that arena there is a great deal of skepticism that needs to be pointed, in the positive sense of careful scrutiny and assessment and thought and awareness about what these things mean and how you are going to use them.
How would one go about doing that if they are new to Agile?
I don't know.
Now we have the tools that either you write off, you get lucky and they match or they hinder you for the rest of your development days.
Yes, pretty much. One out of 3 isn't bad, right? It would be nice to think we are all in number 2, but I have my doubts.
What would you advise us to do when it comes to tools?
You can get a long way with Excel. There is a little voice on the shoulder that comes along and says "Somebody has done this before". People are very reluctant - Surely I could go and get a pre-cooked thing from somewhere and you can, but if you spend half of an hour batching the spreadsheet together for your project, for your team, that will get you going. Once you've found out what you need in your context, then you can go looking for a tool. Maybe this is the answer for the question you asked me before. Generally, I stop at the spreadsheet - task estimates, done-not, you can get a graph out of that, you can stick it on the wall. I mean, really, what do you need? You need to know what there is to be done, how much of whatever is you think is going to take to do those things, how many of them have been done - pretty simple.
The people will argue that what if I have a distributed team? What if I have things in my context where I think an Excel spreadsheet might not cut it or cut it in pasting back and forth? Your advice is to start simple, get your experience and know your context to know what you need and, at that point, you'll be able to do the evaluations.
Yes, to make a choice. If there is one thing that a developer is really good at, is thinking at reasons why something won't work, and it's true. If you are in a distributed team, it's actually less easy than it might be otherwise to email spreadsheets around, but these days we have Google Docs. I've managed projects that way - here is Google Docs spreadsheet, you can see who is editing it, because it's visible everywhere - I think they are versioned, near enough anyway. You can have your RSS feed, it tells you when they've been changed - the job is a good one!
You are definitely on the lighter side?
Very much so. Tools are great, I very much like tools that take away the load of doing repetitive calculations or anything of that nature, but a tool is only a tool, is a means to an end and the best tools are the simplest tools. That's not just true about Agile project management or whatever you want - universally, the best tools are the simplest tools, when they are best fit for what you want to do. We are lucky in software that we have these very malleable tools that we can turn into the thing we want. Spreadsheets are much more like that than any particular product you might want to buy that's focused on the stuff that you want to do. The offshore stuff lures you down a particular route that ends with incomprehensible charting on fantastically complicated project dashboards that look as if they're tell you about the state of the world, but what you really want to know is what is there, how much of whatever it is you think it is it's going to take to do and is it moving in the right direction? It's very easy to get that information, it's very easy to share it right, so do that first and then figure out the other stuff later.
That definitely is in the spirit of the original Agile.
The best piece of tools for this purpose I've ever seen was a case where there was a story board in the place where the developers were, with cards pinned on it. There was a little bit of reorganization of the building, the business sponsors moved a couple of rooms down - they had been next door to the developers, which was great, but then they moved couple of doors down. The funny thing is that a couple of doors down is almost as bad as the other side of the country - strange, but true. The team leader who was a big Scotsman, walked to the story board, got a hold of it, pulled it off the wall, tucked it under his arms and went down to see them and said "Here it is!". Then they had the conversation and he brought it back and propped it against the wall again and that's how it went.
Given this is not a very happy picture, what would be your recommendation? How would you like to see things move forward?
Writing a tool on that. On the one hand, I can imagine something like the craft guilds in Germany where there is a substantial barrier to entry and there is a lengthy and rigorously scrutinized period of professional experience and training and learning that has to go on before you'd be recognized as somebody who is actually competent to do a job. I'm not frightened of a barrier, which I could not pass through. In some sense, I'd be hypocrite if I said otherwise. It could well be that the correct barrier to entry to this business is one that would mean that I can't do this - fine, I'm going to do something else. At the moment, I think it's far too easy.
Another part of me wants to say, actually even the structures that we have now, the Agile Alliance stuff, maybe that's the wrong direction. Maybe even that creative control is not right, that should fade away and we can almost imagine a world of traveling Buddhas wondering around the place and where they go things get a little bit better and that's a good thing. And then they go some place else and things get a little bit better. Perhaps most importantly, if you are not moving, if you really in an organization and Buddhas are coming to you, you get 2 or 3 of them, and they teach you different things and each one of them makes things a little bit better. That just goes on and on and things get a little better every time. Which of those 2 options would actually have the happy side come, I don't know, but I think the sort of middle ground that we have now isn't going to do it. We have made a bit of wrong turn there. Maybe we need to backtrack and try something else.
10 comments
Watch Thread Reply