1. [...] What are you seeing and what are your impressions in general? How does Australia stack up?
Craig's full question: Hi, my name is Craig Smith and I am an Agile editor at InfoQ and I am here with some of my Agile revolutionaries here in Australia. Welcome Tony Ponton and Renee Troughton. So we do a podcast called “The Agile Revolution”, but the reason I wanted to get you guys together was also just to talk about the state of Agile in Australia. We have a podcast called “The Agile Revolution” and we talk about all things Agile. But we are here at Agile Australia in Sydney, so I guess what are your impressions? It’s the fifth year now at the Agile conference. What are you seeing and what are your impressions in general? How does Australia stack up?
Renee: We rule obviously. But yes, a huge number of people here. I think this year is interesting in that it is the first test of growth within Australia. So we have in essence a number of conferences coming into Australia, whereas previously it was a very shallow pool of choices. What’s great about it is, that despite the greater choice of conferences to go to, lots of people are still here. So, you know, it’s certainly crossed the chasm.
2. We are talking about 900 people at this conference. What was it last year?
Renee: Eight hundred.
Craig: But last year we had the CTO from ThoughtWorks out here, Roy Singham, and he said if you took that in comparison to the US Conference.
Renee: On a per capita.
3. On a per capita basis you’d have a million people at the conference, right?
Renee: Yes!
Tony: I think the interesting thing about the dynamic for me as well is that we’re still getting the adapters as well as the people who want to look at how they can take it to the next level. That’s a good testament to the actual conference is that it caters on both levels for that as well. Because I think in the early years there was a lot of adapters, or people who were looking to adopt the Agile transformation. But now we’ve got companies who are obviously in that mean, and they want to look on how they could do Lean, or they can take Kanban, or they can take the extra Agile thing to the next level. But then we’ve also got a lot of people who are doing in that early shallow end of the pool saying what are other companies doing out there?
Tony: Just wake me up when she finishes this!
Renee: I come from a software development background. So it started of as a Java programmer, went into BA, testing, ended up team leading.
5. So you have done everything?
Renee: Yes I have done, well in IT I have done a little bit of everything, even done a little bit of infrastructure as well very early on. But I guess a lot of the projects that I was on were very big scale waterfall web based projects. So I was on one of the hugest Java first ever projects in Australia, like a 50 person Java team. Similar sort of sized, twice, projects that went for two years and there were lots of issues. But there was also a lot of really good things and I look back at those very early days, when there was no Agile and we were doing bits that were Agile, and bits that weren’t. And I think we’ve certainly moved forward quite considerably. I talk about, when I train about stories about Agile itself and compare it to what it was like in the old days of waterfall. And a lot of people don’t even know what it was like anymore. So it has quite significantly shifted on. But for myself, I started in my Agile journey officially ten years ago, and actually my first title was as an Agile Coach, or a Delivery Coach, looking at transforming one of the first major organizations in Australia across to Agile. Ended up transforming about 150 people before I left, went over to New Zealand and did the same within a government organization over there. Was there for about five years, decided it was too cold, and came back.
6. Now you are a co-founder of a small Agile consultancy company I guess, Unbound DNA?
Renee: Correct, yes.
Craig: Excellent and working here in Sydney at the moment on some interesting financial projects.
Renee: Yes, a very big financial project going on in Sydney.
Tony: Well, I guess, as you said, I’ve known you a long time, because we were on the original XP projects, but much like Renee I did a lot of different roles within the companies. I was a trainer, and a team leader, a tester. I’ve a big background in testing, business analyst for a very long time, but predominantly in the waterfall. But then an opportunity came up to go and have a look at this “Agile methodology” thing, which was what it was sold to me as, and I had no idea what it was. And about after ten minutes it just made sense, right?
Renee: I think I fought it longer than you did!
Tony: Yes, it just made sense. It was like, why aren’t we doing that? I guess that was the question that I asked myself at that time. So we did mess around with the earlier days of XP. And yes we didn’t get the purchase that we wanted straight up. And unfortunately the first shots at that became a little bit harder. But then essentially we went on to that, that’s how I fell into Agile Coaching. So I guess for me it is probably a natural blend of those early development days and understanding how ineffective it really was, but some of the good stuff that was in there, that we could have done better, and also having that training background seemed like a natural thing to move in that coaching environment.
Tony: Yes, look I think it’s no secret, we certainly peaked for quite some time there with Agile, and like many things do, we levelled, but I think we’re on that step to taking it to the next level again and yes you’re right. You know, essentially it was a very IT driven or business services driven. But the next step for us is to move to that model that brings the business in closer to our work and closer to the people so they talk and I’m really excited about the journey that we’re on.
Craig: Excellent. So, Renee one of the things that from knowing you, that I think one of the things I’ve learnt from you was really Kanban and how it can be really applied, not only just in maintenance type roles but really across all parts of the organisation. You’ve had some real success in rolling out Kanban and in fact other types of Agile techniques into non-business areas.
Renee: Yes, and I guess one of my specialities has been spending a couple of years in the business side rather than just IT. Not just Kanban, I call it more a toolkit of Agile. So, there’s a lot of techniques that will easily transpose across to the business, visualising your work, limiting the work in progress, removing road blocks, identifying constraints. These are all things that everyone can do on a day to day basis. So anyone in essence that’s doing knowledge work, a lot of elements of Agile are just as applicable, a lot of the principles are incredibly applicable, simplify your work, Individuals and interactions over process and tools. Very much relevant.
Tony: Principle number 10. Simplicity, the art of maximizing the work not done.
Renee: I think probably the first and foremost thing that you need to do is simplify the language. Agile as a language, some of the techniques and some of the names of the certain activities that you do, things like planning poker, they are very confrontational in the business world and it’s hard for people to get those concepts when the language is so playful. So one of the first things I end up doing is changing the language, you know putting it up to the level that business people are more than familiar with and then starting to actually get on the journey of: ”Ok, well let’s have a look at all your work”. So I generally start by having a conversation about: “Well, tell me about the work that you do”. And really it’s a classification in my mind that I do of the class of services that they provide and how they provide those. And then the next step would be to understand how that fits from a business process perspective on a day by day basis. Then visualising that up onto a wall and physically writing their cards for them. So, in a lot of cases, where if I go into a team they would say: “Oh, we’ve got a hundred outstanding tickets in this spreadsheet over here”, and then they really balk at the thought of having to write one hundred cards. I will do that for them, just to get them over the line of visualising their work.
11. So then they get the a-ha moment and then carry it on hopefully past that point?
Renee: Definitely. So, what you generally see is, as soon as you start putting it up on the wall, everyone is going: “Wow, we didn’t know we had that much work on”. So that’s a start. That’s the big a-ha moment that you almost always get and then it’ll be: “What’s happening here and what’s happening here?” And you’ll start to see the blockages associated with it.
12. [...] How do you attack being a Lean practitioner differently to being an Agile practitioner?
Craig's full question: Excellent. Tony, you come from software development teams particularly and worked on some pretty big projects and some ones that had challenges in their midst. And then you’ve moved more into the Lean space. So, I’m really interested knowing from you, having been an Agile coach, a Lean coach and now crossing back to an Agile coach. Similarities, differences? How do you attack being a Lean practitioner differently to being an Agile practitioner?
Tony: Well, it’s an interesting thing for me because I don’t think I attacked it any different and I think that’s one of the things, and Mary Poppendieck and Tom when I was talking to them yesterday, that’s really the thing that you need to put into your head. There are a number of Lean concepts and they work with Agile. I mean the Agile guys when they put Agile together they weren’t, it wasn’t like they didn’t know what Lean was, it’s been around for years right? We had that opportunity ourselves to ask Alistair Cockburn that ourselves on one of our previous podcasts and it was like, well, you know. So, for me they fit well, and so for me when I’m teaching that stuff and training with people, and helping them learn how to use it, it’s really just another tool box. Sit there with a bunch of tools in it that you add to your existing Agile tool kit right? And it’s about where you use them in the process and how you use them to maximize what you do.
Craig: But Lean is very much about waste.
Tony: Yes.
Tony: I think for me that’s really about understanding where best to look for the waste. And I think what happens is sometimes we get a little too process oriented, in terms of software and product. We were talking about it before, and it was, it will be a part of the podcast obviously, but for me the blip in the radar or the ghost in the machine is the humans and the technology right? So we can standardize and we can do what we need to do in terms of those things, but the actual human content, how you develop and how I develop, you’ll never standardize that right? But we can standardize the pieces around it that create the waste, so automated testing for example right? Or making sure that the way that we do our exploratory testing is structured. There’s a pervasion out there that exploratory testing is gung ho, let’s just have a… that’s not the case. They’re the wastes and the things that we can actually attack and use those Lean techniques to actually make sure that we get the right purchase. By the way, the thing that I learnt from Renee is how to say Kanban. Not Kanban mate!
Craig: Oh, yes. Or Kinbin if you’re in New Zealand!
Tony: Kanban! Sorry, I had to bring it up.
Craig's full question: So Renee, you and I are giving a talk at the conference on “Visual Management”. That’s probably been something and having seen walls in your current organisation is something that is dear and close to your heart as well as mine but tell us a little bit about, tell us about what Visual Management is and how that differs to just chucking cards up on a wall, because isn’t that what it’s all about?
Renee: Yes, so chucking up cards on a wall is really just a very small portion of Visual Management. I like to lead teams completely through Visual Management. So you know, first and foremost it’s about, there’s a lot of reinforcement about techniques. So if I have someone come up to me within the team I’ll go straight to the wall and I won’t let them talk to me until I’m actually at the wall and we start talking about the work that they’re doing and the relationship of the problem that they’re having against the card itself. So, almost constant reinforcement associated with that. It’s about visualising the constraints of the system whilst you’re actually at the wall so insuring that it’s not just a simple: to do, doing, done. If you’re dealing in a very complex domain of software development you need to expand the wall in order to incorporate those sort of facets. But then, there’s things like metrics so you know it’s not just about having your burnup chart or your burndown chart or your cumulative flow diagram. There’s a lot more metrics out there that you can present. The wall isn’t just for you and the team, a lot of people think that. The wall is there for management as well. The wall is there for clients as well. We have a, a good example would be: we’ve got a client list of our twenty clients in our current project and we have like a niko-niko indicator for them about how happy those clients are based upon the current issues that they have. So we manage our clients through the wall and everyone’s aware of what kind of issues that we’re dealing with at that point in time. We have all of their knowledge artefacts there.
Craig: So you’ve been on that project now for about six months and really introduced a lot of those things with the Project Manager lens really as a way of getting into the organisation. How can you, if you stand back for a moment, how has that changed the organisation in the way they’re dealing with issues, particularly when in this particular instance they are on a very tight time frame.
Renee: So a lot of it is about negotiation. If people come to the team, say we’ve got a variety of different product owners, and they’ve got extra work, again I’ll reinforce the boards. “OK, tell me about your work” and we’ll actually write a card there at the wall and say “okOK, well this is what we’ve got going on”. Very early on we had a lot of problems with injection of change inside of the sprint, quickly adapted to a flow based system, to be able to deal with that change, and now there is a lot smoother of a communication and negotiation about what work has to be done. So it is reinforcing that wall to all sorts of different audiences inside the company as well, and making that the central hub. I prefer to do status reports at the wall. We don’t do sprint planning anymore in a meeting room, we do sprint planning at the wall.
Tony: I think that’s the thing they miss, right? That the most important BVC is actually your wall. And the other thing that’s the biggest change in mindset when you work with early teams is that, that’s the information radiator. I know it is an old cliché, but there are so many information refrigerators in our companies, in our work. It’s great, we’ve got all this information, but then let’s get it out there, where anyone can understand it when they walk past. The biggest mark for me is when a CEO or an EGM or management walks past and stops, and you can see them perusing the wall and going, Ok what does that mean? I’d rather hear that, because then you can go over there and explain it. And every time they walk past, they’ll look at that. So for me that’s the mark, that you’veactually done the right thing and you’ve won.
Renee: I had a really good example of a CIO. I went up to a wall I am less than familiar with and I talked about, why is this card here? And the CIO was able to explain it to me.
Tony: Look I think it’s the Agile 101. So, it’s teams that have’nt adopted the process earlier. The people really want to do this and they see sense in it, it’s just how do we do it? It really is about having that practitioner lens in there and using the tell, show, do. This is how we do it, and showing how it is done and the letting them do. Sh, ha, ri. And helping them just build their way through. So, a typical challenge I guess is breaking down the old stereotypes of the things that we did opposed to the things we do now and explaining: “Well, those things that you do did actually weren’t bad, I’m not dissing them right? And in fact a lot of the things that you did in the past are actually wrapped up in what we’re doing here in small, sharp, iterative cycles”. So, I think that’s the other thing, when you can put it in that light and put in in different terms the light goes on. And there’s nothing more exciting for me than to see people get passionate about it and go: “Yes!” And the other thing is giving them the premise to enjoy their work and celebrating when they really do succeed. You know, that’s that human piece for me.
17. We do a podcast. It is called “The Agile Revolution”. You can find it where, Tony?
Tony: www.theagilerevolution.com
Renee: My impetus?
Craig Yes for an Agile podcast.
Renee: I had a look at what podcasts were out there and there were a couple but there wasn’t a lot of active podcasts that actually got into the nitty gritty of it. And I felt the need to have something out there that got the message out but also dealt with a lot of the problems that you have on a day to day basis. So a lot of the podcast it’s more speech based rather than talking about the news of what is changing in Agile. Because it is really difficult as a coach to keep up to date for a start and also what’s problematic and keep it very light hearted and fun.
Tony: And we do that.
Renee: Yes.
19. Tony, what about you? Why did you sign on to join us as a merry band of podcasters?
Tony: Because Renee told me to.
20. She had a card on a wall and stood there with a status report?
Tony: She had a card and it was in my column. No, I think when the idea was first pitched to me, I sat back and thought about and thought what a great opportunity it is just to ask the questions of the community out there, right? Again, wisdom of the crowd and that crowd sourcing type thing and there’s no better medium. Like when we do the podcast we don’t have the answers a lot of the times. But we position our thoughts on it and we get feedback,and I guess we probably never thought we would get as much feedback as we do but it’s very interesting that people are interested in and want to have that conversation I think.
Craig: Well for me what I really like about talking to you guys, it’s that conversation particularly as a coach. A coach can sometimes be a very, a job where you don’t, you’re lonely sometimes right? Because you’re the only person there and tparticularly we’ve worked together in a team together, now don’t work together in a team together. But it is that conversation I think that has continued and having conversations even like this it widens your perspective and for me it’s just turning on a microphone and having the conversation that we probably would have had over a cup of coffee or in a corridor somewhere anyway.
Tony: So let’s face it, the Agile community is a very passionate community. You know you’ve only got to sit down at a bar with a bunch of Agile people and there will be conversations going backwards and forwards and they may not agree but the whole thing is everybody is passionate about what they’re doing and it is with the best intent to get the best results. So, and I think that hopefully that transmits through the medium of the podcast and the bounce back that we get.
Renee: There’s no ”Waterfall Revolution” podcast.
Renee: My key issue at the moment is around, I wonder whether we’re focusing on the wrong problem. And the two things that I see quite commonly as an issue: one is the lack of an establishment of a learning culture and the second thing is the lack of appreciation of experimentation. When I started on the Agile journey there were no rule books, there were no cookbooks and it was quite easy and easily acceptable to do a lot of experimentation to work out what worked and Dave (Snowden) talked about this and the fact that we don’t know what works and what doesn’t from a pure measurement perspective. We know that Agile to some extent works but we don’t know why. And in those early days when we were starting to write the rule book it was through that experimentation and I think a lot of people when they pick up Agile get told off for experimenting and I think that’s very wrong thing in our community. The other thing is.
Renee: We’ve lost the art of thinking and I want to bring critical thinking back into everyones every day’s lives: so experiment, critical thinking and continuous learning. The first thing I try and do when I’m working within an organisation is establishing a continuous learning culture.
24. Tony what about you? What should we be talking about?
Tony: I think if you’re asking me that I would be hoping that we as a community of eating our own dogfoord and drunk our own kool-aid would be in terms of the fact that we’re still continuously improving, that we haven’t stopped the bar right? Because the last thing we want to do is stop here and say: this is Agile. And I’m scared that that will happen, right? Because once we do that. It’s a bit like Dave Snowden said, if we build the big headquarters then in two years we’re going to be dead, right? There’s that factor out there he says that when a company gets so full of themselves they build the massive headquarters, they fall over. Well, the same analogy is that if we draw that line in the sand and say Agile’s reached the masses, Agile is at thay 99% saturation. Then I think as a ethos it will die.
Renee: Yes
Tony: We need to keep looking for that next step. Building that next piece of momentum, moving forward and I think that’s where we need to go.
Craig: Which is good because we’ve got people like Dave Snowden and people who weren’t really in that Agile mindset necessarily: Dan Pink and Seth Godin and I could roll off lots of names of people that are n that periphery, even things like people who were in the Agile community, people like Chris Matts and the guys who talk about Real Options and Bjarte who is talking here about Beyond Budgeting. There’s all these sorts of things on the outskirts that are a bit different.
Tony: My stipulation with that is what I do see is that in our community there is an older and this is no difference because we’re oldies as well, but there is an older layer of that innovation at the moment. What I want to see us do is infect the younger layer and get them involved. Because the reality of it is they’re the ones that are going to have that new exciting edge, they’re the ones that are going to be thinking outside the box because they haven’t been inside the tunnel right? It’s like the same thing as us as Agile coaches. What’s our job right? When we walk in, our value is is that we are actually standing on the outside to start with so we can see in what’s happening. Now, yes we do get into the mix because you’ve got to get in there and do some of that practitioner piece and show. But the reality of it is, the value is is that we can see the outside and now the trouble is we are on the inside of Agile. So for me it’s that new blood that we bring in. We’ve got to infect them and we’ve got to take their ideas, we can’t just say “Oh no, we can’t do that”. No, we’ve got to look at those on the best value and take those and improve our process and drink our own kool-aid. Iterative development.
Renee: I’m very concerned at the moment that a lot of people think that Agile has crossed the chasm, it’s gotten there. The issue that I see is that it takes generally around about two years to make a good coach, two years of quite intensive effort.
Tony: I would say longer.
Renee: Yes. Well, I mean at best right?
Tony: At best, yes, you know.
Renee: And we have
25. The 10,000 hours of practice?
Renee: Yes, and we have tons of organisations that want experts and they’re hiring coaches without enough knowledge to be able to best support a transformation.
Tony: You know I think there’s an important level there. Hey look, if you ask me and this is being very honest. If somebody’s said to me are you a good coach, I’d say I’m learning to be a good coach because it’s still a journey. You still learn things every day. There are still things that I do and go “Oooh, that didn’t work. I could have done that much better. I should have taken a right turn there, I wasn’t expecting that”. But you know, that goes in the tool box, next time it pops out. So that’s why I say to you longer than two years because I reckon there’s a good five years in there before you really reach that tipping point where you’ve seen enough that when the new bits come out you’ve got those tools to pull out of the box and go: “OK, I’ve got something to deal with that, even though it might not be 100% what we need to do”, right?
Renee: So, in essense our success is our undoing, by being so successful at Agile, we’ve had too many people say “Let’s transform to Agile” and we’re going to have all these failure cases of transformations because we just don’t have enough internal knowledge to support it.
Tony: But that may not be bad either. Remember that case of Dave Snowden saying: we need to accept the failure and maybe in instance where companies have those failures, well that’s not a bad thing because then we should be learning from those failures and say ”OK, why didn’t that work so what we need to do to take it to the next level”?
Craig: So based on those years of experience that you guys have besides the podcast you have lots of things out on the public interweb. So Renee, if people want to find out more about you and what you’re doing, you’ve got some interesting things happening at the moment. Q39 So based on those years of experience that you guys have besides the podcast you have lots of things out on the public interweb. So Renee, if people want to find out more about you and what you’re doing, you’ve got some interesting things happening at the moment.
Renee: Yes, I’m working on a white paper at the moment for Value Trees, which is very similar to Luke Hohlman’s ProductTrees. I also have a website at agileforest.com and eventually I’ll get back to writing my book on Leanpub called “Agile Forest” which is about a group of Australian marsupial animals who go on a journey to learn Agile. It doesn’t say Agile anywhere in the book; it’s completely agnostic of all that sort of terminology. It’s just a really good fictional tale that will tell you everything about Agile but without using any of those terms.
Tony: They can find me at disruptivethought.com. That’s my blog so there’s very lack of blogsseeing it’s just being transferred over, but we’re getting that back to where it should be. And furiously I’m working away on my book. So yes, that could be a long journey, however I’m hoping to look at something in the coming year so that should be interesting. Working title of “Some days are Diamonds and Some Days are Coals: The Story of an Agile Coach”.
Renee: Have you got that URL?
Tony: I should get that, shouldn’t I. Stay away from it Renee!
Craig: And of course you can find me at craigsmith.id.au and at InfoQ.
Tony: There’s a lot of innovation around that URL!
Renee: renee@theagilerevolution.com or they can get me on twitter on @AgileRenee.
Tony: tony@theagilerevolution.com or you can get me on twitter @SvenNotnop.
Craig: Try and spell that! And I’m craig@theagilerevolution.com and you can get me @smithcdau. So thanks guys for being awesome for doing a video version of our podcast and a making of podcast that may or may not make out of the mix. It has been great talking to you and here at Agile Australia in Sydney and we’ll talk soon.
Tony: Thanks for the opportunity Craig.
Community comments