Coding By Numbers - Episode 14 (Craig Smith - Agile)

 

Craig A: In this episode of “Coding by Numbers”, Steve and I interview Agile Coach Craig Smith.  We talk about where Agile has been, where it is now and where it might go in the future.

 

Steve: My name is Steve Dalton from Refactor.

 

Craig A: I’m Craig Aspinall from Suncorp.

 

Craig S: And I’m Craig Smith from Suncorp.

 

Steve: Welcome Craig.

 

Craig S: Hello.

 

Steve: Welcome to the show. We finally got you on here. Craig is a Delivery Coach or an Agile Coach here at Suncorp.

 

Craig S: Something like that.

 

Steve: We just thought we’d get Craig on today and have a chat about Agile and what he’s been up to.  Do you want to tell us a little bit about yourself, an intro?

 

Craig S: Can I say first, yep, my title is an Agile Coach but I’m an Software Engineer at heart so I’m out helping people do Agile but Software Engineer is essentially what I do so...cutting code...I don’t get as much as I’d like to though.

 

Steve: What’s a Delivery Coach?

 

Craig S: Delivery Coach is actually just our title, I guess it’s if we decide not to be doing Agile at some point we probably going to add some value somewhere along the way but the idea is really to help teams deliver software to users, that’s the key point, the key point of the exercise.

 

Steve: Okay.  I know in Suncorp they have been doing some sort of Agile around non-software projects as well, do you get involved in that at all?

 

Craig S: Yeah, absolutely.  I gave a talk at the Agile 2010 conference in Orlando a couple months ago about that.  I think there’s really a lot of potential for Agile in non-software development.  Potentially because if you look at it, we’ve come from a background where we’ve been doing methodologies in software development whether it be Waterfall, whether it be RAD, whether it just be chucking stuff together and compiling it.  We have a process, we know we write code, we know we deliver it.  But if you think about a lot of the ways that people approach business problems, they don’t really have that approach. They kind of, they ferry around, and try and figure out what it is and try and polish it and never quite deliver it.  So actually giving them something to actually say: "It’s okay to deliver it, it’s okay to deliver it in little chunks, and pilot it".  It’s actually a big difference for a lot of teams that aren’t doing software development.

 

Steve: I think with me Agile, a lot of stuff about Agile or whatever you want to call it...is there’s a lot of common sense there.  I think I guess there’s a lot areas in business not just IT where there’s a whole lack of common sense, you think, why are the hell are they doing it that way?  Even if it’s digging a hole in the road, or whatever you know.  Bringing that aspect into things is...a good thing in certain respects but in other things I think maybe it doesn’t quite fit...like its where you sort, sort of...

 

Craig S: The biggest problem is, I had a manager at one point who brought me into the team and goes: “I want you to help us do quality Agile”.  And I looked at him for minute and sort of said: “Don’t you mean you want to deliver quality software?”.  I think the problem is that it’s transcended a little bit. You know a few years ago we were talking about it because we wanted to do things differently, we were trying to get people out of this whole spend six months writing a specification, then write some code, then maybe hand it to a tester at the end of the process.  That’s starting to become entrenched in the way we do things.  But the problem is that it does that, and more people talk about it, and now you pick up an airline magazine and they’re talking about Agile in there.  It’s really hit the mainstream.  But now the problem is that people are now treating it like how do we do it better.  As long as we’re focusing on how do we do what we’re trying to do better, not how do we do Agile better, then we’re in a much better place.

 

Craig A: So it’s just a means to an end, at the end of the day.

 

Craig S: Pretty much.  It’s a culture.  And if you go right back to the core values, which is where I usually spend a lot of time, that’s my, my number one my pet peeve at the moment is taking people back to the Agile Manifesto and why those 17 guys or whatever got together in 2001 at a ski resort and said we needed to change things.  It’s interesting to hear the theme coming out of the Agile conferences around the world this year.  Lots of people are talking about getting back to basics.  It’s really true.  Because now its, you go to the conferences you're hearing lots people talk about how do we do project management better, how do we do program management better.  A lot of talks are now very much on the management side of the fence.  But the reality is that it’s the core basics that get us across the line.  Those core values of trust, and honesty and courage are really the key things that we set out to achieve.  To actually say to people: “You don’t have to do this structure just because this structure is there”.  One of the things we have to be careful of, especially as a lot of the large Fortune 500 companies and large organisations around the world start to go down this path, is that we don’t just end up with another mess, another you know certification mess, another “We’re doing Agile, and we’re following it by the book over here”.  It’s a bit discouraging when you see things like the Scrum Alliance, really starting to head down that path now. Certification was one thing, but now they are talking about books of knowledge and all sorts of things.

 

Steve: Then you get a Certificate 2 in Agile X, Certificate 3, Certificate...it’s like the PMIs.  Isn’t it? And all of these.  I think one of the things that I’ve found interesting about Agile when I first got into Scrum...the guy that taught...did my certified Scrum Master...and whether you love it or hate it or whatever...the guy that did my...he was talking about when he originally got into software...I don’t know when it was, the 60s or the 70s...and he said he was basically a sole programmer.  And the guy who he was delivering the software for sat at the desk next to him.  And he said they basically did Agile back then, it wasn’t called Agile back then, but that’s how, he said everything about the way I worked there was pretty much Agile.  Then as companies grew this whole thing sort of developed around and we had to start separating people and all of that stuff got in the way...I’m getting off track...sort of bringing it back...but I guess the danger is we do this thing, it becomes like a bit of snake oil type thing and we start and other vested interests start coming back in and before we know it we've just got Waterfall with a different name.

 

Craig S: Absolutely, absolutely.  You think about it, I mean, all the original stuff was all about small teams of people and how do they work better.  Now we’re starting to hear people say: “I have a team of 100 and how do they work better”.  We’ve kind of lost the point of the problem.  What does concern me though, is that a lot of the original people, I see them talking now especially as people have moved out of the core technologies like Java and .NET and they’ve moved into things like your Rubys and your Scalas and those kind of languages.  A lot of those teams of people that are doing those types of projects are actually quite small and they do profess to be Agile but if you actually look at what they’re doing...even they’ve actually thrown away a lot of those core values.  They’ve just kinda gone back to a lot of hacking again.  We have that danger of, we almost go too far down the Agile path, we think we’re so uber-Agile, that we’re actually just back hacking again.  It’s that balance between a little bit of structure that helps you deliver something and put it in your customers hands, cause that’s what it’s all about, delivering value, giving it to your customer.

 

