Jeremy - In this lecture, we're going to talk about the 12 Agile principles. We  talked about the four values, but principles are a bit more descriptive guidelines  to help us make decisions through our daily agile activities. Agile principle  number one, our highest priority is to satisfy the customer through early and  continuous delivery of valuable software. So in summary, principle number one  is all about delivering value faster. So Vivek, what does that principle mean to  you?  

Vivek - Yeah. Jeremy, when I read this principle, there are two things that stand  out to me. First thing is faster or early on, and the second thing is continuously.  So in contrast to traditional waterfall development, instead of doing regular  design and then development and then testing and then implementation, where  the value is realized at the end of the project, Agile says, try to deliver value  faster almost every week or every other week, where you can give some kind of  valuable software to customer, a feature to the customer, and they can give you  feedback.  

Jeremy - Got it? Yeah. So waterfall realized all at the end, agile is trying to  make it where you're realizing the value throughout the project. Makes a lot of  sense. Definitely. Agile principle number two, welcome changing requirements,  even late in development, agile processes harness change for the customer's  competitive advantage. And in summary of the second principle, it's all about  welcoming change. So Vivek, what do you think about that one? Responding  

Vivek - to change in 21st century is crucial for any business, even a small  business, you need to be able to change. So what this principle is saying is, if  somebody is part of an Agile team, and if they're delivering something to the  customer, think about being able to create something for customer in case  something changes on their business end. And it's also about delighting  customers as well and really responding to their needs. Because if you think  about in the traditional waterfall development, where customer comes with the  initial set of requirements, and there's a sign up process, and once you do that,  you cannot really change anything. So in the Agile processes, where you can  actually change, and you are open to change absolutely,  

Jeremy - yeah, waterfall, they even have a change control process. I mean,  that's really important to keep that project online where agile doesn't go that  route. And it really comes back to the main quote that I've heard all the time, that the only constant in business is change. Business is always evolving.  Businesses are always changing. Of course, that project is going to evolve and  change. Agile principle number three, deliver working software frequently, from a couple weeks to a couple of months, with a preference to the shorter time scale. 

And in summary of the third one, it's all about delivering working software  frequently. So back to you, Vivek, what do you think about  

Vivek - that one? So two things in this principle, working software, and then  frequently. So in this principle, what we are saying is focus on the working  software. And when we say working software, it is not a requirement, it is not a  mock up, it is not a wire frame. It is working software, something that actually  works a part of the feature that you can give it to the customer, receive  feedback, and see how they use it. And then the second thing is the time scale.  Sure you are trying to shoot for the shorter time scale a few weeks. And every  few weeks, you're trying to have some sort of working software, and you're  trying to give that to your customer, absolutely.  

Jeremy - So the working software is you can give it to them so they can get  their hands on it, because most change and most ideas will come out when they actually start working with it, and they can see themselves trying to meet that  business need so that that's absolutely crucial. And I think that's a huge, huge  proponent of agile. Agile principle number four, business people and developers  must work together daily throughout the project. And in summary of principle  number four, it's all about working together daily. Vivek,  

Vivek - yeah, Jeremy, so think about you and I were both business analysts at  some point, right? So remember how we were the liaison between the  development team and the stakeholders of business folks. So here what Agile is saying is there's no need for creation of this layer. Developers, the team and the  stakeholders or the customers can actually talk. And in fact, it's encouraged.  They're talking on almost, almost on a daily basis. And the other thing to  remember is, we're not talking about business people asking developer, when is  this going to be done? When is this going to be done? Sure we're talking about  collaboration, what are we building? Has anything changed so that kind of  communication is happening throughout  

Jeremy - Awesome? Yeah, I think sometimes the business analyst becomes a  bottleneck, you know, in a traditional waterfall methodology, and with agile, it  removes the blinders from the developer and allows them to get their questions  answered directly. From the source, rather than going through a layer which  doesn't really add much value. Yep,  

Vivek - it just helps everybody to get on the same page on what they're building. 

Jeremy - Agile principle number five, build projects around motivated  individuals, give them the environment and support they need and trust them to 

get the job done. So in summary of principle number five, it's all about building  projects around motivated individuals. So Vivek, what does that mean  

Vivek - to you? Yeah. Jeremy, the key concept here is there's no project  manager trying to ask you, you know, what did you do yesterday? Or, like, how  much have you done? Like, no status reports. The idea here is, you know, hire a really good, motivated group of individuals, part of the team, who are cross  functional, and actually give them space to actually do amazing work. And when  we say work, not just develop software, but also to solve problems for the  company or the client,  

Jeremy - yeah, it's always about creating value, right? Yeah. And so I think the  big thing to keep in mind here, if you're going to work in an Agile team, is,  regardless of your title, these teams are cross functional. That means they cross over roles, your duties and responsibilities are going to evolve and change, and  that is because everybody's collaborating together to try to realize that end  value, agile principle number six, the most efficient and effective method of  conveying information to and within a development team is face to face  conversation. Well, summarizing principle number six is pretty easy, face to face communication. The fact, what does that mean to  

