“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
“That is, while there is value in the items on
the right, we value the items on the left more.”
-Manifesto for Agile Software Development
As major innovators in the current technology revolution, we find ourselves asking if the Agile Manifesto should still be our guide as we move into a world defined by continuous innovation. This short, but revolutionary document took us from shipping products like they were cargo on boats to same-day delivery by drone. But today we’re riding the wave of continuous technical improvement, which makes us wonder, is it time to improve the Manifesto, too?
Recently, the Accelerance team traveled South America to reassess and visit our Certified partners. During these visits, Jim Marascio, CDO at Accelerance, conducted on site podcast recordings about the validity of the Agile Manifesto, the ever changing landscape of technology and how our partners are navigating challenges, changes and the future of agile work. As we traveled through South America, we spoke with our Certified Partners - all of whom are experts on what not to do. Our Certified Partners are masters of this technical landscape and excel in maneuvering the ever fluid world of Agile rituals.
Listen this week as Bobby Dewrell, SVP of Delivery at Accelerance, gives an account of the Agile Manifesto and gears the Software Outsourcing Show's audience for the upcoming series of interviews with our experts located in Brazil, Uruguay and Argentina.
You're listening to "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority.
Bobby: Hello, and welcome to The Software Outsourcing Show. My name is Bobby Dewrell and I am your host, and I am happy to have you here with us today on the show. So, one of the things that I wanted to talk to you about is we're gonna change up our format just a little bit with this episode and then for the next couple of episodes over the next four weeks. We had talked with our producers here at the show and with the crew from Accelerance going on another world tour. I'm sure you heard our show the week before about their travels down to Latin America and them getting ready. We said hey, "Why don't we take Jim Marascio, let's put him on assignment. Let's have him talk with some of the partners and some of the software development firms they're going to see down there. And let's talk with all of them about Agile."
Agile has been around now for gosh, what, 18 years, we're closing in on two decades, it is becoming bigger and bigger. We're starting to see people apply Agile in places that we never thought, right? This was really all about software development is why Agile came around and now we're starting to see people apply it, I think NPR applied it and reduced their production costs by something like 60%. I've actually seen...read about people applying Agile principles and methodologies to genetic testing and things like that. So, it's really, really taking off and we thought it would be great to talk to a group of software professionals about Agile and what it means to us.
So, in case you don't know or if you haven't heard the story, or maybe you have, but you know, I'd like to recap it again. And really what happened was Agile came about in 2000/2001 where it was a group of thought leaders from the industry got together just from the consequences of the frustration throughout the '90s. You know, it was the time lag between requested features or requested applications and the actual delivery of technology. Right? The businesses, the requirements, the customers, all this stuff was changing during this lag time. And the final product just didn't meet the current needs. And the model of the day, the ruler of them all was waterfall, and I'm gonna be honest, I was a waterfall guy, right? That's where I came from where we did all of these strict routines up front, we heavily defined everything, we figured out all the tools all the stuff we were going to use. We talked about all the potential negative consequences. We wrote these magnus opum of projects that we were going to do. And, man, it just took forever and then by the time we were finally delivering, we were already outdated. The technology had changed on us, things had moved, right? It was all kind of different by then. And so, that's what happened, these groups of thought leaders, and when I say thought leaders, I mean, I'm talking about, you know, like John Kern, [inaudible 00:03:25], Ward Cunningham, Ivan Bandicam, Alistair Cockburn, they all met together first at a resort in Oregon, if I recall correctly, and then ultimately, the manifesto came out from their meeting at the lodge at Snowbird ski resort in Utah. And that's where they came up with the manifesto and the 12 principles, they were all formally written.
And so, as you may know, that the Agile Manifesto is simply 4 values and 12 principles. And the manifesto starts out with, we are covering uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration, over contract negotiation, and responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. And I got to tell you it's this last phrase, that sentence right there, why we value...where there is value in the items on the right, we value the items on the left more. That's what a lot of people miss because what we hear is we go in and we're working with different clients and they say something about they're using Agile and those type things and we'll say, "Okay, well, you know, can we see some documentation?" Oh, no, we do working software over documentation. Well, that's not exactly what the manifesto says, right? It says there's still value in it. It's just we're going to value the software a little more. So, let's kinda take those four values and look at them before I get ahead of myself. When we say individuals and interactions over processes and tools, we're talking about we're gonna value the people who respond to business needs and drive the development process, we're gonna value them more than the process itself, right?
So, in the case of individuals, we're looking at communication in a fluid way that happens when a need arises, as opposed to the kind of old waterfall days where we had a lot of formal documentation and formal reports. And there were specific content that had to be required in each type of document and in each communication and, you know, you couldn't say this here because you were gonna say it over there. And, you know, we're saying no, let's let communication flow, let's talk about it, right? And let's have those daily meetings and the stand-ups and let's get our customer involved more often and frequently, right? The same way when we say working software over comprehensive documentation. You know, what we're saying is instead of all those initial document documents that we used to have to pull together, right, the BRDs and the technical requirements and all those other types of things that we do, instead of doing those, what we're gonna do is get information to...we're gonna streamline it and give only what the developer needs to him without trying make it overcomplicated, right? We're not gonna eliminate documentation, right? We value documentation, right? It's one of those things on the right. And we value those things on the right. We just value working software more. So, you know, keep that in mind, we're not saying we're gonna eliminate some of these things.
So, let's talk about customer collaboration over contract negotiation. Wow, you know that says a lot there, right? When we talk about contract negotiation, we're talking about this, this finite period, where the customer and the project manager's just gonna work out all the details of the delivery, right? And determine, hey, this is what we're gonna do here, we're gonna do it now, we're gonna do it this way, you're gonna bring it at this time, then we're gonna make this done. And this point might need to be renegotiated later. And if we need to change or move something, then we got to come back and renegotiate. Well, collaboration is completely different, right? It's just a whole different creature entirely. Because it has...the customer is actually working with the team, it's just a part of the team, right? It's the requirements for the product are done in great detail and in along the way, right? So, it's a customer who's engaged and collaborates throughout the entire process, right? It's having smaller intervals for periodic demos, right? And have the end-user or the customer even is part of the team and attending all the meetings and ensuring the product meets the business needs, right? That's what we mean when we say collaboration, not this formal separation but just a part of the team. And then responding to change over following a plan. Man, you know, the one thing that I don't miss from those waterfall days, right, is those huge projects where we define everything and just all upfront, made it all done, set out our plan, said this is our course. And then somebody says iceberg and you've got to try to move the Titanic. Man, change was nothing more than an expense. It was just an expense of money, it was an expensive time and often sanity.
Wow, it was just rough because we had to go through, we had a large number of dependencies, there were all these things that we had to change and to move and who are we gonna impact and what happens and does it add more time or, you know, what's going on? What are we not gonna make now? What's changed here? Does that impact someone else? Why did does it impacts them? No, not in Agile, right? And Agile, we have these short iterations, right? So that we can just iterate. So, we do a little bit and we allow priorities to shift and move from iteration to iteration, new features could be added in the next iteration, right? The change in Agile and the way Agile looks at change is that it's a way of improving the product. The change actually provides value, not takes it away, it's a way of making it better. So, you know, when we talk about those values, those values run throughout all of the principles, right? And the guiding principles were nothing more than to describe a culture in which changes welcome and the focus is on the work for the customer, right? To demonstrate the intent, right? To bring development into alignment with the business needs. An intention of Agile is to align development and business, period. That's what it's been, it's really an overarching view of software development throughout the industry and in the industry.
And now, you know, the one thing that I wanna talk about, and for my Agile purist out there that are listening to this, and I'm probably driving you nuts with some of this stuff, right? But we got to talk about the Agile industrial complex, right? That there's faux Agile out there, you've got the evil twin, Dark Agile, right? That just they're exacerbated by the monetization of Agile education and consulting, right? It's the Agile industrial complex, it's just...it's a way where some of these educational organizations and some of these consulting firms out here provide one process and they value the process over the principles. And that is just...that flies in the face of what Agile is. So, whether you call it faux, you call it dark, you know, some people call it the cargo cult, right? These are all subversions, and they just lead to situations that fly in the face of the manifesto's intentions. And, you know, really what does it lead to? It leads to micromanagement to burn down or rate pacing, right? A total lack of delivery, and just adherence to process over the principles. And that's the most important thing that I can say here, is we've got the 12 principles, and that's what we're gonna talk about with some of these other firms as we go along. It's adhering to the principles, not a process. See there is no one Agile process, there's a not one process out there that you can just call Agile. That's not the way it works, that's not what this is, right? It's a belief in some core principles.
So, anyway, like I said, I know I got on a little bit of a soapbox here, and I apologize for that. But hopefully, I didn't take anything away. Hopefully you're really looking forward to the next, you know, four weeks, maybe five weeks, as we talk about Agile with some of the different practitioners, what it means to them how their approach to it is and how they work with clients. And I'm gonna encourage you over all this time as you're listening and you're going through this series, you know, please feel free, write us...tell me what you think about it. Tell me how...what it means to you and what you see as Agile. What I would love to do is maybe if we get, you know, enough people writing and you got a great story to tell, hey, maybe we'll have you on the show here with me. That'd be great. So, anyway, until next time, my friends, thanks for listening.
Thank you for listening to "The Software Outsourcing Show" brought to you by Accelerance, the global software outsourcing authority. Do you have a topic you'd like covered in a future show? Then send us an email at email@example.com, firstname.lastname@example.org. Show notes, links and materials discussed on today's show may be found on our website at softwareoutsourcingshow.com. That's softwareoutsourcingshow.com.