Craig A:  I think what it’s really about...discipline as much as anything else...you have less structure, you can have less process, for want of a better word, so long as the process that you do have you stick to, and you follow it and if it’s wrong then you change it.  You don’t kind of just follow religiously this process through and through and through and through.  And then not actually look at what it’s producing and how it’s effecting the team or how it’s effecting the product or how it’s effecting progress.  If you just keep banging away and just doing it blindly then you’re no better off whatever your actual process is, it’s irrelevant, you’re still never going improve, which is, like you say, that’s really the point, is to keep doing things better than you did it last time.

 

Craig S:  This is the important thing...this thing is a really hard thing.

 

Craig A: That’s the hardest aspect of it all.

 

Craig S:  People assume that there’s rules in what we do.  We do very simple exercises with people when we train Agile.  You give them 5 minutes to achieve some task and you come back to it and you go: “Why didn’t you ask any questions?”.  And their first response is: “I didn’t think we were allowed to”.  And you go, “Well, I never said that you weren’t allowed to”.  And in the work place people think they can’t make change because they’re not allowed to.  Whereas, most of the high level managers are actually sitting there waiting for someone to come to them to go “How can we do things better”.

 

Steve:  Or you got the opposite.  Where you got teams, who, they are doing the retrospectives, they wanna make changes, they wanna adapt the process and you’ve got managers who have, basically, took the Agile pill but then they haven’t got the whole idea that Agile has to be agile in it’s own respect as well.

 

Craig S:  They haven’t got the courage.

 

Steve: They actually just took a process and overlayed another process - I’ve seen that happen a bit as well.  That’s where I think there are some challenges...like I think people like yourself, Agile coaches, doing quite well getting teams across from Waterfall to Agile and introducing Agile to people but I think that people who have already adopted it now, maybe have to have close, hard look at themselves and get help as well.  So maybe it’s a different kind of Agile Coach, maybe it’s still in your remit, but maybe a different way of approaching existing teams who maybe have been doing it for a long time but maybe who have gotta a little bit too Waterfall in their Agile...if you get what I mean...not Waterfall...but...

 

Craig S: Yeah?

 

Craig A: A bit too rigid?

 

Steve:  ...again they’re coming against barriers from management or in their own team...

 

Craig S:  I think it’s a bit simpler than that sometimes.  Leave the Agile aside for a bit.  I know in teams where we were doing XP very early on...so we were talking about things like test driven development, we were talking about things like continuous integration.  Which are obviously key tenets to a good Agile project...but those type of practices.  I think a lot of it comes to the, I think the sphere that we’re sitting in here, us the people that listen to this podcast, the people that we’re speaking about Agile and go now: “Yup, I know all about that, I’m the dude”.  They’re not really the people that we need to get at.  Unfortunately, there’s still, in my opinion, a reasonable minority of the people out there, the sad fact of the matter is that most people working in large corporates, most people that aren’t listening to podcasts like this or getting involved in what’s going out there they are essentially cowboys in their own right.  They’re following some either rigid process because they don’t know any better or they don’t feel the power to change something.  They don’t really care about their craft or have any passion about doing things better.  If you get a team of people together like that or you get a team of people where there’s that the majority it’s hard to make those changes.  In some of those early XP projects we introduced people to test driven development, continuous integration and said: “Go forth and spread, it’s okay to do this”.  They go back and work with a bunch of other people and then whether it’s the manager or whether it’s the people around they just go “Oh it’s just too hard” and they give up on it.  Whereas, for me, it’d be like once I learnt test driven development and once I heard about continuous integration you would just either do it or walk out.

 

Craig A: I think change is hard enough as it is without meeting resistance from other people.  You know?  Trying to change your own individual habit is difficult.  Trying to change your whole team or a whole company can be hard.

 

Steve: It does make a difference when you’ve everyone together and you are all sort of on the same page.  It doesn’t take many people to disrupt the whole thing.  That’s why working on your own can be really hard because you haven’t got the people to bounce off.  But yeah, the team I’m working at the moment are pretty much on the same page with respect to XP, TDD and all of that.  We do slip at times...we check...pull each other back and check each other.  I think we are all pretty good.

 

Craig A:  But ask you self why you do that?  Because the team that you work with are essentially a set of really talented people, really passionate people about their craft.  So if you’ve got that you’ll watch out for each other.  Yeah you might forget about testing being your number 1 gamma - you might go an iteration and then go: ”Geez, we let that slip”.  The fact of the matter is that you’re looking for those signs.  The big problem is that there’s lots of teams that just go: “I learnt Java when I left University 12 years ago and that’s as far as I’m ever going to go”.

 

Steve: That’s right.  I think if you read Seth Godin. What’s he call them?  Automatons? He’s talking more about factory workers and stuff like that...and how people have basically lost skills in the work force and things and mass production is coming.  But that happens in software as well.  You look at a lot of the big vendors for instance and then you get problems like these kinds of things with the Health payroll. I’m not saying this is related to that.  But these big companies they treat software like a...

 

Craig A: Like a production line?

 

Steve: ...production line.  People aren’t suppose to question these things, you just do your job sit down and code.  I’ve seen that quite a bit with certain vendors that I’ve worked with.  So I can understand how that can be hard...to get Agile going.

 

Craig S:  Some of those big things.  If you give that example for that payroll system the debacle we’ve had here in Queensland.  It’s a really good example of, I hear all the time that people go: “My project is different.  We can’t do this in an Agile way”.  I’m telling you now, I don’t think I’ve ever been in a project where it hasn’t been different.  Unless you’re doing a “hello world exercise” - there’s challenges to overcome.  Making the excuse that we have to follow some rigid process because we’re different is kind of defeating the purpose in the first place.  We actually want to have a flexible process that we can do the thing that makes the most sense.

 

Steve:  What are your thoughts on the idea that you can’t do support in an Agile way, and that infrastructure is better, like what’s his name, the guy from ThoughtWorks, Martin Fowler, who basically says, that you should do Waterfall for infrastructure projects, something like that...he says.  Any truth in that?

 

