Foundational Engineering Practices for Agile


We chat with SolutionsIQ’s Dave Wylie, a seasoned consultant, manager and developer with 35 years of experience. Wylie wants to make sure that, while Agile has expanded beyond IT, people especially in IT remember that good engineering practices are foundational for a successful Agile transformation. Agile software development approaches, techniques and mindsets are drivers for business value and make it possible for Product Owners to ship when they’re ready to ship.

Wylie argues that foundational development practices – writing tests as well as reviewing, integrating and continuously improving code – are important for everybody. Unfortunately, according to Wylie, ”There’s lots and lots of people in the software development world that [have] had zero formal training or informal training or mentorship on these practices.”

Howard Sublett hosts.

Listen on iTunes >

Read the full transcript

Howard Sublett:  Thank you for joining me for another episode of Agile Amped. I’m your host, Howard Sublett and in today show we’re going to talk about foundational engineering practices for Agile. We’ve just had a lot of requests from listeners on topics just like this and this isn’t my strong suit. For this episode, for this topic I’ve asked the one and only Dave Wiley to join me.

Now, Dave is an experienced Agile manager and coach. Using Agile principles and practices he collaborates with customers on prioritization, compliance planning, risk management, Agile engineering and ongoing enhancements to systems. He also is an instructor and coach for Product Owner and Scrum Master training and workshops on user story development, release planning and starting new teams. He has worked extensively with delivery teams using XP practices to deliver high value, high quality teams. Dave, thanks so much for joining me today.

Dave Wylie: Thank you Howard, I appreciate that. That’s almost like an introduction I wrote for myself.

Howard Sublett: It sounds very familiar to the words that you sent me in all transparency. By the way, how many years have you been doing have you been doing this, working with teams and XP systems and stuff like that?

Dave Wylie: I’ve been working with teams and systems for 33 years. I’ve been doing Agile stuff for about 15 years. I’ve been lucky enough to work with the great group of men and women that have delivered systems value for customers. I like to say I’ve taken credit for all their work.

Howard Sublett: Well, I just wanted the audience to actually know that this isn’t your first week on the job. I think you are you’re well suited for foundational engineering practices for Agile. Why would you think that this topic is important? So, why this topic now?

Dave Wylie: Sure. I have a lot of sympathy and empathy for developers. Developers, testers, tech writers, SysOps folks, DBAs and there’s a lot of energy in our industry right now about things above and beyond. Agile is really going beyond IT. It’s hitting other functions within the business. It’s hitting the mainstream in books like The Startup Way and The Agile Organization and I want to make sure that, especially for IT people to remember, that foundational, to anything before we hit scaling, we need to make sure that we have good engineering practices that provide business value on a regular basis and allow our Product Owner people to ship when they’re ready to ship.
We are organization that helps people with skilled frameworks like SAFe and LeSS and lots of energy going out in big companies right now on how do we scale this? How do we hit large programs impacting thousands of people? Which is entirely awesome because we want to help people get better and figure out how to compete, because really this is all about business success. Even though it’s a technical topic, it’s really about how do we help our business partners succeed and these practices are so important to them, and oftentimes they’re overlooked. In my experience we often see organizations say, “Well, let’s go train our project managers to be Scrum Masters.” Or, “Let’s help our Product Owners to be able to think about problems differently using design thinking or other approaches, things like innovation games to solicit input and split up work.” Which is all good stuff, but unless you have a capability that allows you to deliver on this short cycle basis, the organization’s not going to get the benefit that it otherwise deserves.

Howard Sublett: Right. I think we’ve seen that too. I want to back up just to make sure that people in the audience actually understands because if you’re not a developer, if you’re not somebody that’s been in the world of writing code, a phrase like foundational engineering practices may sound like we understand what it is, but what would you consider just a foundational engineering practice for development team?