Vivek - you? Yeah, what this means is, instead of writing a big piece of  requirement document and giving to a developer, we are encouraging more face to face communication, or, even worse, creating a ticket or messaging them and bothering them all the time, just having meetings face to face, where you are  able to communicate what you need, having a conversation. What a novel  idea. Yep. And also, if you look at all the Agile meetings. It actually encourages  face to face communication as well.  

Jeremy - Agile principle number seven, working software is the primary  measure of progress. To summarize, working software is key. Vivek,  

Vivek - this principle is just saying that whenever we're thinking about progress,  let's measure that in terms of our working software. What have we built? Not  how much analysis we've done, or how many pages of documentation we have  created, or how many mock up pages we've created. This is purely working  software  

Jeremy - that makes sense. And while we may be creating models as in part of  that and have them attached to our various items, the working software is really  what we're driving towards and what will create the most value. Agile principle  number eight, agile processes promote sustainable development. The sponsors,

developers and users should be able to maintain a constant pace indefinitely.  Principle number eight, all about sustainable development. Vivek, what do you  think?  

Vivek - So? Jeremy, remember those traditional days where business analyst is doing all kind of analysis, they're stressed, and they hit their deadline. They  finish, they give it to a developer. Now development team is stressed out, and  they're trying to make the ends meet, hit the deadline, and then finally, they're  done. Then it goes to tester. It's testers time to be stressful now they're testing  everything. And then implementation time comes in, and everybody is stressed.  So in Agile, what we're trying to do is, instead of this big bang thing, where in  everybody's working in phases, we're talking about, okay, what are key features, what we need to do? What is teams capacity? And think about a sustainable  pace that team can develop in?  

Jeremy - Yeah, I think that's really important, that because in Agile, the whole  team is getting together so it makes it more sustainable, because people, it's a  cross functional team, so everybody's able to help move that, that particular  project forward to meet the value agile principle number nine, continuous  attention to technical excellence and good design enhances agility. And to  summarize, it's all about technical excellence. Vivek, what do you think I want  

Vivek - to talk a little bit about quality in this principle. So if you build something,  and if there is no quality in place, you cannot build anything on top of it. So it's  gonna be harder for you to be agile in the future. So agile says, think about  quality. Think about technical excellence. As you're building certain product  

Jeremy - absolutely, yeah, you evolve those features and functionality you've  built, right? You're making slight changes to them and additions to them to help  drive value later on. If you've got problems early on in that design or in that initial quality, you're gonna have problems for a long time. Agile principle number 10,  simplicity, the art of maximizing. The amount of work not done is essential.  Summarizing number 10 is really easy. Simplicity. Vivek, what do you think  

Vivek - when I think about this principle? Jeremy, I think about Google's landing  page. So when you go to Google's landing page, it is just one source button,  and it's a white screen, and it is beautiful on the way that it works if just because  you have more and more features, it doesn't make a software pleasant to use.  So the idea here is, in Agile, you're also thinking about the outcome, like, what,  what kind of outcome are you looking and you can do that by building less and  less and delivering more. Got 

Jeremy - it so making sure that you're delivering value on everything that you're building, not just building something or creating something to create it definitely  agile. Principle number 11, the best architectures, requirements and designs  emerge from self organizing teams. Principle number 11 is all about self  organizing teams. Vivek, yeah, so  

Vivek - in Agile teams, where the teams are self organizing and cross  functional, meaning, depending on what kind of project you're working on, you're gonna have people with the right skill sets, and that's what a team is formed off.  Is everybody in the team has unique skill sets, and they have what it takes to  make this project successful. So when they need something, a question about  an architecture, they already have somebody in that team so they can actually  talk to somebody, versus borrowing somebody from somebody else. Yeah, I  

Jeremy - know in waterfall or in other methodologies, a lot of times you need to  go ask a manager, Hey, can I have somebody from your team, from your testing  team to help out with this, and usually takes a long time where an agile with it  being self organizing. If you need somebody, you can go tap them on the  shoulder and see if they have availability to come help your team or to join the  team. Potentially, definitely agile. Principle number 12, at regular intervals, the  team reflects on how to become more effective, then tunes and adjusts its  behavior accordingly, and last but not least, reflect and adjust Vivek, what do  you think this  

Vivek - is actually one of the key principle of agile, that one of my favorite  principles of agile as well. So as you're working in a product as a team, you're  gonna learn different things about each other ways of working. So at each  interval, like every two, three weeks, you're getting back and you're looking at  what went well, what didn't go well, and how can we improve? And this is a key  principle of agile,  

Jeremy - yeah, and I think in waterfall, reflect and adjust. Is there as well? Like  waterfall, or any other methodologies, they want to reflect and get better and  change and adapt. But the challenge is, in a waterfall project, you have that at  the end of the project that could be three months, six months, 12 months from  the time you start a project, and it's just too long. You don't get enough time to  reflect and adjust. Where agile, with it being more iterative. Every few weeks,  you're actually able to look in See how it's going, and make adjustments as  necessary to make the team even more successful. 



آخر تعديل: الاثنين، 3 فبراير 2025، 8:34 ص