00:18:55 video length
Bio Craig Smith has been active in the IT industry for over 15 years. He has been an agile practitioner for over 10 years and is a Certified Scrum Master and a member of both the Scrum Alliance and Agile Alliance. He is currently working within Suncorp’s Business Services division as an Agile Coach, on a number of high profile technical and business projects.
1. This is Shane Hastie here with Craig Smith. Craig is from the Agile Academy from Suncorp and one of the leading lights of Agile in Australia. Craig, would you mind introducing yourself to the InfoQ viewers?
I’ve been involved in Agile, started off with XP back in the early 2000’s after getting the passion from reading Kent Beck’s book and working with some passionate people who just wanted to do software just a little bit differently. Since then, obviously the advent of Agile has became a lot more mainstream and really trying to get involved and help teams deliver software, deliver projects a lot better.
I can’t take all the credit for the Agile Academy, but I’ve certainly done my part to help people learn Agile techniques. Because one of the big things with the Agile Academy was when we first started looking out for courses, when we wanted to train stuff at Suncorp on Agile techniques, with the exception of Scrum there wasn’t really a lot out there. There was certainly certified Scrum Master, but they are only one little bit of the whole range of training we were looking for. We were looking for training that would actually go across the enterprise and across the phases of development, so everything from starting a project up through delivering and deploying it and all the different roles, like testing, business analysts, developers - something that was really a niche that needed to be met.
That has been pretty successful. We passed 3000-odd employees through the training at Suncorp and now with training providers like Software Education, that’s now going out to people across Australia and New Zealand and we’re training lots of enterprises with the same message.
Structured Agility - I wouldn’t actually say those words go hand-in-hand; but it certainly is a way of looking at Agility across the enterprise, not so much structured, but giving people a roadmap. We all look at the Agile books, we pick it up, it’s all about the team and how it gets certain people to interact together. Large organizations around the world are really struggling with why it’s actually making Agile fit inside their organization. It’s really about taking it to the next level, about taking it to the enterprise level and giving them the tools they need, because when people start on a journey, they need more than just a couple of practices - "Let’s do a standup; let’s do a retrospective". They actually need something like a roadmap that says "I have a project. How do I start? How do I ensure success? How do I finish it? How does my role as a tester/as a developer fit into that ecosystem so that we can all be successful?"
Not my idea, but business’s idea. It was something that I was playing around with because I wanted to do something different this year in Orlando and get a few people thinking about things. Something a lot of people have been struggling with, and I think the global financial crisis really hit this home for a lot of people, is we need a change, we need to do things in a different way. At Suncorp we’ve been reasonably successful in getting developers and software development projects through the Agile space, but it’s really the business where the big things happen, because if you look at any software development project, it’s usually still tied to some business process, some business need that has a requirement to change. We just started looking at things and how can the business do things differently because when you think about software development, we’ve had Waterfall, we’ve had RAD, we’ve had RUP, we had all these different methodologies over the years and we know we’ve had to create the software requirements, documents to do design, do coding, do testing we’ve always had something to follow.
If you look at Agile, we still follow those kind of things, it’s just that we do them in tighter time frames and focusing on actually getting delivery of the door. But think about people in the business, think about your accountants, think about people who are doing invoicing. People just come to work and do things on the day-to-day basis, they can change something, but how do they know they’re done? What structure are they following? What I really want to point out is that a lot of people don’t have that thing to follow, so we can actually give them some structure to get a project done, to get some initiative done. Actually give them that definition of "Done" - How do I know that I can get this thing across the line rather than just teasing around a playing with it to refine it. We can really help things happen and they actually get things across the line.
An example: We did an internal project where we looked at the invoicing - it’s the example I gave in my talk - where we were struggling with how to actually insure that the invoices were not getting double paid and to ensure that we weren’t paying for things that perhaps we didn’t need to pay for because contracts had lapsed. They’d been trying to start this project time and time again and really hadn’t got it across the mark; someone would start looking at the process, it looked like a big mountain "I’m not sure how to finish this. Let’s start playing round with Viso diagrams to map at the process . . ." and things weren’t really happening. They invited me in and being a pure Agile person I put a bunch of cards up on the wall and gave them something to visualize. The key thing I found from there was turning those cards over and saying "how are we done?"
A good example was we had an invoice structure that said "If an invoice is over a certain amount of money, it must go to someone for approval." And I said to the business people on this project team (because they were all business people, no technical people whatsoever) "How do you know you’re done?"
Their first response was "Well, if we get an invoice that meets that requirement, then it will go through this process." I went "No, that’s what’ll happen when you have arrived. How do you know that you’re done this process?" They got a puzzled look on their face and they went "Obviously there would be a little box on the diagram and Tick! - that’s the definition of ‘Done’." "What else?" "I have to get my manager to make sure they’re happy with the new process - Tick!"
We did that for all the cards and then an amazing thing started to happen: they actually started to get things across the line, the process started falling out. This is a project they initially envisaged would take three months; in three months they were going to launch with a big bang. In three weeks we were able to get a pilot out so somebody could trial the process. We learnt lots of things; we got a second person on, learnt some more things, and finally we could roll it out. At the end of the three months we had everybody on board, we had a process that was actually working and the amazing thing was that when people were picking up cards and didn’t have acceptance criteria on the back of it, they would shake it and go "How are we going to know when we’re done?" Turn the card over and write the acceptance criteria.
Absolutely. Things like one-week iterations, especially if you got a business project, that help out a lot, every week checking in. These things like continuous integration which we naturally think is something that’s a technology construction, but think about big projects: you want to continually integrate and make sure they become a realistic whole. At the end of every iteration you want someone to come and look and go "Are we done yet?"
Business projects will tend to actually send people off into their areas of expertise, then bring back in at the end and try and merge them together. The same thing we do on technical projects, but the impact is even worse on business projects. So once those different practices, things like standups and retrospectives have really improved how we worked together, getting people communicating, all those practices really come to bear. There are not too many of those practices if you look at them in the traditional sense that are particularly "agile" [technology]. They’re just practices, things that help us on the process. There is nothing [exclusively] software development related about them.
The interesting things are: firstly we’ve been bringing business people along the journey of software development for quite a while, so it’s actually a lot of those people are now asking "How can I do that in my patch?" because I’ve worked on your project over here, I’m doing some other thing over here. I had someone in an insurance assessment center company the other day and they went "I love this thing of being able to prove things up and visualize quotes that I’m doing on a wall" something even I wouldn’t have dreamed of people wanting to do it. So people can see the process in action, they work with it and I want to go forth with it.
But the other side of the coin is - pick up any magazine, any airline magazine (which is a staple reading of CEOs around the world) and people are talking about Agile, they’re talking about Lean and talking about doing things more effectively. So even in the outer space it’s coming from the top down, people are saying "Now we do things a little bit differently."
If you already got Agile embedded in your organization then you can naturally take those learnings from the software development teams and apply them to your business teams, whatever they may be, but if you don’t, then maybe you want to go down the Lean path which essentially will get you to the same destination but using perhaps language the businesses is more familiar with.
It’s going well, it’s slow going. As I said, we’re just building up the momentum now. The first couple of projects we did were just to try it out, so we tried it in areas like HR, we are tried it in areas like infrastructure, as I said we tried it in the invoice areas. We’ve got real estate people starting to dabble in this as well.
We think that it’s really about some of the key things that Agile gives us: better visualization. So many of these business related projects get started and then they lose momentum, they lose focus. If you do simple things like put stories on a wall, put out those big visual charts to indicate what’s going on, that’s the kind of thing it brings in. It may not even be traditional Agile, it could be more of a Kanban type project where you’re rolling through, by getting those artifacts on the wall and getting people talking about them.
An example: one where we made some savings, by introducing [the practices] to a particular project; at the end of the project they were asking "How do we continue to be Agile?" The first thing we did is we did an introspective where we said "you’ve implemented this; when are we going to do the next steps?" So make sure that we continuously improve, so we wouldn’t be doing regular retrospectives any more as the project team was disbanding, but what can we improve?
The second thing is keeping with big visual charts. This project was saving us lots of money and one thing that we often don’t do is go back and see whether the project actually delivered on what it set out to do. So we had a big visual chart on the wall and that’s interesting up in the corridor, showing the amount of things that were processed, the amount of money that was saved. When a manager walks down the wall, they actually pay attention when they see a number that’s moved from 27 to 150 or 1 million dollars to 3 million dollars. That’s something that gets people’s attention and once you really a valuable part of the business. We always have to ask yourselves "What is that place in business? Where are we delivering value?" and that really gets people driving home and saying "I am actually doing something that’s delivering real business value."
9. We look forward to seeing more of that in the future. The other conference that you recently attended and spoke at was the Agile Australia Conference and there you gave a talk on setting up an A Team.
Indeed, I just like 80’s television shows so I wanted to base the talk around that, but seriously, how do you take a team and how do you bring it [to high performance] - there has been a lot of talk about that of late; Dan Pink is a perfect example is his book called "Drive" (http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_1?); lots of you-tube videos and reincarnations of that. People started talking about that motivation and how you get people working at the next level I think it was really started by the book "Tribes" (Seth Goden) (http://www.amazon.com/Tribes-We-Need-You-Lead/dp/1591842336/ref=sr_1_1). If you think about that, he talks about people working in factories. A lot of our organizations still are people working in factories. You come in, slave away at your desk and at the end of the day some manager directs you what to so and you go home.
But if you look at where the real innovation is happening, the real companies are actually pushing them to next level is where they are driving out the passion in their employees. They are letting them do things and almost essentially "own" the business, they are not just being driven by what the management thinks the organization is going to. They are giving them that drive to say "What things do you think we can do to make this business better? What things we can do to drive things forward?"
That’s where some of the innovation is really happening; mostly start up with this "tribes" idea, where if you got the passion the you are person can stand up because in this Internet age with new things like YouTube, with new things like Twitter, new things like Facebook, LinkedIn - we are able to assemble people that have a similar passion to us and move things forward. If you take that to the workplace and you start doing the same thing, there is lots of unlocked potential there in the workplaces. At Suncorp we use a tool called Yammer for doing that kind of thing. It’s a corporate Twitter type tool and an amazing thing started happening when people started using it.
Of course, it took a little bit of seeding to get started, lots of people dismissed it, they went "I don’t want to know what people ate for breakfast " (the old Twitter line) but over time, useful things started coming here, people started coming back because it was almost like they felt they were missing out the good stuff and wanted to know "how can I get in on that", and it’s about Yammer. So, over time that’s really started to build momentum.Giving people that ability to follow their passion is really a key aspect to building an A-Team.
I think the question I want to answer is "What isn’t an A Team?" They’re the kinds of teams where you feel like you’re stuck in a rut, where you can’t really get things done, you can’t push things to the next level, where you are just doing the same things over and over again and you feel you have no control over your destiny. So an A Team is where a team actually does have that; where you’ve got passionate people who are there and really enjoy what they are doing.
Ask yourself the question when you get out of bed in the morning "Do I really enjoy what I am doing?" if you don’t you’re probably not sitting in an A Team. If you do enjoy what you are doing, then are you actually doing that at your full potential? Are you actually taking things to the next level? Are you learning new things? Are you learning from the people that you work with? Are you enabling the wisdom of the crowd? There is one thing that (a very good book by James Serowski [insert link]) which is about taking the wisdom of all the people that you work with coming with great ideas.
That’s one of the things Agile gives us: the ability to take those people, put them in a room and extract those things out. A Teams do that thing, they say "We need to learn from this person over here and get together and let’s harness that knowledge, let’s get some great ideas, and let’s do it."
The key thing is being able to have a safe to fail environment and that’s really based on the key Agile values. You have to have trust, you have to have honesty, you have to have courage, to have accountability. It’s interesting: I asked lots of people "Are you doing Agile?" they respond "Yes, we’re doing it well" and "Do you have a safe to fail environment?" and they go "ooh, not really." And following on from that question "Why don’t you have that safe to fail environment?" - "We can’t afford to make mistakes." We can’t afford to go off on a track for half a day and come back?" That’s what we are talking about safe to fail; we’re saying "I’ve got a hairbrained scheme - I’m going to timebox this, let’s go and try this for half a day, a day, two days tops of timeboxed activity".
Go off and learn something from it because it’s why we put erasers on the ends of pencils, we’re humans, we make mistakes - the key is to learn from those mistakes. That’s the way that we’re learning, that’s the way that we do good things. Otherwise, if we try to be perfect all the time, we are going to be doing the same old thing and organization will be stuck in a rut.
Firstly, the thing is the difference between managers and leaders. Good organizations have leaders thinking outside of the box and giving your team the potential to do things and do them well. There is an old saying that says that people don’t leave companies they leave leaders, they leave managers and never a truer word was spoken.
So, firstly, if you’ve got people leaving the team, why are they leaving? Is it something you’ve been doing differently, are you not leading them in a way that they are comfortable with? One of the things that Dan Pink found in his book is that motivation is very rarely driven by money. If you pay people money that they are happy with, then throwing more money at them is not the key motivation, it’s actually doing good things. It’s why the open source movement has been so successful: people want to do good things, and share it with the world. You’ve just got to take the money option off the table as long as they are being compensated well enough for what they do, so that they can pay their mortgages, feed their families, then they want to do good things that help people.
If you think about it, the majority of people in the world are good people. So, as leaders, we need to harness that, we need to say "How can we achieve our aims? How can we achieve our vision as an organization but let our people take that vision forward?" Agile is a really good vehicle for this, because we take the micromanagement out of the equation, we say to the people "Have control over your destiny - self organizing teams. We have a problem over here. I need you guys to help solve it and we are all on the journey together."
The other thing for leaders to look out for is the traditional H/R patterns that happen, traditionally we have H/R policies that get in the road of really good things being done. Maybe you have to knock out some of those boundaries. Look at the organizations like Netflix who don’t have a vacation policy. They don’t have a policy for what you wear at work. They have been doing different things.
Atlasian is doing really awesome things in what they call "Fedex days": Every quarter they get people together, they get a day just to do something outside of the ordinary; Google has 20% time. Even looking at performance appraisals, Atlasian is some work now where they’ve essentially thrown performance appraisals out the door. You have the leader and the staff member getting together and saying "Are we doing good things?" Taking the whole "marking" and performance measurement stuff off the table. Thinking outside the square is really the key.
We really need to move towards "management 2.0". Get past the traditional thins that we’ve had in our factories since the early 1900’s generation and deal with the economy we have today - the internet age, generation Y, where people can work anywhere, anytime and have the ability to on really exciting things.