Dave Wylie: Absolutely. We’ve known for a long time before Agile was even named, that there are good practices the development team should do. They should test their code, they should review their code, they should integrate with other teams building programs, they should work with the business and make sure that we’re building the right thing. It’s our responsibility, as developers, to build the thing right, but we need to work with people to help us get feedback on those things. We are become stewards of this asset, this codebase. As somebody, a smart person, said, “Every company is really a software company anymore.” Whether you collect garbage or you’re doing sewer treatment or you’re a nonprofit or you’re the military, everybody has a huge software component of what they do.
These practices that the people do, and it’s not just writing code, there’s other components of it, are done by most organizations. Those foundational practices that I just described, writing test, reviewing code, integrating the code, making the code better, are important for everybody. We often say, one of my colleagues says, “Who’s responsible for maintaining and not degrading this corporate asset that we’re creating?” We’re spending such a huge percentage of corporate budgets on the software. Guess what? The quality of that asset, the building of that asset to meet current needs and be ready for future needs, that’s in the hands of these delivery teams and so we need to make sure that we’re giving the delivery team direction and guidance and training and support to make sure that this asset is both enhanced and extended and not degraded and eroded.

Howard Sublett: Let me ask the maybe an obnoxious question in this, but if this is something that’s been around 19 years or so and I’m somebody that doesn’t write code, why isn’t this just the way that they do it? I mean, why wouldn’t somebody not test their code? Why wouldn’t somebody do these things? Is there an expectation by management that this is the stuff that they do anyway and it’s part of their job or what?

Dave Wylie: That’s a great point, Howard. There may be an expectation by management that people just do this. The reality is, because many people in development don’t know these good practices, the development and QA and tech writing and operations tend to be entry level positions. In certain cultures the people that have done this for three to five years, they get promoted to management. Their hands come off the keyboard, they stop doing these things and other managers start to treat these people and they have this horrible phrase of calling people resources, start to treat these resources as fungible. So, there’s your word for that, a fungible. That means they can easily replace. So, the developer one is equal to developer two. So, we’ve not valued the craftsmanship component of what people do.
It’s relatively unusual across the world to have developers that have 20 years experience. Developers don’t. Most developers have three years experience. Where they’re learning their craft at? Well, they’re learning it in schools and many the schools aren’t doing some of these foundational things either. Also, they have contracts, if they’re a contracting firm, they have contracts with customers that incent them to deliver code quickly and miss and don’t say anything, they’re quiet on these practices. So, oftentimes, frankly, we’ve lost these things. There are absolutely pockets of people that are doing … there’s that thing called the software craftsmanship movement, which absolutely says, “Hey, this is a real profession. Let’s be good at it. It’s important how you do these things.”
Unfortunately, so many of these people that are in … the developers that are in our ecosystems now, haven’t had a good mentor and have not had formal training. The beauty of the Internet is democratized development. Anybody can learn how to do JavaScript or HTML CSS3 and do those kind of things and build systems and get them out. The learning curve for learning curve for Ruby and Python is relatively low. So, people, there’s lots and lots of people in the software development world that had zero formal training or informal training or mentorship on these practices. Unfortunately, these practices aren’t promulgated. They’re not out in the world.
We see it, the VersionOne survey that they do every year on Agile practices, shows us pretty consistently that about 30% of the people are doing test driven development, about 30% of people are doing pairing, less are doing more advanced practices like behavior driven design or things like that. Yes, it shows that … We’ve improved on some things like unit testing, yay, but doing them all the time and doing it all the time like we say we do an XP, it is still fairly unusual, that’s what the data is telling us.

Howard Sublett: It’s really crazy because you and I were talking earlier that it was, what is it? ’99 when Kent Beck wrote XP and Extreme Programming. So, it’s been nearly 20 years, 19 years ago and yet 30% of the people are following some of these foundational development practices. I’m wondering if it has to do with one of the other reasons why and it’s interesting to kind of think about the why, because maybe we can come to the solution, but since it is a team based, since a pair programming and other things are team based, there seem to be so much thrashed within a lot of development teams that fungible resource word that you thrown at us today, where they move people from team to team to team to team and they never actually go through any kind of a Tuckman model of storming, forming, norming and they never get to that stride of anything better. Have you seen that?