Craig S:  There’s some truth in that statement but if we go back to the basics...if you go back to...come back to the Agile Manifesto...we still want working software over comprehensive documentation.  A lot of people say you can’t do Agile in an infrastructure environment, you can’t do Agile in a support environment because I have to fill out a ticket over here or it takes me 3 months to build a server over here, or whatever their excuse is.  

 

But to come back to some of the basic tenets about having a visual indicator of what everybody is working on, making sure you don’t have too many things in process, that you’re only doing things that make sense.  If you apply those basic Agile principals, even if you say this is something where I have to write a specification up front, if you think, if we were writing heart transplant software I’m telling you what, I think I really would want to write a Waterfall specification up front and understand all the problems that are going to attack me in that space.  Whereas, if I’m just writing up an internal web based application - maybe not so much.

 

So there’s horses for courses...it’s just there’s that thing...we say: “We must do this thing all the time”...is the notion we need to get away from.

 

Craig A: The phrase I’ve heard a number of time from various people is “Just enough”, you know.  Agile is about doing just enough, the right enough amount you need, not too much, not too little.  It is difficult to hit that right line, you know, to get enough process in place that you don’t make the same mistakes over and over and over again...but not so much that you get drowned in it and you end up never delivering anything.  

 

Craig S: Absolutely.

 

Craig A: If you need to build a mission or safety critical system then you’re going to put a lot more effort into specifying it up front because it is important.

 

Craig S:  I tell you what, I would probably want to do test driven development on that.  I want to know as soon as possible if that that heart rate valve system isn’t working properly.  

 

Craig A: Exactly.

 

Craig S: Same even with infrastructure, I mean, yes it’s a lot harder because of the lead times and the hardware notion of things...but you can still plan that stuff visually, you can still break it down into more manageable chunks of work and make sure you have the right people at the right time.  Suncorp is a good example with our Windows 7 deployment here.  Where they took that in a very Agile fashion.  There was a government department here in Queensland and Suncorp started deploying Windows 7 at the same time.  Suncorp has it now on developer’s desktops...they’re still doing a bit of a trial...they’re about to roll it out to everybody.  The other government department that started on the same week as we did are still writing the documentation about the policies that they might decide to put in when they roll it out.  There is not one desktop in use anywhere.  Now, the downside when they did the Windows 7 deployment here was that you might have signed up for an early desktop and your desktop might have been rebuilt 16 times along there, but for the most part the people who wanted that desktop were willing to take that sacrifice because it made a difference in the way they did things.

 

Craig A:  It’s the usual early adopter sacrifice, you’re going pay more for it but you’ll get it sooner.

 

Steve:  In government I found there wasn’t ever that, it was an all or nothing type approach.  They liked to use the term Agile in some things but it never really happened.  And some things were so non-agile I just couldn’t believe they even said the word.  I can really understand that whole desktop thing.  I’ve worked at other banks as well in Sydney, where we were on NT...the whole NT support thing...they tried and tried and tried to do deployments and they would always trying to do it on a big scale.  All they needed to do was do the small steps thing and they probably could’ve got there but it was always a big bang...it was like how are we going to do...don’t worry about...just focus on...

 

Craig S:  Any thing in software in large organisations is the same boat.  People are very scared about...you take it to the extreme of your Googles and your Yahoos where Flickr for example, continuous deployment rolls out every 30 minutes.  What’s the worse that could happen? Your 30 minutes worth of changes.  Okay, maybe a large bank or insurance company can’t make that same commitment but it doesn’t mean you have to big bang everything.

 

Steve:  Well there might a department, there’s a lot of things in banks that are high risk, but there might be another department maybe with less risk.  Governments I guess are a bit of a unique one because they’ve got, and I think this is particularly in this day and age, and I don’t know if this is different in other countries, and maybe you’ve had some experiences from your conferences.  But the governments seem to be so risk adverse, they’re so scared of the political fallout from things going wrong and being embarrassed.  So actually governments are like the least, the most risk adverse organisations around here - certainly in Queensland.  Maybe it should be the other way around.  Maybe they should be taking chances and doing things.

 

Craig S: Interestingly in the US though, in the US they’ve made a lot of changes.  There were a lot of good case studies at the recent Agile 2010 conference in Orlando where people were talking about how they are making these changes in government.  Are they all the way there yet?  No.  It’s good to see that there’s more people talking about this.  It’s interesting seeing the types of organisations that turn up to these conferences now.  That’s where the mainstream thing has come from.  Organisations that I would never have expected to turn up to these things a couple of years ago are coming along.  Their commitment to it varies from interest to full in commitment, none the less the fact that they’re even sitting there actually talking about making change is at least a start on the radar.

 

Craig A: At least they are paying attentions to it.

 

Craig S: That’s right.

 

Craig A: Which is more than they were doing - eventually they’ll get there.

 

Craig S: The little joke I made on the presentation I gave this year in Orlando was that I’ve been to three international conferences now.  The first year, the first conference I went to was the one in Toronto, I made the joke that it was interesting that we had an Agile conference right near one of the world’s greatest waterfalls.  It just felt like that.  It still felt very niche, very out there.  The story that Paul King, who was on the podcast the other week, and I gave a talk and it was just about how we were doing Agile on one of our small projects.  And they were the kind of stories people wanted to hear.  

 

Whereas Chicago, the following year really felt very big city, lots of sky scrapers and the conference did really feel like it was more mainstream that big business were taking notice.  But this year it was moved, unfortunately due to flooding in Nashville, they moved it to Orlando right to the home of Mickey Mouse.  It really felt like Agile has really gone to that, “It’s all good, we know what it’s about” and it’s the mainstream.  

 

It’s now moving back and saying: “Okay guys we all get the picture now, we don’t have to come to a conference and spend the next three days explaining to you what Agile means or what the tenets are”.  But now we actually got to get back and go, “Have we actually taking it too far?”.  And what are the next interesting things that are happening in this space.  How are we going to continue to improve on the way forward?  

 

I think the interesting thing I really wanted to share here is that what I’m seeing is, we had to go down this path of getting software developers, and business analysts, and testers together to talk about stuff.  And that’s what we need to do in our teams as well.  You go there now and the testers are going, “Well I wanna know more about testing”, the developers are going, “I wanna know more about development”, and the project managers are going “I wanna know about project management”.  So I think the challenge now is actually breaking these Agile conferences up because it should just be now more the mainstream and actually making sure that when you go to a testing conference that there is actually more than just the one token talk about Agile.  It’s all about how we can do things better - that’s the challenge.  Until we can kinda make sure that it’s got to the mainstream - those other 70% cowboy ratio that I talked about before is really the problem.  Getting it our of our little niche and moving it into...

 

