00:32:15 video length
Bio Keith Braithwaite is a Principal Consultant with Zuhlke Engineering, and leads their Center for Agile Practice in London. He provides Agile training, consultancy and mentoring to development teams in the wholesale finance and mobile telecoms industries.
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.
Yes, all those things, consultant, trainer, you name it.
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.
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.
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.
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.
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.
8. 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.
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?
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.
11. 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.
12. 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.
13. 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.
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'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.
16. 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.
I don't know.
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.
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.
20. 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!
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.
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.
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.
Selling Agile is a Smell?
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.I'm wondering why Keith alludes to but doesn't name the primary culprits he is talking about when he is making claims:
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.Some? How many are there? Which are the worst offenders? While Keith does a good job giving you some specific examples of when extra skepticism can save time and money, perhaps people should be skeptical of boxed agile best practices that carry price tags in general? I wonder if money is the motivation that causes people to be more defensive of the agile boxes they create?
Re: Selling Agile is a Smell?
By the way, your transcript isn't quite right (the fault of my accent, I'm sure) What I said was:
Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want to monkey about with our set of Best Practices, that's an indication that there is something wrong with 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 around in your head.
Price tags aren't bad in themselves. I sell services aimed at improving the ability of an organisation to add value through building information systems. The Agile toolkit has a lot of great ideas to offer there and I use a lot of those ideas. And a lot of great ideas from elsewhere.
I think that it's the box that causes the problem. I've gigs where a client has previously had one or another vendor of a particular, specific Agile solution come in and do their thing. The end result has been a diminution of the client's ability, which I (or someone else) then has to fix. That's bad.
Re: Selling Agile is a Smell?
As you point out it is very ironic when any agile approach has rigidity that does not allow you to refactor the approach itself. All agile brands have rigidity: there is a point at which, having altered or abandoned enough of its components, where XP is no longer XP. Hence if someone says: we are going to do XP, there is a tendency to limit the degree to which you adapt XP to fit your needs.
However, when you overlay a strong marketing and commercial structure on top of an agile methodology you increase the inherent rigidity of an agile brand still further, thus increasing the pressure to confine your approach to those practices directly promoted by the brand you are purchasing. For example, if as a CIO I pay money to have someone become Scrum certified I'm going to expect them to implement Scrum, and not something that doesn't resemble Scrum as it was sold to me.
For this reason maybe agile best practices should not be defined (packaged, cataloged) to the degree that they can be sold. You are right, the box is the problem, however, perhaps selling and marketing the box magnifies the problem to unacceptable levels?
With regard to specificity: I can understand your hesitance to name names, and this isn't the first time I've seen this issue mentioned (agilethinking.net).
Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose.I think there is a way to talk about this with greater specificity that goes beyond name calling, and works to guide people when adopting agile. For example, the quote above names the methodology and puts the criticism in the context of what the methodology does well.
seems to me more of a criticism of "BEST PRACTICES"
uncritically applying behavior from one context to another is not good. adopting a permanent, certified "Context-driven" stance is also not good.
Here, a message from Library Science:
There is no single set of preferred or "best" practices that one should follow in collecting free Web resources. What succeeds in one context might prove fruitless in another. The practices recommended in this report have proved effective in a specific project or show promise for broad applicability, regardless of the fiscal, technical, or human resource parameters in any specific institutional setting. Ultimately, it is not the practice per se, but rather how well that practice lends itself to a particular set of goals, workflows, and staffing preferences, that determines its effectiveness and value in any given setting.
Shouldn't we in software development know this already?
the video appears to be clipped around 9minutes
Re: the video appears to be clipped around 9minutes
I'd like to see the rest, 9minutes is not enough :)
Hi Niall, have you tried clicking some of the questions in the transcript? They forward me into the interview far further than 9 minutes. I'm not experiencing the 'clipping' you mentioned.