Dave Wylie: Absolutely, Howard. It’s very insightful statement. Our friends at Rally did some surveys and published some papers on the importance of stable teams, persistent teams, that can go through those phases of team formation and without it we tend not to see this high performance, which we know we’re capable of. Jeff Sutherland has published many times that, 10X performance, 10 times, not 10% better, but a 1000% better performance from these teams that are stable and have the support and do these practices. That’s the potential that’s in front of us and is exciting to me, is that it can make a difference and it’s potentially huge.
Again, often when I go do workshops one of my icebreakers is I ask people, “What’s the last good technical book that you’ve read?” Uniformly I get zero hands going up and I’m like, “Okay, I’m an old guy. I get that. People don’t read books anymore. You’re looking at videos or reading blogs. What’s the last great video or what blog do you read on a regular basis?” Again, I get very little feedback on that or very little people saying, “Yeah, I do this.” I think one of our opportunities in front of us is encourage a culture of learning instead of just performing and if we do that, then there’s a great ripe field in front of us of practices that we could do that will help us support the business better by delivering high quality code on a regular bases if people will just be open to it.
One of the real unfortunate things, again, is that development and QA, because of this fungible nature, have been outsourced in many, many companies. So, what happens if you’re a person that works for one of those companies? Guess what? Your emphasis is being billable. There’s really little time or money for you to go sharpen your saw, to go get better, to learn, to go to the conferences and be better and do these practices, whether it’s on a week a year or an afternoon a month on how do you get better. Unfortunately, there’s little space in people’s lives to get better. So, that’s my explanation for it.

Howard Sublett: I was thinking when you said going to the conferences and learning some things was, early days of Agile most of the conference kind of topics were in the engineering space. It was about those kind of practices and then the pendulum has swung to the point that it’s all about other things. It’s business agility and scaling, which are good things for us to start thinking about, and then they started adding like an engineering practice track within those conferences too. I think this is the second year that the Agile Alliance actually has a specifically focused engineering deliver, I think it’s called deliver this year, conference. I’m actually glad that they’re going back to those things. It’s a little bit like back to your roots into this.

Dave Wylie: Kudos to them for helping bring us together. I’ve kind of ranted for several years that the only XP, the Extreme Programming conference there is, is in Europe. Europe still cares about this. Why aren’t we? Where are we doing this? One of my colleagues, Vibhu Srinivasan has started a conference in Bangalore to try and get the Indian audience to see that this is so important, they can’t just compete on low cost anymore. They have to compete on delivery and quality and responsiveness as well. I think it’s awesome they’re there. Now we’ve got to get people room to breathe and go to those things. I work with really smart people. I’ve learned so much over the last five years, Howard, it’s just crazy. I’m nominally at the end of my career and I’ve learned so much. I probably learned more in the last few years than I have in the previous 20.
What I’m learning is that, while we want to focus on things like coaching and we spend a lot of these conferences talking about coaching, how do you coach people what is a coaching stance, those are really important, but there’s a facet of Agile. The other facts facet is we need to figure out how to build software that customers want. We don’t know what customers want. I was just chatting with a colleague that … The reality of Lean Startup or what Lean Startup has shown us is that we have ideas about what customers want. Until we implement them and put them in the market we don’t know that that is truly a value. Eric Ries talks about pivoting where we implement something and then we get feedback that says we really need to go in a different direction. These practices are going to enable companies to move in a different direction easily. If software developers were just order takers and building the thing that was asked for without feedback cycles, our ability to pivot is going to be limited.