Steve: So I read your comment at the recent Agile conference that there were less developers this year.  Was that the case?  I was just wondering...

 

Craig S: Yeah.

 

Steve: Do you think it is a little worrying, that it’s skewing towards...more towards managers.  What sorts of people were going to the conferences?

 

Craig S: Certainly the amount of technical talks and amount of people that were sitting in the technical talks this year was much less this year.  I’m not entirely sure what the...

 

Steve:  Maybe the financial crisis?

 

Craig S:  I don’t think that helps. If you were going to go to a conference you probably don’t go to an Agile conference to get tech.

 

Steve: No.

 

Craig S: And that’s I guess that’s really the point.  The problem is that if you go to a tech conference you’re not going to get a lot of Agile in there either.  You’re going to have to use your mind to figure out how that kind of assimilates.  That’s something that has been changing.  Same with the Australian conferences.  The Australian conference, Agile Australia, really made a decision not to do too much tech in there because the YOW conference, that we have here in Australia in December, is going to...covers that kind of topics.  There was no point...people wouldn’t go to two conferences.  But you can use the same argument for all other streams.  Certainly yes there’s lots of project management and program management.  Again that’s the stuff people are really struggling with at the moment.  It gives that illusion.  But on the same token, the amount of people that are trying to actually get there head around it.  The developers kind of, at least that are doing it, have got it. It’s now the developers that are saying to their project managers and program managers we want to do it this way are now at the point where they’re going “Okay, how are we going to react to this?”, because what people in our teams are doing these kinds of things.

 

Steve: Maybe devs aren’t so interested into going to conferences...actually avoid them...the big keynote type conferences...they want to do more grass roots type stuff.

 

Craig S: We had to go a couple years ago, right?  Okay, we had to go to spread the message to project managers to say, “We want to do things in an iterative cycle.  We want to do things and deliver software sooner”. That message we’ve kinda of got out there.  Other people have picked that up.  That’s why I can walk around calling myself an Agile Coach.  Which was a job that didn’t even exist 3 years ago, right?  There’s thousands of people out there are doing that same job.  What we’ve created these roles and these people that are now spreading that message on behalf of the devs.  So as developers we can actually go back and just do what we do best which is actually cutting code.  The problem is we do have to keep one eye open to make sure that it doesn’t end up down a rabbit hole that just becomes, as we say, another Waterfall.

 

Craig A:  So what would suggest is the, you know, what do you want to see at these conferences, who do you want to see presenting now to whom, to kind of move the whole thing forward?

 

Craig S:  I think the perfect world is to let it mix.  But I think the reality is that perhaps that’s not going to happen and I think we’ve moved passed that now.  I think it’s more making sure we’ve got at the development conferences, the YOWs of the world and maybe TechEDs those kind of things, in the area especially that you have, you can go there and it’s quite easy to figure out, you know, how you do this and making sure people understand that we’re not going to have a whole talk about continuous integration because continuous integration is just the way you should be doing things.  It’s a no brainer, in the same way that...

 

Steve: It’s a given.

 

Craig A: There’s a whole bunch of information our there that people easily can get now.  There’s so many articles on continuous integration.  There’s free videos sequences on test driven development.  All these things are out there.  People who know it best and been doing it for the longest are sharing that knowledge for free.  You don’t need to necessarily go to a conference to pick that up anymore.

 

Craig S:  All we need to make sure that the people that don’t know about it because there’s still a worrying amount of people out in the world that don’t know about this stuff.  The amount of people, I go out of my usual sphere of influence and I go and talk to the small five man PHP team that I was talking to the other day, out in suburban Melbourne and you say to them “Continuous integration” and they look at you blankly, “It’s a what? Oh, we do that agilely type stuff.”

 

Steve:  I do know PHP guys doing CI so...yeah it’s rare...I think it’s rare...particular languages are better at it than others.

 

Craig S:  I don’t just want to pick on the PHP guys.

 

Craig A: No but it’s...

 

Craig S: There’s a lot of PHP programmers out there.

 

Steve:  PHP is one of those languages that is very easy to pick up and there’s a lot of people in there...I’ve struggled to get Agile into PHP teams as well.

 

Craig S:  But .NET...there’s a heck of a lot of .NET programmers because Microsoft hasn’t bundled that stuff in there which is why a lot people are attracted to the .NET side of things.  Ruby...is the same...even though there’s a lot of those tools out there...

 

Steve: I see a lot of Ruby talk about Agile but then I see lots of Ruby developers...

 

Craig A: Not doing it?

 

Steve: ...hacking a lot...but we’re not perfect...

 

Craig S: That’s right.

 

Steve: ...no ones perfect...

 

Craig A: Those in glass houses.

 

Steve: Yeah...so if someone wanted...I’ve been thinking about this question...if someone...and I guess this is still hard for the people...if you want...to take a little start at getting into Agile if you’ve got a small team...what anyone is listening to this podcast, maybe it might be developer who wants to try and introduce it by stealth...or maybe it’s just a team leader or something...who says right, I just want to go for it.  Do you have any advice on how the can get started?  Is there a good place to start with all this stuff?

 

Craig S:  The first thing I would say is don’t use the “A” word because you’re just giving something a label.  Look at the things...that you...it’s really got to be that improvement type mentality.  I’ve done this with teams before.  I’ve casually dropped the Martin Fowler article on continuous integration on somebody’s desk.  Or dropped the agile testing book on somebody’s desk and sort of said, “Hey, there’s some good stuff in here maybe we should have a read”.  And find someone else in that sphere of influence, who kind of has some passion to kind lead that with you.  So you’re not just the only person that’s going: “We should do that”.  You don’t want to be the “Agile guy”.  The ones that’s going, “He’s that guys who continually goes on about that “A” word”.

 

Craig A: Crazy cousin.

 

Craig S: Yeah that’s right, the crazy cousin...so you wanna...by doing things by stealth, is kind of I think, is the best way...like trying introduce those things. That whole big bang approach really doesn’t work.

 

