Scrum DOES NOT Equal AGILE

I never worked in a waterfall process well of course that's a lie I mean I've never worked in a waterfall process where we actually agreed and admitted to it being a waterfall process I've worked in numerous companies where we worked agile within the gates in a stage gate model we had what people call water scrum fall a lot of analysis up front some agile iterations and then a lot of testing and integration afterwards foreign Corey and I'm a co-host and Dave Farley's continuous delivery Channel welcome to this channel if you've not been here before please hit subscribe and if you enjoy the content today hit like as well before we begin a thank you to our Channel sponsors equal experts try centers transfit and Ice panel all of whom help us grow the channel and provide products that align very well with what we discussed in this channel when I started working as a developer more than 20 years ago we worked in a purely agile process we worked with XP we worked with pair programming we worked very iteratively and in super small increments smaller than two weeks the company I worked for even designed some pair programming tables with help from Quebec ironically my first job as a teacher in industry was actually to teach Java programming in the Rock process which is actually very much a waterfall process at the time I didn't think that that was a problem at all even though we would never work in such a process in our company I could see the point of waterfall process where you can actually plan exactly what it is you want to make and then you can analyze how long it will take and you can make the design and then you make the implementation and then you put all implemented Parts together and then everything works in the end at the time I couldn't really see a problem with it and the people that I was teaching this couldn't see a problem with it either of course I'm immensely embarrassed about that now but I was young and I needed the money now since I've been working in some sort of agile way for the past 20 years I should probably know what to say to people who are skeptical about RTL processes shouldn't I especially since I've been an agile coach for the past 10 years or more and with an agile coach I mean somebody that the management has invited into an organization to make people work in the agile process that they have decided they should work with or at least that's what most agile coaches do I know that there are also some adventurous agile coaches who go out and modify the process that the management decided that people should work under they change it to something that fits the developers better I think that's a brilliant thing to do but you don't always get that choice as an agile coach not all agile coaches can do that so I do understand that there's skepticism around the concept of agile I know that even Dave Thomas who was one of the people who wrote that gel Manifesto started talking about how agile is dead more than 10 years ago what he meant was that the way we're using agile processes Now does not work he says that agility is more interesting but what does he mean by that he means that instead of following an agile process to the letter you should instead think about the agile principles behind it all there are 12 agile principles the first is our highest priority is to satisfy the customer through early and continuous delivery of valuable software number two welcome changing requirements even late in the development agile processes harness change for the customers competitive Advantage three deliver working software frequently from a couple of weeks to a couple of months with preference to the shorter time scale 4. business people and developers must work together daily throughout the project five build projects around motivated individuals give them the environment and support their need and trust them to get the job done 6. the most efficient and effective method of conveying information to and within a development team is face-to-face conversation seven working software is the primary measure of development eight agile processes promote sustainable development the sponsors developers and users should be able to maintain a constant Pace indefinitely 9. continuous attention to technical excellence and good design enhances agility 10. Simplicity the art of maximizing the amount of work not done is essential 11. the best architectures requirements and Designs emerge from self-organizing teams 12. at regular intervals the tune reflects on how to become more effective than tunes and adjusts Its Behavior accordingly that's basically retrospectives but unfortunately the 12 principles are very long to read for people so they don't read them it's much easier just to look at the agile Manifesto It's only got four different points 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 these four points are easily misunderstood in both directions famously we have the manifesto for half-assed agile software development by Kerry Buckley this adds some extra text to them for example responding to change over following a plan provided a detailed plan is in place to respond to the change and it is followed precisely the subtext to the manifesto for half asked agile software development is while the items on the left sound nice in theory where an Enterprise company and there's no way we're letting go of the items on the right but I also see skepticism arising from a misunderstanding in the other direction it's much easier just to read the agile values and if we look at the last one we value responding to change over following a plan that is very easily interpreted as when you do Agile you don't need a plan because of this we have people claiming that when we are agile it's Anarchy because we never plan anything and I hear people laughing at me when we talk about planning and they say oh I know I'm sorry we're planning so we're not as agile as you want this to be it really makes me angry when people say that but luckily I've worked with my anger management so they don't notice anything but the holes in the walls and the hallways but the point about this agile value is that we value responding to change over following a plan it doesn't mean that we don't have a plan or that we don't try to follow the plan agile doesn't mean that you don't have a plan it means that if you have a plan you should accept to embrace changes to that plan actually I think that making a plan is brilliant no matter how agile you're working it's a very good idea to think things through as far as you can but then you also have to accept that even though you want to think things through you shouldn't dive into analysis paralysis and try to think about all the different eventualities that might arise in the future you should make an overview of the plan and then the closer you come to the different milestones in the plan the more detailed the plan can be it's a little bit like the way that we look at backlogs we say that the tasks described in the backlog need to be more and more precise the closer we get to top priority of the backlog and the further we are away from the top priority the less detailed the tasks can be described but the problem is that people read the principles in a shallow way and misunderstand what being agile is about because they just see that oh we can't follow a plan so that was my rant about 0.4 in the agile Manifesto next I'm going to work backwards and tackle the third we value customer collaboration over contract negotiations oh okay so we can't make contracts with our customers you say the only thing that we can do is chit chat with the customers every other week and that's the way that we can make the system that's also not correct it's quite okay to negotiate a contract but when you are negotiating a contract with somebody and you want to work in an agile way then you of course have to tell the customers that you're working in an agile way and that means that we're trying to learn and that we're now creating the contract with some flexibility there's a lot of debate about agile contracts and I'm not going to go into detail with them here moving backwards in the agile Manifesto the previous point is we value working software over comprehensive documentation does that mean that we shouldn't document anything no you've learned it now no you can definitely create documentation but you have again to accept that the working software will change and the documentation has to change with it often the best way to do that is to either make the documentation in the code AS comments or some sort of annotation so that it changes with the code alternatively you just have to revisit the documentation whenever you change the software otherwise the documentation will be stale and nobody will read it and it will have been a waste of time to create it I know that some people have started feeding their code into chat gbt and then the chat GPT will actually make a very nice documentation of their code it could potentially be a bit dangerous because you do not know where your code goes when you give it to a chat bot but if you don't care about that that might be a way to actually keep your documentation up to date and the last or the first point is we value individuals and interactions over processors and tools and this is an interesting one if it is true that we value individuals and interactions over processors and tools why is it then that some of the agile coaches say that if you don't follow this process completely then it doesn't work why is it then that people sometimes say that the toolger is what makes the magical what happened there the problem is I think that it's much easier to use processes and tools and have rules for those things than it is to actually value individuals and interactions between individuals when you have some individuals that need to communicate and you want to make sure that they do it in the right way it's much easier to make them follow a rule set and then if something goes wrong with the communication you're thinking oh we should add some more rules to this we should put some more processes into this maybe we should use another tool to check just how many hours you spend on this task and then something goes wrong again and then they say oh we need more control we need more processes we need more tools and then what happens in an organization like that is that processes are like scar tissue an analogy is that if you cut your hand your skin creates scar tissue to make your skin A Little Bit Stronger so that if you cut your hand again it'll be more resilient and the more you cut your hand the more Scar Tissue you get on your hand but when you get a lot of scar tissue you're not very flexible anymore and rigid processes are like scar tissue in an organization whenever something goes wrong you create another process in order to prevent this failure from happening again but the more processes you put into an organization the less agile it gets and that is why instead of just adding more processes we actually need to add more interaction and communication between the people but that takes time and that's difficult and it's easier just to create more processes and for me that's probably one of the things that it it's most difficult about introducing agility in an organization I can easily make people understand that plans can change by showing them how their own plans have changed previously I can show them that contract negotiation is not as valuable as customer collaboration and how it can work better with demo sessions or better reviews with stakeholders it doesn't take many meetings to prove that the value of what we do becomes better with better communication and they already know that comprehensive documentation that is always right does not exist and that working software is the only thing that is correct all the time but the last point about valuing individuals in interactions that is the hardest thing for me to convince people of in an organization for some reason people are not able to communicate about things like API between systems or how to hand over systems between developers and operations and I know that there are more organizations now where we have a very good collaboration between developers and operations but it's not like that everywhere yet and in general when people are placed in different teams the other colleagues quickly becomes the other people and communication becomes harder but instead of just creating more and more processes and communication layers and tools between these people what we should do is that we should remove all these things and enable them to communicate it with each other to find a way for them to communicate maybe even every day or maybe every other day the actual human beings need to communicate with each other and to say out loud if something is stalling them and here it comes back to the Daily scrum meeting the stand-up meeting that some people hate for various reasons they think that it's a complete waste of time and some days you might not get something out of the daily stand-up meeting but the daily stand-up meeting is there for a reason and instead of just following the process you should ask yourself why do you have this meeting and what are you supposed to get out of it you're not having the daily stand-up to talk about what you did in detail and not to talk about how many meetings you're going to today but it's a forum to talk about things that you need help with or questions that you have or things that you're wondering about and having those very short daily meetings is so important for people to work together I remember once I talked to somebody who was a manager in a company that made a new browser that was much quicker than the existing browsers on the market and I asked him if they were using an agile process and he said no we hate agile it's the worst it's a complete waste of time okay I said so what are you doing then how are you communicating well obviously he said we're communicating every morning just very shortly just to make sure that we're on the right path okay I say right okay how do you make your plans well we do make plans he said but we revisit them every week just to make sure that we're going in the right direction okay and how about your communication with the customer well of course we're communicating with the customers we're showing them what we have from time to time so that we know whether we're going in the right direction or not and we aim to have the software always be shippable we are shipping a new version to the customer every few weeks and then I asked him how is this not agile because we're not doing scrum and this is one of the biggest misunderstandings to say that agile is always scrum and scrum is always agile you can definitely use scrum in an waterfall process you can use scrum as a way to support project managers into seeing exactly what people are doing and how many hours they're using it to do it and you can plan Sprints months ahead of time you can also definitely do Agile development without using scrum or any other documented process such as Crystal dsdm ASD lean kanban XP or AUP the core idea of agile besides all the principles the values and the processes is inspect and adapt if you are inspecting and adapting to what you find out then you are being agile but in order to do that you actually need to inspect you need to be able to see how things are working so you need that openness from the people working perhaps that you're abort with the flow or you need to have demos with the stakeholder so you need to have management knowing what's happening not how many hours you've spent but what's actually happening you need that inspection and then you need to be able to adapt to the situation and adapting to the situation means that you can react to What you see when you inspect but the problem is that there are so many things you need in order to be able to adapt you need to trust from management and you need trust from the customers to change the functionality that you promised into something that is better and you need the management to actually invest in Agile development by supporting continuous delivery because if you do not have continuous delivery or at least continuous integration you cannot be agile because in order to adapt the software you need to have the courage to change the software and in order to do that you need to know that when you make a tiny change somewhere it doesn't mess everything up so we actually need technical agile support in order to be truly agile there's no real agility without technical agility and that means that you have to strive for the continuous delivery that this channel supports in order to have real agility so in summary I see organizations claiming that they agile because they make people stand up 15 minutes every morning and they use jira or Asia devops but if you do not give people the trust and courage and testing infrastructure to change the software you're missing the point and then you're agile in name only which acronym fondly is my name a-i-n-o thank you for watching if you're interested in learning more ideas and techniques for teamwork and Leadership and Tech teams check out our teamwork and Leadership playlist that you can see here foreign [Music]

Channel: Continuous Delivery

Views: 31,176

Keywords: agile, scrum, scrum master, agile methodology, agile project management, agile scrum, agile 2023, what is agile, agile software development, agile mistakes, agile coach, agile training, learn agile, software engineering, continuous delivery, aino corry, agile vs scrum

Id: bdSzvnccLQk

Length: 17min 47sec (1067 seconds)

Published: Fri Jul 07 2023