Howard Sublett: It is a little bit scary when you think about the number of really, really high performing teams that we’ve all seen in our experience as clients is very small. Most people would have asked them at conferences to kind of name kind of how many teams have they seen that they consider to be truly high performing software development teams and it’s usually a handful, four or five that they can think of in their career of looking at very large companies. And yet, for these very large companies, their entire infrastructure is built on the fact that they need these things, they need these groups of people.

Dave Wylie: Absolutely. These guys, we need to value the people, I call them hands on keyboard people, hands dirty people, we need to value them and pay them and give them career paths that allows them to keep their hands on keyboard. Again, it’s one of the real disservices we’ve done as a process is say, “Well, once you’ve hit five years or eight years and you’ve now become a manager and you don’t get to code anymore.” Well, that’s a bummer. We just took some of our best, most passionate people and took them away from the ability to help create these corporate assets.
The other key one you said and I’ll echo again, persistent teams. We need to allow people to figure out how to work together. We’re working with some amazing clients that are … We’re talking foundational. Well, the next step are interesting things like mobbing, where the entire team is working on one keyboard at a time and they’re rotating in the seat. This is a fantastic way to get feedback, to bring new people into a team and get them productive, to share practices on things. We’re also working with some large orgs that are doing the concept of a Dojo, which is where … It’s taking the gym metaphor to say come in and let’s warm up and then let’s practice. Let’s do some Katas on a regular basis and then let’s practice with coaching and figure out how we can deliver and do these things. We know this works. We know they can implement some amazing stuff.
I wish I could name some of the clients we’ve seen that do this, but if you just look in the marketplace and see some of these innovations, they’re coming from these excellent teams that are doing these excellent practices. Some of the big dot.com companies, the web companies, they’re implementing thousands of times a day. If you’re in corporate America, if you’re an insurance company or bank or something like, “Yeah, we go live once a quarter or something like that, that’s our release plan.” That’s inconceivable. You’re speaking Martian to those people. Like, “No, this is possible.” The federal government has people doing this stuff. The military has people figuring out how we can implement on a regular case and foundational these practices.
That’s why I want our audience, especially if you’re in management, go talk to your teams, go talk to your vendors about how are you building code. Are you doing code reviews? You should be doing … code reviews we’ve known are a good idea. Well, there’s a great thing that comes from extreme programming called pairing. That’s where two people work on a chunk of code a time, there’s different pairing practices where they trade off writing code or writing tests, but guess what? You get 100% code review all the time. What a great concept. Writing test. Again, if you’re writing test and you’re following test driven development. You’re writing unit tests and you’re starting, before you do anything, you’re able to write the test. Well, guess what? If you’re able to write a test, that means you really understand that requirement. You’ve had a good conversation.
Again, not a new topic, bringing QA to the front of the process is something we’ve talked about for many years. If you’re able to write tests on it before you start, then it means you’re really rock that problem. As one of my developers has talked to me about, he says, “This allows me to figure out not only what the problem is, but how do I go at fixing this. How do I go out creating a solution to this, by doing it a byte at a time I’m able to break it down and come up with solutions.” This is very much a creative enterprise. This is not a rinse repeat exercise. Software development is new creation and these practices of working closely with other smart people, writing test, then integrating our code, allows us to get feedback and where we’re at because it’s a new creation thing.
So, integration is another one. We talked about integrate the trunk. If you want to amaze your technical friends, tell them that you know what integrating the trunk means because integrate, early integrate often, as one of my guys says. When you’re on a multi-team enterprise, let’s figure out how to get our software together so that we know it works together, let’s not wait for a day, a week, a month, a quarter to integrate our code because we need that feedback. We need to know if we’re on the right track.
So, these basic practices and then frankly, having a sense of stewardship of the software. Almost like ecology, you’re responsible for the ecology of the software. Don’t pollute it. Don’t mine it. Don’t strip mine it. Don’t inject poison into it. Be good to it. Make it stable. Make it better then you left it. We talked about the boy scout, make it better than you left it. You don’t have to rewrite the code every time, but if you touch code make it a little bit better and if you do that this asset is going to appreciate instead of depreciate.