Steve: Maybe CI is quite a good place to start looking, wouldn’t you say?  I’ve done that before.  Especially if you’ve got something like Hudson or whatever that gives a nice visual reports and graphs.  You can show that to a manager, and say, you don’t even have to say Agile, you can say I’ve just got a historical report of all our builds here, we had this amount of bugs and now we have this amount of bugs, we had this amount of coverage and now we have this amount of coverage...it might not be 100% and they see the graphs and the shiny stuff...that’s cool and then I guess you can sort of chip away and maybe introduce little bits and piece as you go along...

 

Craig S: Especially for the technical people I mean as much as XP has lost a little bit of relevance - you can still go back to that original book by Kent Beck...it’s still a great place...

 

Steve: It’s awesome.  The pink one? Is that the one?

 

Craig S: There’s white one, the first edition, and there was a second edition which is the green book and it removed a few things like metaphor that nobody got but...

 

Steve: I’ve got the little pink one, I can’t remember, I think it’s Kent Beck and someone else...

 

Craig A: XP Explained?

 

Steve: XP Explained and I just re-read it recently...and not all of it...a few chapters...I thought this is actually really good...I think we should do more of this and less of the worrying about what to call Agile and all of the infighting.

 

Craig A: Kind of goes back to what Craig was saying before about...now the conferences are kind of trying to almost do too many things for too many people.  You need the project management track, you need the program management track, you need the test track, you need the software development track...XP was always very, kind of software developer focused, a lot of the practices in it are very specifically software.  You kind of get people pulled back into that a little bit.

 

Craig A: And all the problem was that a lot of that just stuff became what we perceived, at least in the passionate side of the industry, as mainstream...we just assumed that most people know what a unit test is and most people know what a continuous integration server is and so XP lost a bit of relevance because the people who were already doing that going, “We’ve done that now.  How do we now make sure that I’m working with team B over here and they’re still in a Waterfall fashion asking me to write some stupid document?  How do I fix them up?”.  That’s how we’ve actually evolved here.  But if you look at the XP movement, I think the reason that’s become irrelevant...not only for the mainstream, but you look at people like Uncle Bob Martin, and a lot of those folks, are that they pushing a whole software craftsmanship angle, which on the face of it is just XP phase two.  If you haven’t read “Clean Code”, then just go out and buy a copy right now and have a read of it.  Whether you believe in all of what’s being said in there is not really the point.  Go back and read some of the original books like “The Pragmatic Programmer”.  It’s an old book but that book changed my life, that was probably the first book I picked up and went, “Wow!  That’s kind of where I want to be, that’s how I’m going to better myself.”

 

Steve: See if I can get some free copies to give away on this podcast or something.  I have read “The Pragmatic Programmer” but I haven’t read “Clean Code”...I’ll check that one out.

 

Craig A: Even if you are adverse to reading...all of these things...there’s lot of free...Uncle Bob has got lots of free videos - if you do a search of your favourite video site.

 

Steve: Any good Agile podcasts, around at all?

 

Craig A: It’s interesting...the Agile Toolkit is probably the best known and Bob Paine does a really good job of that.  If you search for that.  He does a lot of stuff at the conferences so he’s talking to a lot of the thought leaders there, it doesn’t really get to the XP heart of the matter though.   I think the problem though is that there’s no one really doing an Agile Development podcast because to be honest with you it would be pretty irrelevant.  It’s podcasts like this one that are actually covering those topics...

 

Steve: You can bring it inside.  I wanted to ask you this question before, I didn’t get around to it. With respect to the way the Agile community has split and schismed a bit in that you’ve got the scrum and Agile Alliance and then you got the XP camp...you’ve got people in the Lean Camp...

 

Craig S: Kanban.

 

Steve: ...kanban and all of that.  What’s your feeling on how that’s going?  Is there animosity there?  Is it just a constructive disagreement and all that?  How’s the community sorta going with that?

 

Craig:  I think the Scrum Alliance seems to have held out a bit of an olive branch to the Agile community and said, “Hey we’re so bad after all”.  Interestingly, what they’re saying and what they’re doing seems to be two different things.  I think they’re actually further apart than they ever were.  Yet they seem, yet it seemed to be talking a bit closer.  The whole certification thing has always been a talking point...

 

Steve: My renewal came up recently...and haven’t really needed it...why should I?

 

Craig: Yeah, I think I’ve still got 6 months left on it.  And I’m not entirely sure whether I’ll renew it either.  There’s some benefit in it.  At the end of the day there are still lots of organisations out there that want a piece of paper and want certification.  We’ve been talking internally here...in the organisation about ISTQB and whether testing certification is valid.  There’s two schools of thoughts there.  I’m not really sure which camp I kind of sit in.  Listening to someone like James Bark - I had a really good breakfast discussion with James Bark and Sharon Robson who’s actually on the board of ISTQB.  It was a clashing of the thoughts because James Bark is on the side, I think testing certification is an absolute rort.  You can sit an exam.  Sharon is on the other side going, “Well you need to have a body of knowledge and you put things together”.  

 

My argument back to James was, you’re making an assumption - a bit like what we were talking about development here - that testers know their craft.  The problem with testing, particularly, is there’s lots of people who fall into for one or another reason.  Software developers who fall back into it because they’re trying to munge a gap. We have people who work in the business who tend to do nothing but user acceptance testing and then all of sudden just get this role of tester without actually ever knowing what they’re doing because all they can do is punch numbers into a screen.  You’ve got other people who don’t make it in some other area, and who go “I could probably do testing” and just fall into it.  And then you have got people who are really good that are what I call the CSIs of software development.  The ones with the magnifying glass really questioning what’s going on.  

 

You have to look at what the difference is between a software engineer and a tester.  I have always use the adage of if you’re walking across the street a software developer looks left and right, looking for a car and walks across the street if they don’t see anything.  A tester walks out on the street and looks up to make sure one’s not falling from the sky.  Because any of those possibilities can really happen.  

 

If you look at that body of knowledge my argument to James was that you are assuming that most people know the key tenets of what makes a good tester.  The problem is that the people that are following your movement are already there.  They’ve either got the passion and they haven’t had to do certification because they know what they’re talking or they’ve gone through the certification path because they want to know about it - that thirst for knowledge.  Again, like the software engineering cycle there’s all these other people at the other end going, “Oh yeah, I know how to use quality center and record and playback and raise a bug”.  The amount of resumes I get across my desk of testers who think that that’s what a tester is is really disturbing.

 

