The Agile "Revolution"
A free video tutorial from Doug Rose
Publications, classroom and online training
4.4 instructor rating • 2 courses • 4,908 students
Learn more from the full courseAdvanced Agile and Scrum (PMI 8 Contact Hours)
How to become an effective Scrum Master and Scrum team
08:08:26 of on-demand video • Updated September 2019
- Learn how to use Scrum to deliver software or information technology (IT) products with a more agile mindset
English [Auto] So one of the big questions that I get after a lot of my agile classes is why now why why why do I have to worry about agile. We've been developing software products for 40 years and so why over last 20 years. 80 percent of products being delivered using an agile mindset. And the big difference between then and now is you. So I grew up outside of Detroit in Michigan. And so there were a lot of auto plants there. That was Ford and GM. And if you wanted a job in the 1960s you were just kind of show up and they would train you on what you needed to know to do the job. And so you didn't have to have a master's degree didn't need to know about how to put together a car before you showed up for work. They would train you on what you needed to know. And so if you were there for 10 or 20 years eventually you would become a manager and then new people would come in the door and you would train them on what they needed to know to do the job. And so in these organizations you have a pretty strict hierarchy. You have a manager and then you have the employees underneath them. But what's important is that the managers know everything that they need to know for the individual employees to do their jobs. And so if you were working assembling a part of a car if you were painting cars in the assembly line and after 10 years you sort of learned how to do everything that needed to be done to paint a car. And then when you hired a bunch of new people you knew everything they needed to know to do their job. So you could recommend how they could do it better or you could sort of train them on different ways to improve. Now if you think about today you've got a lot more people who are working sort of as knowledge workers. And so the intellectual capital of software developers is in their brain and so they often show up knowing exactly what they need to do to get the job. And so if you think about that it makes it much more difficult for a traditional hierarchy to work. So imagine that you're a manager on a software product so you might have database engineers working for you you might have software developers you might have testers you might have UXO UI people working for you which are user experience people you know quality people. And each one of them might have decades of experience so they know a huge amount of what they need to know to do the job. They didn't just show up and say hey I want to be a tester so you know teach me everything I need to know about quality assurance and then I'll eventually become pretty proficient at it. Instead they show up knowing that their knowledge workers they have that capital. But it makes it very difficult for you as a manager to sort of understand everything that's going on in the product. So you couldn't be a manager and know everything that the quality assurance people know and you couldn't know everything that the software developers know and everything that the database engineers know you couldn't know all these different things because each one of them might have decades of experience. And so it becomes very difficult for you to manage these people using a traditional hierarchy. And so that's really where agile got its start. It wasn't about it just a organizational change it was about people change and so that forced the organization to change. So that's why often agile is called sort of the agile revolution. And so back in 2001 you had a bunch of different software developers and they got together in Utah in each of these offered developers came from what they called these different lightweight frameworks. So there was scrum extreme programming and lean software development and they all got together and they were trying to understand what they do that's different from how other organizations were delivering software so they got together and they decided that they wanted to sort of up in the way that companies think about software you know. Old companies were still using that kind of general motors Ford way of delivering software. They had this strict hierarchy with managers and managers told the software developers what to do and they delivered it in chunks and the managers were expected to know what all their employees were doing. But you know about in 2001 that wasn't really possible anymore. And so these Soffer developers recognize that and they were trying to come up with a new way to deliver software a new way to think about delivering software. So they got together in 2001 and they were trying to come up with a name and they didn't like the name lightweights because they didn't want to call each other a bunch of software lightweights. So instead they tried to come up with a name that reflected this kind of ability to move quickly. And at the same time make quick changes and so they came up with the label agile and they started to think about agile kind of as an agile revolution. They were trying to take these slow moving products that were the slow moving organizations that were delivering products in a very kind of old way where you have a traditional hierarchy and they were trying to make it more nimble and they wanted that to sort of they wanted to up. And so they use the term agile and they created what was called the Agile Manifesto. Now the reason they used the term manifesto was a kind of reinforce this idea that it's kind of an upheaval a revolutionary language. They wanted to sort of make it sound very dramatic it wasn't they could have easily called it kind of like the agile ideas or the agile work group but they went with manifesto because they wanted to kind of really communicate that this was a big change. So they got together and a bunch of the sort of software developers went off to ski on the slopes and a couple were left behind with a white board as you often see happening in meetings and they're trying to sketch out what they thought was similar between all these different lightweight frameworks scrum Expwy lean software development Kristel. They're trying to figure out what's the similarity and so on the whiteboard in a very first draft. They wrote the Agile Manifesto and they started out on the whiteboard writing out 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 and responding to change over. Following a plan. And so you have again this very revolutionary sounding language. And in these values you see that they have cut it they put a lot of emphasis on working software because from the from the perspective of these lightweight software developers they didn't put that much value in creating huge amounts of documentation. Well that was still kind of a hold out from this old way of viewing organizations. We have a strict hierarchy. And you have the customer create huge amounts of documentation saying exactly what the product was going to do. And then you'd have the software developers work hard to kind of build out what was exactly specified in the Documentation Project Management. This is often called the requirements. And so you have everything that the products required to do planed out in front by other people in the organization and the developers essentially just kind of almost mindlessly delivered what was required. And so but with this new Agile Manifesto they put a lot more emphasis on individuals in interaction and working software. And so if you look at this at the core values here in the Agile Manifesto so you should almost think of this almost like a pendulum. We have sort of the values on the left individuals in interactions and working software and customer collaboration and responding to change over following a plan being pulled back away from processes and tools and comprehensive documentation and contract negotiation and planning. And so this is it's not that you're saying that these lightweight software developers are saying that you should never have any documentation or it should never work with processes and tools. You should never do any planning. What they're saying is that organizations are putting way too much emphasis on these items on the right and they need to put a lot more emphasis on these items on the left that try to pull it back over. And so you can kind of tell that this Agile Manifesto was written in 2001 because some of it sounds a little dated. You know customer collaboration over contract negotiation you know it's some of these things were still based on using delivering software products that sort of this big planned out thing and so it was before you have like app stores and things like that where you have a lot smaller smaller groups of people working to deliver software applications. Another thing that you see here aside from this being pulled back with the pendulum is that this new manifesto it sort of encourages this kind of customer collaboration with software developers and the way that these things used to be delivered because it was based on the strict hierarchy is that there was sort of this business side of the organization and then there was this software development side of the organization and the software development treated the business side kind of as a customer. And so they didn't really have this type collaboration they didn't if there was a problem then they sometimes they even tried to keep that away from the customer or try to protect it. They see they see the customer as someone who sort of that they need to look after and not necessarily someone that they need to collaborate with. And sometimes you'll see that in organizations where they come up with requirements and they kind of throw them over the wall and then the software developers try to figure out how to deliver it. But if there's problems or something like that then they don't necessarily get to collaborate with the customer and go back and ask them questions because from the customer's perspective they're like well we're paying you to create this thing that we've created these very detailed requirements for. So you need to go kind of deliver that for us. So in some ways they thought of it almost like you're ordering something you know like a meal or something like that and you're saying here's exactly what I want. Now you go and create it and give it to me. In reality that's not how a lot of software works. You know at any time if you probably worked with requirements you realize that sometimes the detailed requirements actually give you a lot more questions and answers than it's just the way that it's very difficult to make a detailed requirements document for something as complex as software. And sometimes the language itself is difficult. You know if you're if the requirements says that you know it needs to have a button then it doesn't necessarily specify where that button should be what color it should be or how Where's the best place to put it. And so you kind of need with these newer than delivering newer software product you kind of need this close collaboration with the customer but that also allows the customer to kind of get a peek under the curtain of how your software developers do work if they run the challenges or if they're having if they have serious issues then the customer will be right there to kind of see what's going on. And that is a big change from how organizations typically delivered software.