Howard Sublett: Make it a little better, that’s refactoring. It would be like waiting until you run completely out of dishes and the sink is completely full of dirty dishes and you’ve got no silverware and then you start to clean out. It’s a big mess. It’s much easier to washing go as you go.

Dave Wylie: In fact, I would love to extend that metaphor because what we see in a lot of clients is they do that, the kitchen’s a mess, dishes are dirty and you know what they do? They throw it all away and go to Target and buy new dishes. They say, “We got to go implement a new system because this old system is so fragile and we’re scared of it, we don’t know how to modify it, it doesn’t perform so we’re going to go replace it.” Now, the vendors that are listening, that are in that new application market are like, “Dave, be quiet. You just uncovered the reason we’re going to be able to sell new applications system.” It’s because the old ones have degraded to the point where they can’t meet current business needs and the reason they’ve degraded is because we’ve ignored these practices.

Howard Sublett: I was thinking about this and if these are foundational practices that we’ve all known for a long time, from kind of three facets from your viewpoint, what holds an individual back from doing these practices? What would hold the team back and like what would hold a company back from making sure things happen? Because there’s got to be some resistors that are holding them back from doing them because if this is truly the thing they need to do, what would keep that individual from just doing them?

Dave Wylie: Sure, a great question and there’s a couple. There is a stereotype of developers as being antisocial. They would go put their headphones on and sit in the corner and do work and then they’ll show you when they’ve created this masterpiece. There is some degree of truth that developers are not the best people people, but they still, working together is something they can learn. Most of the people that we’ve exposed to these practices have some initial resistance. They’re like, “If you just leave me alone I’ll be much more productive.” And it’s true in the short term, but in the longer term if we work together either in a pair or as a team we can start to be better. And we talked that people have done this, people say, “Well, I can’t work the old way anymore. This is the only way I want to work. I want to work on a team where I can pair and we’re writing tests and we get this feedback.”
One, is this kind of the stereotype that some developers wrap themselves and say, “Nope, I work by myself. I’m the hero. When people think code they’re going to come to me and I’m going to be the hero.” The other piece is management, the favored pointy haired boss who comes around and says, “Why are you two guys working together? Why don’t each of you work by yourselves. You’ll be twice as productive if you work by yourself.” In fact, I heard one pundit say, “Pairing is crazy, that means you’re going to cut … If everybody paired, we would cut our capacity in half. That’s not possible.” A person that obviously doesn’t understand what pairing is, about the constant review, the constant feedback, the time we don’t spend going down rabbit holes, that’s what’s important.”
So, again the pointy haired boss is part of the problem. It’s easy for me to say because sometimes I’m that person, to back off and let … but let the team figure this stuff out and let them experiment and give them time and space. The other forcing function is these contracts that people sign. If you’re working for an outsourced person they’re focused on a tough date and a lot of us go fix, go fix date, iron triangle kind of problems. People can’t conceive that they can work in a different way and still meet those constraints. Jerry Weinberg said years ago, he said, “Well, as long as the software doesn’t have to work I can meet any other constraints. I can meet your time, your delivery, all those kind of things.” So, it’s the Zeroth Law of software.
We’ve seen that repeatedly. I don’t know about you. I’ve seen places where we’ll meet the date. Now, the software doesn’t compile, but we’ll meet the date to go into QA for you. We’ll trust QA to find all our problems and people celebrate, “Yeah, hey, look at us.” We repeatedly see, unfortunately, big clients, they get to the end of a delivery cycle, put it in and they figure out they’ve totally missed the mark at the end, after they spend the $10, the $50 million dollars and they either put it in and let it [inaudible 00:26:24] or they pull it back out and by then it’s too late. So, there’s this pressure, this perceived pressure in these deadlines and that’s where this new … What excites me, what’s really fires me up is we’ve got this new vision of what management can be, what product management can be, what financial management can be, what HR can be, that says, “Let’s change our focus. Let’s not look at cost per hour. Let’s not look at individual contribution. Let’s look at team contribution. Let’s look at value delivered, not cost of delivery or let’s add it to our equation anyway.”
That’s why I think we’re live in a great time. I’m excited about doing this stuff because I think we have the opportunity to be much better than we were and quite honestly, in oh by the way, if you don’t, you’re going to get left behind. If you continue to think you can do command and control and you continue to think that we can outsource and people are fungible, guess what? You’re going to lose and if you want to be on the winner side there’s these things you can do, which is encourage people to learn, encourage … and all you’ve got to do is start. So, start. Look at your vendor contracts and say, “What are you asking from the vendor?” If you’re asking for fixed delivery on a fixed date for a fixed price you’re going to continue to get vendors that are going to inflate their schedule, inflate their efforts to protect themselves. You’re trying to shift the risk to them. Instead you say, “I want to see your delivery every couple of days, at most every two weeks.”
I saw an example that’s from Department of Homeland Security, the national agency and they said, “If you’re going to be a vendor for us here’s what we’re going to expect from you.” That’s publicly accessible documents that people should look at from a procurement perspective that say, “I expect you not only to deliver code to me. I want to see that you’ve got good test coverage. I want to see that you’ve integrated and that you don’t have lots and lots of branches in things and I want to see this on, not every month or every three months, I want to see it on a daily basis.” And if we do that that’s going to be impactful for us.