Steve: You’ve got the same developers, BAs, all of these things...you’ve got people...we were talking about PHP before...people who have just fallen into programming...without any programming experience whatsoever...

 

Craig A: Yeah, they just want to build a web site with a bit of data...

 

Steve:  You’re right...you’ve got BAs who become testers, project managers that become testers....

 

Craig S: And that’s cool...like...if you’ve got that passion...and you follow it...then by all means...they’re the people that make the best testers.  It’s all of those ones that are punch clockers who are there going: “Eww, I’m going to make an extra 20 grand if I go do that job or I’m happy to stay in my happy little rut”.  They’re the ones that we really to get doing certification.  The problem with certification is you need to actually back it up with a real exam and a real test of knowledge or something...

 

Steve:  The scrum one didn’t have any of that.  I did the CSM course...

 

Craig S: It’s got a test but...

 

Steve: It didn’t when I did it.  I actually loved the course I did...the CSM course I did.  It was given by Jens [Ostergard]...he was awesome...it was one of the best courses I’ve ever done...the whole CSM thing at the end...where he said: “Now you’re certified”.  It was like...well...I don’t really care about that bit...the course itself was very, very good...and I did like the scrum stuff at the time because it gave me the terminology and the words...that I could use...I could give them to the team...and I could okay this is a scrum...you know...this is a sprint...and even though those words were a bit alien to them...we all decided we know what a sprint is and we know what a scrum is...you can stick to those terms and it’s a common language...that’s what I liked most about scrum...

 

Craig S:  And that’s why scrum certification is extremely popular in Europe especially because they just send everybody on a certified scrum master.  The problem with that is that you don’t want 2000 people wandering around the organisation being scrum masters but at least they have that common knowledge.  We’ve done the same thing here in Australia, the Agile Academy.  Suncorp has put 3000 of their staff through it.  If they got nothing else out of that, that whole exercise, the fact is you can walk into a meeting and mention the word retrospective, iteration and people know what you’re talking about.

 

Steve: I think it’s a bit sad that they didn’t run the scrum certified product owner course in Australia...at all...it was never enough demand...and I thought that was the key one they needed to nail.  Actually getting people, the product owners on board getting them to gauge business value properly and all that sort of stuff.  You know? I asked them about it, I said: “You gonna run those courses?”  They said: “No, we just recommend you send them on the CSM course”.  This was for my product owner at the time, I thought, he doesn’t need to know all that other stuff, I really wanted something for him to deep dive into that whole...doing the whole back...managing the back...doing the business particularly and assigning business value to things...which maybe isn’t a scrum thing...maybe its a thing you need...it’s a business thing...but...

 

Craig S: That’s really the issue...those people don’t step up and go...wake up one morning and go: “Wow! I should become a certified product owner”. Because what they do, they don’t see it as being that extension of being able to do something differently.  At least as a software developer tester I wanna improve my craft...I wanna go learn about Ruby or advanced technologies...whereas...

 

Steve:  It’s definitely a craft on that side though as well I think...you’re right, I don’t think many people think of it that way.  If you can get a good product owner...that’s really important...I saw that first hand in that project...because this particular guy left the company and the guy who took over from him was the complete polar opposite and I ended up leaving...that basically killed the project...I don’t know if the Agile Academy have done anything along those lines...I thought that would be...

 

Craig S: No I mean, they’ve taken the tack of approaching Agile from the phases of development so they talk about it from concept, initiate, deliver and deploy and it’s worked into the curriculum.  They’ve got the same problem, is trying to convince someone they’ve got to go on those courses to learn how their role interacts with that.  They’re looking at things like story writing courses and things which are going to get along those lines but it’s a hard thing.  The leaders are in the same boat.  How do you get the people that really have the ability to make change in your teams and your organisations - to get along to know that they have to lead in a different manner? You know if you can just pop a copy of one of Seth Godin’s books on their desk and say: “Go read this, and tell me what you think” - it’s a hard thing.

 

Craig A: The question I was going to ask was more about the Agile Academy and how that’s working...how many because obviously it’s got a big backing from Suncorp...How far is its reach outside of Suncorp?

 

Craig S: Yeah, I only know enough...the fact I run some of the internal training courses.  It’s interesting...that the model they went for...when Suncorp originally looked out to Agile training all they only thing they could find was scrum certification.  They didn’t want to go down the model of training 2000 scrum masters.  They really said: “There’s a bit of gap here” and spent a lot of time on the curriculum and really ran, as I said, those four phases of the development structure.  What they realised after they did that, there was nothing new in what they had, in that the fact of everything was stuff that was out in the public knowledge anyway.  The packaging of that was something a bit unique.  Luckily the CIO, Jeff Smith at Suncorp, is quite open to doing things just that little bit differently and said: “Why don’t we spread the word out there?” It can only be better for us if our partners and vendors and other people in the industry are starting to talk the same type of language.  They decided very early on that they would retain the IP but essentially the Agile Academy is a non-profit center and basically give that training out to certified training providers who will then train that on behalf of the Agile Academy and the royalties goes back to building new courses - that’s essentially the model they used for that.  It’s interesting that there’s a lot of uptake in, especially the Federal Government, the training partners, there’s a reasonable uptake in New Zealand for a lot of the courses.  And around Australia particularly on the Eastern seaboard Brisbane, Sydney, Melbourne...a lot of the larger companies are really coming along and signing up for that.  As for the uptake in general - I don’t know.  

 

If you look at the Agile Australia conference that’s a good indication...you know it’s only just ran its second conference this year.  The first year they got around about 300 attendees but there was lots of people from the same organisations...this year there were less people but way more organisations.

 

Steve: Yeah it looks a lot more spread...the talks seemed to be more spread as well...it wasn’t just all Suncorp.  It looked like its definitely going somewhere.  Who are the Agile Academy? Whose their main competitors? Would it be like the ThoughtWorks those people like that?

 

