In this episode of Unstoppable Talk, I interview Grant Gibson, President and Founder of Cincinnati based Gibson Agility, an Agile transformation company that helps clients implement Agile practices at scale. Grant has worked as an Agile coach with some of the largest companies in the world – including American Century Investments, Phillips 66, United Technologies, KPMG and the Kroger Co. In this interview, we discuss some of the most important aspects of Agile adoption, what people struggle with when it comes to adopting Agile, and the new arenas and business areas that Agile practices are rapidly gaining acceptance and results in.
Sam Schutte: Okay – so I’m here today with Grant Gibson. Grant is an Agile coach and his company is Gibson Agility. Grant, welcome to the show.
Grant Gibson: Thanks for having me.
Sam Schutte: And we’re going to talk about Agile practices, Agile as it applies to software development and business, and sort of his background and what he does in this space. So maybe a good place to start Grant is, let’s talk a little bit about how you got into this and sort of, your background, where you’re from, and kind of start there.
Grant Gibson: Sure. So grew up in Columbus, a suburb east of Columbus, Ohio, in Reynoldsburg, and went to Ohio University, and got a degree in Geographic Information Systems. What does that mean? A whole lot of spatial analysis, mapping, that kind of thing. I was computer science about halfway through college and then, I got tired of banging my head on the desk because it just didn’t click with me. So somehow I got directed to the Geography Department and my dad kept telling me “do something with computers”. And so I stayed in computers by doing GIS. That then led me to ,right outside of college, worked for a small consulting company in Cincinnati for a couple of years, abouta year and a half, almost two years. And then saw an opportunity to start a business in GIS and mapping and spacial analysis. And so the company evolved into a software as a service company, and I had a software product for contractors.
Grant Gibson: Basically, anybody who sent technicians or individuals out into the field to do work. So, during that time, I had an exit in 2011, I sold my shares, and then I ended up coming across Agile, where I had a customer, a landscape business, a very large landscape company as a customer and their CIO, basically had us build features within our product and then show it to them every couple of weeks. And so that as I grew professionally, I look back on that and said, well wait, I was actually doing Agile before I even knew what it was.
Sam Schutte: Gotcha. Yeah. And we met probably about, I dunno, 15 years ago, I guess, maybe something like that.
New Speaker: Wow. Time flies. Right?
Sam Schutte: Yeah – and were both kind of active in the backpacking and outdoor space and kind of met there. At that time you were running that software company, and I remember thinking, “Oh wow, you own a software company?” Because that was before I had done anything entrepreneurial in the space, really. And so I, I guess what was your process then when you sort of, after you had initially gotten involved with Agile, how did you get trained up from there and get certified to be where you are now, and what are you certified in right now?
Grant Gibson: Yeah. So two parts to that – I’m an Agile coach, AKA Agile transformation coach – but so a couple of different certifications. One is, a SAFE program consultant, SPC IV, SAFE stands for Scaled Agile For Enterprises, It’s a large scale framework for, for large enterprises or organizations that take on Agile, as a delivery method or framework. I’m also a DevOps practitioner, and then also a certified Scrum Master, and then I’ll end up here pretty soon becoming certified in Enterprise Business Agility as well.
Sam Schutte: Okay – and so maybe a good place to start before we dive into some of those areas and sort of what makes those parts unique, for listeners that aren’t super familiar with it, is maybe talk a little bit about the history of Agile. It came up out of the software development space though it’s expanded now to be more broad than that. But maybe we can talk a little bit about traditionally how software development was done, things like waterfall models and then, sort of when that revolution happened to move into Agile.
Grant Gibson: Yeah. So little bit of history there. Where waterfall, started out was in World War II, building warships. So it was: design the entire thing up front and then, get all the way to the end and then basically, I’ll call it, release it or send it out to sea. That was originally where waterfall started. Then it’s of course evolved over time, to be applied to technology and to construction and to many different industries. And then, Agile started, approximately, in the 90s, where some software developers, had come together as kind of a – I call it an unofficial conference of software guys where they were frustrated with their current ways of delivering value essentially and when I say value, meaning delivering working product or delivering software or technology and they said we need to find a better way.
Grant Gibson: And essentially what they wrote was what’s called an Agile manifesto. And you can go to agilemanifesto.org and it’s a set of four values in 12 principles, to where they establish those as kind of the quote unquote guidelines. I call them the guardrails, where these four values are the guard rails. And it’s a way for folks to easily embrace Agile. So for example one is people and interactions over processes and tools, where essentially you want folks interacting as much as possible when it comes to delivering any kind of project or technology or value versus using tools and process to deliver that value. So, of course that’s number one value for the Agile manifesto. If you read deeper into the 12 principles underneath the values where it states, rather than using technology – just email for example, rather than sending somebody an email and asking them a question, why not just if you’re co-located together, why not just get up and walk over and have a face to face conversation. So face to face conversation and interaction is of the utmost importance for the Agile Manifesto and for the folks that created it.
Sam Schutte: It’s interesting because you know, back in the mid nineties and late nineties, or even early two thousands waterfall was really the de facto way of building software, the way you would typically do things is create a lot of documentation essentially, right? And sort of to avoid communication, you’d create documentation. I remember one of the very first projects I worked on, we created a 600 or 800 page design document, a design specification, which said where every button was going to go, what color is every item, and then proceeded to throw two thirds of it away. So you started seeing people say, well, we need, these requirement management systems and all kinds of object modeling tools because we need to document more and capture more detail. That just became overwhelming. And it resulted in sort of a lack of communication because nobody could possibly talk about an 800 page document. So that’s sort of what fed into all that.
Grant Gibson: Yeah. One of the values associated with Agile manifesto hits on documentation specifically. The Agile Manifesto brings to light, the value of not a tremendous amount, but just enough documentation, essentially because, as we all know, things change very quickly. So you might start building something today and in a month requirements might change. And so what changed as soon as you started on Day One? The documentation. So if you’ve spent a tremendous amount of time writing documentation, usually that documentation is not necessarily wrong but different when you get two weeks or a month down the road. And so that’s where a lot of emphasis is placed on. Essentially just in time documentation. A big stereotype about Agile is, “oh, well with Agile you don’t do any documentation”.
Grant Gibson: You just write code. Actually no – you write a tremendous amount of documentation, you just write it as you progress. So for example, when you write a user story, the documentation is in the user story and in the task and in the feature and in the epic. And so when you do that, you have documentation and you’re writing that documentation as you go versus all up front at the beginning.
Sam Schutte: So, so let’s, let’s step back there for a sec. You said tasks, features and epics. So a lot of folks may not know that terminology.
Grant Gibson: Absolutely. So we’d start at the top. So if we think of, over a timeline, an epic is something that is like an initiative essentially. It’s very large in nature. It’s got some high level requirements to it. And then from there, once we start to step down into feature and then the story, and then task, each one is essentially a decomposed component or piece of the one above it.
Grant Gibson: So we start with an epic and then we’ll step down and we’ll say, we’re going to break that epic into smaller chunks and we’re going to say features. And so then features are essentially a means of servicing the epic. If I have a very large initiative or epic where I need to break it down into smaller chunks, I might break that epic down and do five features or 10 features. It just all depends. So the features are a subset. So then once you move down one step further into a user story, user story is essentially in the, in the voice of the user itself. So whatever value or technology or software, whatever you’re building and delivering, that user story is in the voice of the user. So for an example, let’s say, I’m building an online bookstore.
Grant Gibson: If I’m building an online bookstore, one way to build out a feature, let’s say a feature within that bookstore might be, I want to be able to pay for my books using credit cards. So that could be a feature. And from within that feature, then we need to be able to say, okay, here’s a software team. Go build this feature of paying for books with credit cards. What are the small things that we need to do as a team in this, in the voice of the user. So as a user, I want to be able to select a book and, and put it in my check and my shopping cart. Right? And so once I progress out of my shopping cart, it could be, let’s even drill it down even further and say, I want to be able to select American Express as a payment method.
Grant Gibson: So as a user, as an online bookstore customer, I want to be able to select American Express as a method of payment so that I can pay for my credit card and get points, maybe it’s an Amex points card. So that’s how it’s written out. And then from there within that user story of selecting American Express that’s in the voice of the user, then there’s tasks associated with each individual user story. And so task are essentially, okay, what are the things that the software developer needs to do in order to deliver that user story of selecting American Express as the payment method. So a software developer would go through and task out that user story. He’s got to write certain code to be able to display American Express. He’s got to connect to maybe a payment portal of some sort, so on and so forth. So he’s going to list out all the different tasks. And so now when you look at the user story itself and the tasks associated with it, that’s the documentation right there. So back to your point earlier about documentation, the documentation was written just in time, and that’s an example of an epic, user story and a task.
Sam Schutte: Yeah – because there’s really no greater nightmare in my career that I’ve had than taking every little bullet point out of a 800 page document, and having to paste it into a Microsoft project plan back in the day. And then trying to keep those things in sync. It’s like we’ve got to change it in both places. At certain point it gets kind of crazy. Now one thing that I do, when we’re doing an Agile project, and I think a kind of a critical thing to all of this is, you have to handle change. You have to anticipate change and you have to sort of limit your exposure to change. And I think part of that is sort of limiting the time duration of the projects and the size of those epics. It used to be, you might say we’re an insurance company, we’re going to create a new claims processing system and it’s a seven year project.
Sam Schutte: You would just never do that. I mean, cause what can you possibly think you’re going to have to deal with from a requirements standpoint feature, you know, and all that stuff in say the year 2017, seven years later are just not going to be anywhere remotely accurate. So how do companies – and I think that’s something when we’re dealing with clients is helping them understand like, look, don’t try to, we understand that what you really want is going to take 18 months or two years or whatever, but we’re not going to try to bite that off yet because it’s too unclear and we’re, and we don’t understand it well enough. So how do you kinda work with clients to help them limit that scope to what’s sort of more achievable or safe? You know, what’s a safe, epic size?
Grant Gibson: Yes well epics typically can be a year or a couple of years, but that can be for the entire project. So if we, if we equate a project to an epic, yeah. Because I get asked that question all the time. Well, you told me what an epic is, but where does the project fit? Well, okay, we can make it some weeks and we can make some analogies or equivalencies essentially where, let’s just say that a project is an epic, right? It’s going to take a year, it’s going to take 12 months. One of the things that I coach and mentor my clients on is, so you have this project that you want to do well, let’s make sure that we’re building the right thing for the end user or the customer. Let’s get the feedback early and often.
Grant Gibson: So within a feature, you right, that remember, we talked about it a second ago, was with right underneath that epic is those features and that’s how we’re going to break down the work. So within a feature, for example, back to the bookstore example, the online bookstore, within that, a feature is I want to be able to use credit cards to pay for books online. So within that feature, it needs to be defined. So that you’re not only timeboxing the epic, let’s say it’s 12 months. So then we’re going to also time box the feature. And so within that, feature of paying for books online with a credit card, we might estimate that it’s going to take three months. I use the rule of thumb that Agile, a scaled Agile recommends is three months for a feature – time box it to three months because you want to be able to start something, work it and deliver it, put it out to the customer and get feedback.
Grant Gibson: Because otherwise if you just work on something in perpetuity, meaning, okay, well now we need to change this and change that and change this. I recommend that, let’s not only think about what the customer wants, let’s try to be prescriptive. Let’s actually build something small, the smallest unit of value and then put it out in front of the customer and then get their feedback. So again, within that feature, there should be very well defined and then also a time box of how long it’s going to take and no more than three months for each feature. And then back to your point, about 12 months or so for an epic, I mean you can go over that, but if you go over 12 months with an epic, it, it typically can get out of control.
Sam Schutte: Yeah. You mentioned value driven and something we try to do on projects is be value driven, basically on our project planning. And essentially what that means is try to deliver the most valuable features first. And I think that’s a process we have to often educate clients on a bit is what’s needed when, you know, and so if you can have a release to production, say of a system that they can use but perhaps doesn’t include any reporting, let’s say, well, they don’t have any data yet. So what are the reports needed for exactly? It’s a simple example, but why delay customers and users getting in there giving you feedback, really using it because you want 30-40 reports written on an empty database. That’s something that probably back in the day you would never have released it. You couldn’t really, release something to production unless it had everything and was completed. They would’ve said, well, what about reports, you know, and you might’ve even done reports first. Maybe you had a junior developer in parallel and it just would have slowed everything down. So, I think some of it is being very strategic about, you know, it’s not just sort of estimating tasks and the size of things, but also how do they really fit into the business plan and what can you digest when.
Grant Gibson: Exactly. And that to your point right there, and I’m glad you brought that up because it, it hits on planning, right? A lot of folks, there’s a stereotype type of at, “Oh, when you’re Agile, you don’t do any planning”, which is truly the opposite. One of the things that I emphasize regularly is when, for example, a client of mine recently, had a very large initiative that they anticipated would take about three years to build. And I said, well, do you have any kind of roadmap? Have you done any kind of estimating? Have you done any planning now? And they said, well, no, we have an idea of kind of what we want to build, but we don’t need to do any planning right now. And I said, well, that’s actually not the case. You need to be planning. And when I talk about starting a new initiative like this multi year initiative I said, you need to be doing a lot of planning, not only from a roadmap perspective of kind of what we’re going to be doing for the next 12 to 18 months and then let’s lock in what we’re gonna do for the next quarter or two of what we’re going to do and build.
Grant Gibson: And so you can do a lot of estimating on, on, on delivering software or technology or even non it related projects where you can estimate it, but then also plan out, okay, what is it going to take? And when I talk about planning, I talk about what dependencies do we have. I mean that’s one of the most overlooked, areas, when it comes to any kind of project within an organization where it’s, okay, well, we’ve got this data and we’ve got some software developers and, but is there a dependency on, for example, in software itself, delivery of software products? What if we have a dependency on a security team or if you have dependency on, compliance or legal, or does legal have to sign off on it because there are certain compliance rules? If you’re regulated by the federal government, with any of those agencies, the SEC or, energy or whatever, I mean, any of those financial and specifically energy – those are heavily regulated industries. And if there’s certain things that you’re allowed to do and not allowed to do, where there can be fines associated with being out of compliance, well, if you don’t do that planning ahead of time, what if you have a dependency on, for example, the IRS if you’re a financial company, right? So those are some major things that are very overlooked by all sizes of organizations that they just, they failed to do a lot of preplanning or planning ahead before they even start the execution of the work.
Sam Schutte: So, beyond that, what are some other areas that companies fall short on or problems that they have that keep them from getting the benefits of Agile? What are some of the other wrong approaches that, folks tend to underestimate or miss out on?
Grant Gibson: So a couple parts to that. You’ve got autonomy, autonomy is essential where its letting the people do the work. What comes with that is trust. I always say to the clients that I work with, let the people plan the work, do the work, give them the guidance on the things that you’re thinking from a leadership perspective, of here’s kind of what we want to do or what we’re thinking for the customer. Go talk to the customer, make sure it makes sense. But trust the people that do the work. Get out of their way, give them the autonomy that they need to do their work. But then also, not being half in half out where it’s, “oh, we want to kind of try this Agile thing and we want to see how it goes”.
Grant Gibson: It’s great to do a pilot internally with a couple of teams maybe or whatever the size of your organization is, but don’t be half in half out. It works for all size organizations across the United States and globally, whether you’re a one to 10 person business or if you’re 100,000 people strong within an organization, be all in, be committed, but then also get leadership buy in. If you’ve ever seen the sticker a lot of software developers have on their laptops, that says “culture eats strategy for breakfast”. I’ve seen that time and time again where, leadership will say, oh, it’s a homegrown, it’s a grassroots kind of thing. We’re going to let the people do it. But if people at the top or the leadership aren’t drinking the Kool-aid, so to speak, and if they’re not preaching and, saying, look, we are Agile, we are going to do this thing and we’re 100% committed from a leadership perspective. If that’s not there and they’re not telling the people that, then the, the culture is not going to buy in there. They’re going to find every reason to fight it. But I think those are the, those are the three things that I see on a regular basis is the autonomy, the trust and then having leadership buy in.
Sam Schutte: Well, it’s interesting cause you know, I think when, Agile first started up, way back when, there was a lot of resistance from more corporate IT and just other bigger companies that said, well, I mean, yeah, that’s, a fun thing for startups. When you’re burning venture capital and there’s no real budgets and you’re just having fun and you’re down there with your, table tennis in the office and you’re doing Agile or something. Right? And, but what we’ve seen is, you know, the proof is in the pudding because the rate of failure of software development projects and, sort of, if you look at all the statistics about, return on investment on all of these things have all drastically increased since Agile has taken off in the enterprise.
Sam Schutte: To the point that, more and more projects outside of software development, are utilizing the Agile framework and Agile practices to be successful. And I know, we’ve talked a little bit about, for instance, data science projects where you’re not writing code, but you’re working with data. Also, projects that are just simply business-related projects that have nothing to do with technology. Or a construction project, and, and other, areas where they’re pulling that in. There was an article in the Harvard Business Review recently talking about applying Agile practices to non-software development departments.So maybe you can talk a little bit about how that works. One challenge, if I can give a specific example that we sometimes see is if we’re working with, say like an industrial manufacturing company, where we’re building a system that’s going to be used against a, some new manufacturing line or some new product of some kind. Well that product or that assembly line or whatever it is, it has it’s own project plan. How do you sync up software to real world? And how does that work on non software projects?
Grant Gibson: Yeah. So right now, one of my current clients, I’ve worked directly with, a team that is a, I’ll call it a non IT team. Essentially this team provides, a service, it’s an enablement team, is what I call it, where this team provides visualization and analytics training, to users all across the organization. So there’s no building of software product. There’s no code. There’s nothing associated with that. They essentially have technical coaches. They have trainers. They have a couple of people that write content. What they are building is a community of analytics and visualization, across this organization. To where it’s this team’s responsibility to visit locations all across the US and train folks, answer questions, and create what they call use cases for basically justifying the need for visualization and analytics software that this team trains on.
Grant Gibson: So to the point of how do you approach that, where the best approach is, essentially, as I mentioned earlier, where you’re taking something that is, say for example, large in nature of this entire enablement team, right? It’s their responsibility to go out, create this community of users of this visualization and analytics software. Train them, provide support, provide, you name it, to where it’s essentially, for example, one is when they go and visit these locations across the US they say, okay, we’ve got to visit this location and we’ve got to provide training to 80 people, and support. So they go and they break down each location as a feature. So this location they go and they train 80 people. So there’s logistics, there’s getting the training room set up, there’s the licensing for the software, the visualization and analytics software.
Grant Gibson: There’s all these different things associated with visiting this site. And so each person on the team is responsible for certain parts and pieces of this feature. And so when we go into sprint or iteration planning, a sprint or an iteration is just a way of timeboxing in Agile. So with this team, they time box for two weeks. And so when we go into planning, they essentially break down, okay, what the things that I need to do or deliver, what value do I need to deliver it in, in order to make sure that we deliver this site training, location training for these users, by this certain date. And so they break down all the things that they need to do, in user stories and in tasks. But, from a higher level perspective, they break down, they’ve done roadmapping, to where they have an idea of what they’re doing for the next three months, for the next quarter, but then they also have an idea of what they’re going to be doing, approximately what they’d like to do over the next six months.
Grant Gibson: And so from there, then that team takes that information from the roadmap and then breaks it down a little bit further from the feature level on the roadmap. But then breaking it down into user stories and tasks at the, at the every two weeks. It can be done with non it. I’ve worked with like it just mentioned this training enablement team. I’ve done it with compliance, legal, I’ve done it with tax and accounting. Where of course analytics is becoming a very important thing across, a lot of organizations and industries where we’ve got all this data and we’ve got all this stuff that can give us insights into what we should do next or what the trends look like currently or maybe even forecast. So it can be applied. I’ve worked with marketing teams as well to where, again, it just comes down to the context of the team and, or the set of teams and, and the type of value or work that they deliver.
Sam Schutte: But it sounds like in general, you know, for, folks going out and, and trying to deliver some kind of value in a two week time box, they’re going kind of all over the organization to do that. It’s going to be, easier probably with a smaller team, right? I mean, within a large organization. And I think, and I’ve read some case studies, for instance, I think companies like 3M that said, hey, we’re going to go and create, you know, a 20 or 30 or 50 of these little teams and give them some innovative tasks to do. And, it just kind of a large collection of small teams allows them to be more Agile, and just react to change quicker as, as an organization. But then there’s also this concept of scaled Agile when you have large teams, and I know there’s, there’s, some clients you’ve worked with that have hundreds of developers all sort of working on projects. I believe that they’re doing more of that scaled approach. So what are the key differences there? Sort of a compared to a smaller team?
Grant Gibson: Yeah. So, typical rule of thumb for a single Agile team, I’ll start here is, rule of thumb is you want a team size of what you can feed with two large pizzas. Where when you get into scaled Agile, you have a a or a scenario where, you can have, as you mentioned before, like hundreds of developers and to where there are numerous dependencies on the different teams, upon with each other. So for example, I’ve worked with a client in the past where they had, hundreds of developers and there were dependencies on, um, one team to another because one team couldn’t finish their work and less than another team finished their work. So dependencies are obviously very important when it comes to scaled Agile. But, it not only comes down to dependencies, but it also comes down to, creating a very well defined roadmaps and to include features.
Grant Gibson: You have typically sometimes and sometimes not. In the last client I worked with, when I started working with them and I said, well, do you have any product managers? And they said, well, sure, we’ve got product managers, but they’re a different type of product. They’re financial product managers. And I said, no, let’s talk about technology. Let’s talk about the products that you are building internally that you own. And that there’s a team that’s responsible for owning that team, or owning that product. And to where I set up a product management structure where there were individuals that their sole responsibility, and this comes along with being scaled Agile, is you have product managers that are responsible for being the eyes and ears with the, on the outward facing towards a customer. And so, or the end user to where they go interact with the customer or the end user and say, what do you need?
Grant Gibson: What do you like, what don’t you like? And taking that information and translating it into features so that a software development team can look at that well-defined feature and say, okay, we know what we need to build next. And so that product managers not only helping build along with the leadership division and then helping execute that vision at that feature level, but then they’re also interacting and being the eyes and ears of the business to say, okay, what does the customer want next? That’s one big difference. A few more differences, is when you have numerous teams, um, you can create essentially what scaled Agile refers to as value streams. Value streams are essentially a, it’s a, it’s a team of teams. You could have approximately 50 to 125 individuals on a, on a value stream, to where, there might be, if you say there’s approximately six to eight people on each team, you’ve got a fairly large, value stream or number of teams associated with that value stream.
Grant Gibson: And so when I talk about value stream, it’s the organization looks at what streams do we provide of value to either our customer end user both internally and externally. And so you could have a, a value stream that builds, for example, nothing but analytics technology or PR or software products within an organization, to where there are other teams or value streams that are dependent on that analytics. So again, it really comes down to, comes down to the number of people that you have within the organization, but also, the types of dependencies that you have as well. It’s not a one size shoe fits all kind of thing. It is definitely a, it takes some time to get there. I’m of the belief that, you make the team strong Agile practitioners first and then you introduce scaled Agile because if you don’t get the basics right, you’re, you’re not going to be able to scale.
Sam Schutte: So if you think about a company like Google for instance, they might have, you might say one of their value streams is, the android operating system, another is their search engine, but each utilize each other. I mean, the search engine uses data that comes off that android passes to it based on your usage and such. And of course, android uses the search engine all over the place, but those are distinct teams but, they have those dependencies. They’re very large teams I’m sure, I don’t know exact numbers, but I’m sure it’s hundreds of developers on each of those obviously. And, and coordinating the product vision with all of them is kind of what drives them. Now you mentioned, and we’ve talked about this a little bit before, you know, product managers, project managers, and Agile coaches when you’re embedded within a company. What are the distinct definitions of those three? What’s a project manager versus Agile coach versus a product manager?
Grant Gibson: Yeah. So, as I mentioned before, I’ll start with the easy one, the product managers, the, the eyes and ears of the, of the business associated with working with the customer, the end user, where they’re taking that information and the feedback that they get from the end user or the customer and saying, okay, I need to take that and translate that into features or something that can be digested by a software team and turn that into workable product. Project manager – that’s a tricky one these days because there’s a lot of, a lot of organizations will ask for a project manager with Agile experience. I’m not saying it can’t be done, there is a place for project managers, sometimes not always necessary in the scaled Agile environment, but, when you get into different settings, you have a project manager who is responsible for, more so on the financial side when you have projects.
Grant Gibson: When we think about scaled Agile and value streams, you’re essentially feeding that value stream work continuously. You have continuous flow. And so if you have continuous flow, you already know your financial, you already know your financial run rate of what it costs for having x number of people on that value stream. So the project manager is kind of removed from that picture. But then when you have individual projects with, for example, one of the clients that I work with right now, very project manager centric, they are currently training their project managers on Agile, and providing some certification classes. But at the same time, the difference again with the project manager is in the name right? They manage projects, but with Agile, as a project manager, you don’t manage the team. The project manager manages the financial side of the project.
Grant Gibson: Again comes back to autonomy, right? The team should be able to decide what they’re doing and when, as long as they’re meeting the goals associated with here’s what we’ve got to do and here’s kind of the timeframe that’s established by leadership. So, again, they’re looking more on the, kind of on the metrics and the reporting side and the financial side of it. Right. Are they in budget? Are they over budget? Are they this, are they that? But not necessarily in the daily operation of the team. So, yeah, you know, the product manager’s going to advocate for what the customer actually wanted. That’s who their boss is, the customer.
Sam Schutte: Generally, the project manager is supposed to be accountable to the bean counters, but the coach is supposed to advocate for the process.
Grant Gibson: Yeah, and so I didn’t touch on that one. The Agile coach is there to, as I mentioned before, one of the things that I say is let’s make the team of the teams strong Agile practitioners. Another thing I always recommend is if you’re considering Agile, hire a coach because, while there’s expense to having a consultant come in and provide that level of expertise, the last couple of clients that I’ve been with, it’s always, well, we tried it on our own and it didn’t go too well, and now you’re here.
Grant Gibson: And it’s typically the case, because the Agile coach is the mentor, of course the coach, but then they’re also the trainer and they’re also the guiding light associated with Agile. Thye say, here are the guardrails. We, we can let you can bounce around all you want, but as soon as you drive outside those guardrails and start plowing corn, as a coach, I’m going to pull you back to the center of the road. So again, with a coach, that’s their sole responsibility. I’ve talked to all different types of recruiters when it comes to how do I write a job posting for a scrum master or a product owner or whatever it may be. And, and then we end up getting into the conversation of, well, how long are you here? And I’m like, until I work myself out of a job.
Grant Gibson: And with the coach, that is the purpose. You’re there to coach and help. But then once there’s strong practitioners of Agile and the teams are on their way to become a quote unquote high performing team, then my job as a coach is to leave and to get out of the way. Back to that autonomy thing. Again, that’s the role of the coach is to help provide a lot of expertise and answer a lot of questions around, well what about this? Or how do I do that? Or we tried it this way in the past and it was really awful. Well what do you recommend? And so there’s always somebody to go and talk to outside of just the training and the guidance. There’s somebody there that can provide examples from other industries, other organizations as well.
Sam Schutte: Well and probably kind of hold everybody accountable. Cause I think, you know, any kind of process, Agile or not, when things get rough and something bad happens or you just, there’s a time crunch money problem, whatever the issue is, that’s when everybody abandons everything and you’re just like, just ship it. Just start hacking, you know, stuff and, and uh, don’t write anything down, just pound out code – and developers are probably some of the worst. Definitely some can be some of the worst sort of offenders of that because, if you want your developers to track their time and a time ticketing system and you want them to enter bugs in the bug database and, close user stories out in whatever, if you say, hey, guess what, you’re halfway done with the project. There’s a hundred hours of work and it has to be done in the next three days. They’re going to dump all that and they’re not going to be in there. And so, it’s like, somebody has to advocate and say, wait a minute – I thought we said were going to do things the right way.
Grant Gibson: Yeah. Not only that, to that point where my job as an Agile coach is to help set the stage so that kind of thing doesn’t happen. So let’s make sure that there’s good planning upfront when we’re building out the features, and then once those features are well-defined and estimated, then we hand those off to the teams and say, okay, here team, this is what we need to build. Let’s do the, let’s plan out the user stories and the tasks to where sure, there’s going to be some back and forth and some questions asked, but at the same time, my goal as a coach is to make sure that those things don’t happen where it’s we’re in crunch time, just forget about everything else and let’s grind it out and get it done. Well, unfortunately, usually what happens in those scenarios, as you probably know firsthand, Sam, is you grind it out and then guess what? You release it and then all of a sudden it comes back and it’s full of bugs. Right. Because we cut corners, we did this and we did that. And one of the famous sayings that, I always go back to what my manager at one of my clients said, that in the past, this organization did a lot of duct tape and bubblegum and we’re at a point now where we cannot support those applications that have been built with duct tape and bubblegum.
Grant Gibson: And it was like, okay, we did it, we got it done and we checked the box and it’s done. Now we can move on. But then guess what? They’re being told now that, well, we can’t do anything with that other app. That application that was built with duct tape and bubble gum because it’s, it bombs out all the time. You have to babysit it. It creates support tickets all the time.
Sam Schutte: You’ve accumulated technical debt on it, which you have to pay off eventually. And you know, there were many times early in my career as a developer that you’d be in there writing code at 4:00 AM and you come in the next morning and are like, what was I doing here? Because invariably those sort of problems that would occur that are the types of problems that companies want to avoid and they, and that claim, that’s why they want to do Agile, always happen because something that Agile would’ve prevented in the process was skipped. Like I remember, there’s a project I worked on once that we, our whole team estimated, you know, nine months. It was like maybe September and we said nine months, it was our estimate when we started working.
Sam Schutte: We found out somewhere that up the chain somebody told the CEO that we’d be done by 12/31. None of us ever said that. And it’s like, where are you getting that from? And they didn’t tell us – that date did not become public knowledge until the end of November. And it’s like, who gave them the date? It was just made up, you know? And with process and transparency and communication and technology where anyone can go in, add up the estimates and see that it equals 12,000 hours for instance, that shouldn’t happen.
Grant Gibson: Good point. I have a session where I call it model storming. Basically, I have a team that’s responsible for building a feature and I have them estimate it at the high level and we spend 60 minutes doing it no more, no less 60 minutes. We estimate the feature. And then when they leave within the next couple of days, I have management or leadership or whoever’s in in has a voice of saying, okay, yeah, let’s do this feature. Let’s build this thing. I have them come in and say, Hey, look, you remember that previous estimate of, of basically 300 hours that somebody put together, well, we just came up with like 4,000 hours. And you can see here’s all the things and we draw it out on a whiteboard. And I’ve had managers sit there and be like, I had no idea, no idea that this was, it was this involved.
Grant Gibson: And I say, okay, well now you’ve seen it. What are some things that are part of your minimum viable product? Right? MVP. And they said, well, okay, carve that off. Carve this off, carve that off. Okay, that’s what we can live with to get it out by the deadline that’s expected. Okay, great. The other things will come later. We’ll put it off on the side for now. We’ll work on these things. And then what we get is agreement and from not only management and at the director level and sometimes leadership as well, further up the chain where it’s, okay, you see what it’s going to take. This is estimated by the actual team who’s going to do the work. You’re all in agreement on it. Okay. We all shake hands and say, okay, we’ll go to work and do it. And so that’s one of the big things that I see on a regular basis is that, like you said earlier of Oh, you got down the road and then all of a sudden you found out that there was this make, oh, I call it make believe deadline, right. They pull it leadership, pulled it out of thin air and then communicated it around the organization and it’s, Oh, no, well, we can’t get that done. Then it becomes, I don’t care what it takes, get it done.
Sam Schutte: And like, yeah, but you’re gonna end up with garbage. And you know, of course that it always goes back to the whole nine women can’t have a baby in one month type thing. You know, all those kinds of classic examples. On the other side of that coin, I guess, I think something that I’ve heard, executives and stuff gripe about or complain about is, you know, if you say, look, you know, developers give us the estimates and we’ll trust you and all these things. Some developers will sort of use that, in an maybe unethical way. And what you hear is the gripe is like, they’re trying to create a country club around here. Right? Back in the day, I remember, my dad was managing software development at a local company here and because he had low turnover and happy employees, he would get accused of, of running a country club.
Sam Schutte: You ought to be having people quitting. You gotta have people, you know, like how can people be so happy? So imagine if you had an Agile team and the developer just decides to make, give everything a hundred hour estimate. Like, yeah, you want estimates, I’ll give you estimates. I mean, that’s, you don’t have to have Agile to have that problem, I guess. But I think that sometimes is the perception is like, oh, all these whiny software developers that just want like an easy job where there’s no deadlines and they never have to work till four in the morning. Where do you meet in the middle on that where, it’s not too easy?
Grant Gibson: So I think that that’s an easy one. So for me at least, where it all comes down to is good facilitation from an Agile coach and it’s not, it’s like you mentioned before, it’s more than just Agile. It’s about bringing the individuals together. I’ve had to tell C-level executives that, look, it’s fine that you came up with a deadline on your own, but you can’t guarantee or promise deadlines when you didn’t even ask the people that do the work, does this deadline work? Because if you don’t do that, you just might as well throw it out the window. So my point being there is if one thing that you can do is one have good strong facilitation and it can also come from a scrum master as well on a team where it’s, that’s a part of their role is a facilitator where you have a essentially a team that says, okay, it’s going to be a hundred hours.
Grant Gibson: I always like to pry as much as I can without being offensive to the point where it’s okay, will you tell me a hundred hours? Let’s talk about this. Tell me all the different things, the parts and pieces and the moving parts and, and do you have one of the parts of, one of the components of this model storm session that I mentioned earlier when it comes to estimating is, is there any compliance, is there any security related dependencies? What questions do you have? What assumptions do you have? And when it comes down to risk, it’s okay. What things are you risking here? If you do things a certain way, right? So if you choose one path versus another, what are those? Look like, okay, if you’re going to tell me it’s you’re going to build it using x, but then it, it could take you 20 hours, but then if you choose y and it’ll take you 40 hours, twice the amount, but why is risky than, okay, let’s provide the estimate on both sides of the coin, right?
Grant Gibson: Meaning let’s show the high level, the higher estimate and even the lower estimate and I like to, I provide that as well when it comes to facilitating a session like that. But to your point of how can you really keep just a team from saying, oh, it’s just a hundred it’s a, it’s a hundred hours worth of work. It’s all about good facilitation of that estimating session. It comes down to getting the interaction between the two, meaning the team and then management or leadership or whoever and saying, okay, and putting them together in the same room and letting leadership and management hear it. Because then the team says, well, they must care because they’re in here. And when you bring the team, and the, and I hear it on regular basis is bringing it in the business together. When you do that and they hear each other out, it’s, Oh wow, I didn’t know you had to do this, this, this and this, and Oh, it is more complicated. Or from a team perspective, it’s, Oh, you said that, but you really mean something else. Oh, well then you can shave 20% of the time off. Right? So when you put them together in the same room, then during a session like that and an estimating session, it really breaks down those walls of, Oh, you’re the business and Oh, you’re IT.
Sam Schutte: Well, I think also, as a coach providing options and solutions that are creative that they might not think of, right? Because developers tend to sort of get a little boxed in sometimes in their perspective, but if you can provide solutions, sort of adhering to certain values. So say like a risk mitigation, which is a big one I preach on a lot. I think in just our projects, you know, it’s completely true that if you ask a developer to estimate something that he doesn’t have any background in that the new thing or maybe no one has ever really done because as developers that’s, that’s one of the cool things is you often are asked to do things that no one period has ever done. Right. Because it can be globally unique sometimes.
Sam Schutte: Which is cool. Um, but so they might say, well it could take me a day or three months. I don’t know. Like I don’t know how hard this is because I don’t know if for instance, let’s say you want to interface with some API, well does it support it? I don’t know. Or if it doesn’t support it then I’m going to have to like screen scrape it. And do all kinds of crazy hacking.And so, you know, I remember one example we had on a project, we were building something that needed a sort of like some collision detection of being able to move a piece of equipment inside the boundaries of a room on, you know, on the screen within this sort of a web app. We built, well the developer had never done anything with collision detected detection and boundary detection.
Sam Schutte: And I said, okay, here’s what you’re going to do. You’re going to go write Tetris. You’re going to go make a little tetris in Silverlight. This was back, on a Silverlight project. Because how do you do boundary detection in Silverlight, we didn’t know, there wasn’t much documentation on it. So he spent like two weeks or a week and created this little mini, very light scale tetris that did everything. It was a prototype, you know, that did everything you would need. Because you know, bars and stuff could bounce off walls and, and they had to be limited. And that took a week. And then after that he was able to really estimate what the true functionality would take, which was a much higher degree of accuracy. But before I sort of suggested that, or before a coach or anybody suggests that they might just not even know what to do and what are they empowered to do, and management is not going to think of that probably. So some of it is, you know, come up with those solutions I think.
Sam Schutte: So you’ve talked a little bit about some of the coaching you provide and I know you’ve traveled all over and been a road warrior providing coaching to companies on the east coast and a lot of different places in the country. What do some of those courses look like? What are the levels, you know, if someone wanted to dive into Agile, because you can certify everyone, you’re licensed to certify people in all these different Agile, skills and trainings. What’s that pathway look like? Where would you get started?
Grant Gibson: Yeah, so I would recommend, going out to like a scrumalliance.org and looking at their offerings. They do Certifications and scrum master and product owner. And, so when we talk about Agile, if we think about it being an umbrella, and then under that umbrella are subsets of Agile. So methods of delivery. So for example, Scrum is one. Scrum is great for planned work. Kanban is great for emerging work. And then also you have scaled Agile as I mentioned before. You have XP, which is extreme programming and then there’s others – scrum at scale. And then you have LES, which is large enterprise, Scrum. And so you have all these different frameworks, but again, you have scrumalliance.org is a good place to get started, to kind of check out what their offerings are when it comes to scrum master and product owner. Um, and then also you can go out and look at scaledAgileframework.com which is another good resource, because when you go to that website, they talk specifically about scaled Agile and their offerings from a training perspective, but then, who they are and who they’ve worked for and their white papers and their case studies. So for example, you can click on iteration and it’ll take you to iteration and it’ll define what an iteration might be and how it is used and how it’s involved in Agile and in scrum. But then also you can click on something like feature or epic and it defines it.
Grant Gibson: So very resourceful, great resource when it comes to learning about that framework.And there’s other ways as well. But again, scrum alliance and then there’s a couple of the ones out there, similar to scrum alliance, you can go out and look up their training schedule and get certified.
Sam Schutte: So folks can also go to your website, which is just Gibsonagility.com, and you have a number of packages and offerings on there, that people could read up and find more information on.
Grant Gibson: Yeah, so I offer a couple of different things. One is kind of an assessment where I can come in and help get an idea of where you’re at with Agile, and then obviously create an assessment and then make recommendations on kind of what’s next. But then I can also look at, take it one step further and look at transformation as far as, okay, what’s it going to take to actually implement Agile? So it’s kind of progressed. It’s kind of a sequential type offering.
Grant Gibson: But then, of course I am certified to teach a variety of classes. Everything from Agile overview, scrum and Kanban overview, and devops. I do a variety of, roadmapping and basically taking a project from inception all the way to completion using Agile. Another thing I often get is, well I just need a single project to go through Agile so I can prove it. So I do offer that and then of course obviously just being an Agile coach onsite – I can come in and provide coaching as well.
Sam Schutte: So also if people mention, if they go to your website and reach out to you about these packages and mention the keyword “UNSTOPPABLE”, they’ll get a discount on some of those services you can provide as well. So great – well thanks for coming on the show. We appreciate you coming and talking to us about Agile and scaled Agile and all this sort of stuff. We hope we can have you on some time again to talk more. Like I said, if you want to check out Grant’s website, it’s Gibsonagility.com, and you can check out our website, unstoppablesoftware.com and we appreciate you all for listening.
Grant Gibson: Yeah. Thanks for having me, Sam.
Sam Schutte: Sure, no problem.