Howard Sublett: One of the gaps within that for me is those things are hard to see if you’re not somebody that knows how to write code. For me, those are hard to see. Are there ways for … If I’m a manager and I have groups of teams that are building a software product for me, that I can actually see and check these things in a way that I would understand?

Dave Wylie: Sure. Excellent question. Step one is go talk to your teams, go see your teams. The Japanese call that Gemba, go to where the work is being done. Go work with your teams. If your team are remote, get on an airplane and go see them and see how they’re working, see are they working together or they work in individual cubes or separate floors. I see these horrible instances where QA’s on one floor and Dev’s on another and OPS is in a different building and the product people are in another city. Guess what? That’s not going to be as effective as it could be. So, go see, number one. Oh by the way, this is going to require some change and effort on management’s part.
You need to go see. It’s not a hands off, come see me in a month, kind of thing. It means every day you should be working with those developers and ask them, “Can I see the working code? Show me what you did yesterday. Can I see this? Can I see either the status of the build or can I see a component, a story? When a story is done, show it to me. I want to see it. Don’t show me Visio. Don’t show me a PowerPoint or a movie interpretive dance. I want to see working software about what’s working.” I’m telling you, Howard, it’s crazy how many times people try to weasel out of showing you a working software. So, if you’re seeing people do that, that’s a bad smell.

Howard Sublett: Interpretive dance, you made me choke up just a little bit within that. I don’t think I’ve ever seen anybody try to do that.

Dave Wylie: But you see people tap dancing. They widdle and waddle and they put some music on and they play a movie instead of saying, “Here’s the software we got done.” It’s very evidence-based. It’s do or do not, the yoda thing. It’s either done or it’s not done. Show me the stuff, let’s review it and we’ll know if we’re on the right track because again, engineering is half of that equation. The other half is the product side where we’re guessing about what customers want. Engineering’s job is to build it so we can get some feedback if we’re on the right track.
So, looking for test, ask them, “Are you guys testing? How many tests did you do? Are there more tests than we had last time? That’s a good smell. Do they have big visible charts of progress of status of integration? Those are good signs. Satisfied product owners. Sorry. Satisfied Product Owners are a great sign because when you do this on a regular basis the product people are so excited. I repeatedly see times when people go into Sprint demo and they show things and the product people are clapping. They’re like, “This is so awesome. I can’t believe you got this much work done in this period of time.” Here’s the dirty secret, oh by the way, if you do this stuff, you actually get faster.
I don’t want to put any pressure on the XP developers out there, but if you build this safety net of tests and CI and pairing review stuff, because you’re spending less time in your mistakes, you’re actually spending more time delivering features. So guess what? This is where we start to get to that 2X, 3X, 10X functional delivery of people. If you have a team that’s having to struggle delivering, they’re probably not doing these practices. If you’ve got a team that is delivering and making products or is happy there’s a good chance, they’re doing some, if not all, these practices.