Craig S: The people like your ThoughtWorks are more enabling.  ThoughtWorks, from what I can hear, just can’t keep up with the demand in that space.  You’ve got the scrum area - there’s still a major force in there.  A lot of the universities are starting to look into this as well.  There’s a lot of American companies, I was speaking to a lot of organisations in the US, because there’s a dime a dozen of them out peddling their Agile wares now.  I think a lot of them are eyeing off this part of the world now as being the next frontier now for their stuff.  I suspect that in the next...

 

Steve: Spend maybe here...the rest of the world...

 

Craig S: Not only for training...but they are training and consulting companies....we already know that in Australia there is not enough...if you want really want to hire a agile coach or some really hot agile or good software developers, good software engineers, testers...they’re extremely hard to find...a lot of these companies can come in and start to take that ThoughtWorks model where you embed people in the teams to help bring them up...the better off we are.  I think a lot of them are eyeing off saying: “The ThoughtWorks of the world can’t keep up with demand right now so there’s money to be made”.

 

Steve:  I think there’s an opportunity there for developers who are maybe struggling to get up to another level and get better paid work...it might not just be money...it might be more interesting work...they can maybe look at the Agile stuff...I know in our team we’ve been hiring a lot lately and we needed people who had that sort of Agile thought process...the test stuff...it really didn’t matter...we had certain skills on there...Java, Groovy...blah blah blah blah blah...really...we had some really good Java people but they just didn’t get the whole testing thing...and they were just...their CVs were just in the bin.  I guess people who want to get a bit of step up into these companies...there’s lot of companies wanting agile people...they can maybe take it on and try and upskill themselves a bit...maybe in the XP type stuff would be a good start.

 

Craig S:  Absolutely.  We recently spoke, Craig and I both spoke at a recent testing conference, it’s the same thing saying to testers...especially...there’s money to be made here you can be making 30-40 or even double what you are earning now if you come out and say to your self you are actually a professional tester you can do things in an Agile manner you’re willing to get your hands a little bit dirty in code...doesn’t mean you have to cut Java or anything.  It’s the same thing with software engineers, if you can be more flexible you can look for improvements and change your way...not get stuck in your rut...that’s going to put you in good stead.

 

Steve: I know a lot of testers are always wanting to be developers...they were always jealous of the developers...I think working in an Agile teams...it gives you ability to experience both worlds...not necessarily make the whole jump so we...you can pair developers and testers together and everyone is a developer on an Agile team.

 

Craig S: And a tester!

 

Steve: Yeah, same with developers they can go the other way.  So developers can get an insight into the other side of things as well.  I think it’s a good opportunity...for...so that maybe there are people out that who have picked up PHP or whatever and done the whole cowboy thing and maybe they don’t have a university education even...they’ve just picked it up...they might have done a TAFE course...they can go away and admittedly there is a mindset change...it’s not just a skill thing...but they can potentially get themselves up into a different level and maybe improve their career prospects, their money...

 

Craig S: Yeah I mean...you’ve just got to look at something like 37 Signals...you know...their “Getting Real” book..which is a few years old now...in fact they’ve just written a new book...I think...

 

Craig A: “Rework”

 

Steve: I’ve read it.  It’s very good.

 

Craig S: That’s a good example of a very small software company just looking at how to do things differently.  It’s not so much looking at you know, today I’m going to wake up and be an XP programmer.  They just had the reality that they didn’t have a lot of people to do what they needed to do.  They wanted to make money but they wanted to ship a good quality product.  In the end of the day that’s exactly what Agile is...let’s lose the whole connotation.

 

I talk about it in training courses and conferences all the time - I don’t want to call it Agile anymore - let’s just make an agreement to call it “raccoon” - and if you want a stupid name on it - if you want to put a label on something.  I always explain Agile is just an umbrella.  It’s an umbrella for the values, principals and practices.  If you’ve got this connotation that Agile means continuous integration, or Agile means a daily standup or a daily scrum then you got it wrong, then you haven’t got the point.

 

Steve: I read something the other day, it was said about Agile, it might’ve even been a Suncorp email...Agile started from XP...and it gave this historical thing...as if there’s a standard path there...a progression...it’s not.  

 

I think there’s a real reluctance from developers at the moment to use the Agile word and people say the “a word” and they say “agile with a little a” or “an a”...the fact that people are having to do that definitely I think makes me think that there’s a reticence there to sort of and I think there’s the whole snake oil thing as well...they worry that people...it’s actually going to be a negative thing if they mention Agile...a bit like social media and...business coaching and all this stuff...I was talking to Des the other day about business coaching...about there’s so many business coaches...and it’s sad because it’s sort of polluted...muddied the waters...and I guess Agile is a similar thing...as an Agile Coach you must get it a little bit with your title of Agile Coach...causes there’s quite a lot of...everyone seems to be an Agile Coach...it’s sad...people need the label for something...you’ve got to call it something...but you’re right...maybe it should just be called raccoon...

 

Craig S: That’s right. Starting a movement right now people...raccoon...raccoon...

 

Craig A: Raccoon capers.

 

Steve: Let’s pick an Aussie animal...possum.

 

Craig S: I was using wombat but then I realised that it stood for something else completely...

 

Steve:  Raccoon...actually no...I don’t like raccoons they get into your rubbish and all sorts of stuff like that...

 

Craig S: I think we can come up with a better name...I don’t know...

 

Steve: A nice animal, a helpful animal.

 

Craig A: So is there anything else you would like to add?

 

Craig S: I don’t think so...I think...I guess...probably the only other thing...I mentioned the conferences a little while ago...I mentioned before that trying to find where the next level is...I’ve been kind of looking for that...and I’ve been trying to say where are things going to now...a couple of things have been pointed out to me I guess...one is the continuous deployment type stuff...deployment has always been the bug bear...it’s all well and good we can develop iteratively but we still have trouble actually getting the thing out there...tooling support for it’s been pretty woeful in the past.  That’s where people obviously tend to always put their faith in there.  I mean the same thing happened with story walling and things like that. Let’s grab a tool and that will make story walling a lot better.  When actually, putting cards on a wall...

 

Steve: That’s a whole other thing...tools vs...

 

Craig A: Next week...

 

Steve: We’ll be talking about tools.

 

Craig S: Yeah, radiators and refrigerators all those kinds of things...

 

Steve: I like the Lego one.

 

Craig S: Yeah that’s pretty awesome isn’t it...making walls out of Lego.

 