Howard Sublett: Awesome. Awesome. Awesome. You’re holding the banner high for foundational engineering practices. You think you’ll see a major shift? You think you’ll see it coming?

Dave Wylie: I don’t. That’s the bad news. I don’t think it’s going to change a lot. I think it’s getting better. I think there’s going to have to be some organizations that age out. The people in management that believe they can control the developers and the scope of things they’re going to die out quite frankly. Either their corporations are going to fail or they’re going to retire and it’s not it’s probably going to be a long pole. Like you said, Kent Beck was starting to do this literally 22 years ago. We’ve known these practices. The contracts people have … Steve McConnell published The Low Hanging Fruit 30 years ago about these practices.
The good news is if you’re enlightened and you have opportunities you can win, you can beat the competition, you can beat the offshore people, you can add more value than your competition, you can go open new markets because you’re able to pivot and deliver and experiment and you can be the winner on those things. At the same time it’s a harsh ecology out there. We know that people companies in Fortune 500 last about 16 years. These are the most successful companies in the world. They’re only in that group for a short period of time and part of that is because they stop innovating. They think that we can predict things. We’re getting way more overhead than hands on keyboard people.
When you innovate, when you invest, you’re going to see good results. When you don’t and you spend more of your time on process and more of your time on non-software deliverables. People are very busy delivering these non software deliverables, but unless you focus on some of these practices you’re not going to have software deliverables and ultimately that’s the value of IT organizations and … Sorry, but again, since every company is a software company, you need to pay attention to these things. If you’re in HR, if you’re in finance, you need to go talk with your IT partners and say, “What are you guys doing about building a better asset for us and show me, show me the money.”

Howard Sublett: Wise, wise words as always, Dave. Wise words as always.

Dave Wylie: I don’t know if it’s wise, but I feel like I’m shouting in the wind.

Howard Sublett: Well, you’re passionate about it. I mean, that’s the thing, is you’re passionate about it.

Dave Wylie: Yeah. We have an opportunity. That’s the beautiful thing here, guys. Anybody that’s listening to this. You have a chance to change your organization for the better, to help your organization succeed. If it’s a nonprofit, if you’ve got a nonprofit that’s doing this or if you’re a small government that’s doing this, you have an opportunity to deliver more value for in shorter periods of time for lower cost. That should kick anybody in the pants to say, “Yeah, let’s go try and figure out what we need to do and let’s be better than we used to be.”

Howard Sublett: Awesome. Dave, if somebody want to reach out to you, how do they find you?

Dave Wylie: I’m David.Wylie@Accenture.com. Please reach out to me. I’d love to hear from you. Accenture and SolutionsIQ, which is an Accenture company, is very passionate about this. I’m blessed to be able to work with amazing people, some of the best trainers and developers in the world. We would love to talk to you. We would love to help you get better too.

Howard Sublett: All right. I’m hoping that your passion is infectious for those that are out there listening to us today. So, Dave, thank you so much for joining me buddy.

Dave Wylie: Thanks Howard, appreciate it.

Howard Sublett: All right and thanks again for joining me for another Agile Amped episode. Make sure and subscribe because you don’t know what might be next. Thanks for listening to Agile Amped. Find more inspiring conversations at AgileAmped.com, iTunes and your favorite podcast app. If you have an idea for a topic or feedback on an episode, reach out to us on Twitter, Facebook and Instagram or send an email to AgileAmped@Accenture.com.