I mean tooling can help...continuous deployment is one of those things that I think people have been talking about but at least now has been getting some traction as a...in the same kind of boat as continuous integration.  Yes it took ThoughtWorks and Martin Fowler a little bit to talk about it.  Jez Humble has released his book on Continuous Deployment which is a good read in that space. At the end of the day you look at it and it’s nothing more than chucking a bunch of scripts together and continuously deploying your software.  But trying to get to that level is something that I think we should be aspiring and it’s something I still think that lots of people don’t have their head around...

 

Steve: The tools I mean...look way too heavy weight and cumbersome to the point where it’s like...yeah you’re right you can’t do it regularly...and only one person in the team that understands it...but for that to work it needs to be simple...something that you can check into source control...it might just be a bash script or something...something that everyone can understand and change easily.  I won’t name any particular names but some of the ones I’ve seen around just to me just look like a huge fail because they’re just so big and I don’t...understandably big organisation have to use them...I don’t know if they should be big...I really like Puppet...it’s just a little...I don’t know if you’ve used Puppet...it’s just a simple little Ruby definition thing...simple...you can just check it in.

 

Craig S: My problem is at the moment is that we’ve really got the big iron and we’ve the little iron.  Puppet is there in the little iron...the problem is...people look at it and they go: “It’s Ruby only so I won’t even bother using it”.  Then you’ve got a lot of the big vendors that are in that space...that are peddling it as part of their integrated application lifestyle management tools.  It’s all way too heavy weight.  I think the big problem with continuous deployment is that most organisations still have to over that whole change thing about that it’s actually okay to deploy more often.  I don’t need to employ some two-bit programmer who didn’t make it or a system engineer who kind of got sick of deploying Windows box to sit here at 3 o’clock in the morning and press a button to deploy this software...that kind of control...

 

Steve: Ken Schaber who has got that company...where they do the continuous deployment to hand held devices, they do continuous deployment right the way through to alpha or beta...I think it’s alpha...pilot customers...from check in...so all the way through...they manage to get it to production...some medical...medical handheld thing.

 

Craig S: Absolutely. I think the adage is that...

 

Steve: When you check it in and it goes all the way though to production and your process is good enough to actually...

 

Craig S: It’s not just Web 2.0...most people kinda of go: “It’s okay if your Web 2.0 and you’re a Twitter and something like that you can do this sort of stuff”.  The real money to be made is in the big iron.  Especially some of these big off the shelf systems...you know...if you could choose to deploy a SAP system...then...then you know that’s something we should really be aspiring to do...because heck...the things 99% written when you buy the thing anyway...it’s just the configuration right...like we really tend to over engineer this stuff.  

 

The other one was, I really saw was Bill Krebs’ doing really cool work in virtual stand ups and virtual meetings with Agile.  If you go and look at some of his stuff Agile 4D - do a search on that.  He at the conference...showed a virtual stand up...which they were using Second Life and telepresence...to do these stand ups...it’s a Cisco product...they actually in the talk did a real live one with State Farm Insurance in the US...and at the end of it I was speaking to him...I was managing that stage that we had...I was really keen to get something...to get that talk on there...because it was something a bit different...I kind of went up to him: “It’s a bit of a lark isn’t it?” And he said quite honestly: “Yeah, I thought that when I first went down this path”.  But he told me this story that...they had this stand...right...and everyone has their avatar and they’re all talking to a real wall...this kind of thing...he said...the team I was working with in this particular company had these people and they were telecommuting from all over the place, there were some people in the office, there were people telecommuting and there was a couple of people...there was actually a lady that couldn’t get out the house...she was house ridden and all the rest of it...and they hadn’t started the stand up but she walked in and she had obviously gone to Second Life whatever and bought herself a new dress and there were two girls talking at the table...they said show me your dress...and she spun and all this kind of stuff...and this is someone who is house ridden and doesn’t get that kind of interaction with people...and these other people somewhere over the country...but they had this presence...

 

Steve: It’s a big psychological thing for those people.

 

Craig S: It’s that...we always talk when we do...especially when we do distributed Agile about looking somebody in the eye, right.  Is that once you’ve looked someone in the eye you at least get that trust factor in there.  You can’t do that.  Some of these tools are really good.

 

Steve:  There’s some huge implications for Australian with all this talk about the NBN and all this stuff.  You’ve got all these country towns where they’re saying, “Oh you’re taking away irrigation rights, these town are going to disappear”. You could potentially have people living anywhere and doing some this virtual stuff and it’s not going to be perfect but if it means you can have...you know...live anywhere you like and if you’ve got decent internet...I guess there’s a whole new podcast there.  Again and again...I have noted that.

 

Steve: Thanks Craig.

 

Craig A: That’s two podcasts.

 

Steve: That was an awesome discussion thanks for joining us today.  Probably lots of other things spun out of that.  So I guess we’ll put some notes in the show notes.  I’ve got a final thing...I’ve got lots of things to give away on this podcast...I have to remember...I’ve got to announce this at the end of the podcast...I’ve got some CDs from Mike who is the guy that does our intro and outro music and is a friend of mine...he has got a new album and he’s got some CDs he’s given me. I don’t know if there’s any iTunes stuff or anything like that.  It might just be old school CDs. If anyone who can...are we going to do email...on the Google...what’s the Google email address?

 

Craig: podcast@codingbynumbers.com

 

Steve: Yeah, if anyone can email the answer to this question that’s which is...has been encoded into this podcast which is: “Where was the first Agile conference that Craig went to in the US?”  If you can tell me the answer to that...

 

Craig S: Actually, it wasn’t in the US...it was in North America.

 

Steve: North America. Damn.

 

Craig S: Hint, hint, hint.

 

Steve: A big hint there.  In North America where was the first Agile conference?  I’ll randomly pick by some bizarre means...some winners.  

 

Craig A: I’ve just answered it on the iPhone.

 

Steve: Have you?

 

Craig A: I’ve entered too but I think I’ve got it wrong.

 

Steve: They’ll be excluded and we’ll get the CDs to you. I’ve got lots of other cool things to give away.  I had Groovy mags for the last one but I forgot so I’ll give the Groovy mags away another time.

 

Craig A: Yeah, we’ll do more give aways in the future.

 

Steve: Thank you very much.  Thanks for listening.

 

Craig A: Thanks a lot, thanks very much Craig.

 

Craig S: Thank you.