Understand Agile Principles

0:00This skill is focused on the Agile Manifesto, which is a set of core values and guiding principles for Agile project management practices, and my goal is that by the end of the skill you're going to be very familiar indeed with those values and principles. But anyway, we already know that Agile is the principle of software development based on iterative and incremental development, but as we also know, there are different ways of being Agile. There's a number of different methodologies and frameworks.

0:30There are lots of different ways to actually be Agile, and all of these have evolved since Ag ile as a project management approach was first born back in 2001. And all of these different frameworks and methodologies all apply and interpret the core values and guiding principles of the Agile Manifesto in different ways. So the values and principles that we're going to look at in this skill was the kind of the fundamental guidance that then developed or evolved into these different flavors of Agile. So you can see here from the PMI 's brief history of Agile that when that bunch of software developers put their heads together back in 2001 to solve the problem of traditional project management methods not being well suited to software development projects, that the output of this brainstorm was the Agile Manifesto.

1:18Now I have put a link to this PDF from the PMI that you're looking at here in the skill, but I'm not saying it's an especially important document for you to have a look at at all. But you know what it's like if you haven't got it, you're always left thinking, "Oh, I'm sure that would have been a really terribly useful document if only I had the link." But much more usefully for us though in this skill is the official home of the Agile Manifesto. You can see it here, AgileManifesto.org, of course I've given you that link in the skill. And these are the four core values that we're going to look at in some detail in the next video, but look, there are also rather exciting 12 principles of Agile software .

1:55And I absolutely love these and these will form the bulk of what we will talk about in this skill and I'll be grouping them into related topics just to make them a little bit more digestible for us to go through them. So by all means have a quick look at this website and obviously this will be your main reference for the manifesto itself, but you can also see there's a bit more information about the authors and a bit of history about the Agile Manifesto. But I think really another useful resource for you for this particular skill is the Agile Alliance website.

2:26In particular I love this Agile Glossary that you're looking at here and you will find this on the Agile Essentials menu, there we go, Agile Glossary. And this also gives you links to the Agile Manifesto and those 12 principles. So you may prefer this website, but I'll give you those two resources for you to use as required as we start learning about these values and principles of Agile. Now there is something else I should mention before we crack on and learn about those values and principles is that if you are watching this with a view to preparing for the PMIs Agile Certified Practitioner exam, please be aware that you're not going to be tested on this content directly in the exam.

3:03So you're not going to get questions such as, "Which is the seventh Agile principle?" No, no, no. It's much more subtle than that. You're going to need to be able to understand and apply the principles. So our emphasis in this skill isn't going to be about simply learning them off by heart. It's going to be more about developing an Agile mindset in order to help you to spot the right answer in the exam. So you can imagine with a multiple choice question, you might get four possible answers to choose the right answer from. And hopefully there's one complete nonsense one you can disregard.

3:36So that leaves three. Hopefully one of those three after a bit of thought you can also disregard. But very often you're left with two very feasible sounding answers. Well, a good solid understanding of these core values and guiding principles will help you identify which one of those two remaining answers is the most Agile. And also please be aware that although as we go through these values and principles, because they were developed with a view to improving projects for software development, in the exam these principles will be applied to different scenarios, not just software development.

4:10So bear that in mind. Even though I will be generally using software development examples because they're the clearest ones to highlight the Agile principles. And although it's not really an exam tip as such, please also be aware that as we progress through this course, I shall be referring back to these principles time and time again as we learn more about Agile. So really from this short introductory video, I've got just a couple of key takeaways for you. So yes, these values and principles that we're going to learn about are at the heart of all of those different Agile frameworks.

4:41They've all used that as their basis for the methodology that they promote. As we go through these values and principles, remember that they can apply to other environments, not just software development. Remember the exam won't test you on these principles directly, but you really do need a thorough understanding of them. And those are your references that I pointed you to earlier on in this video. But anyway, let's crack on and learn about these values and principles.

0:00In this video, we'll take a look at the four core values of Agile as outlined in the Agile Manifesto. And you can see them listed here, there are four of them, and although we will go through them one at a time, just a quick note about how they are worded. So you can see at the top here it says, "We value," and then number one, " individuals and interactions over processes and tools." So as we will see as we go through them, each value has kind of got two halves to it. The bit in the green on the left-hand side is the bit that we prioritize.

0:31And it's not saying that we don't need the things on the right, it's just that the things on the left are more important. The items in green is what should take the priority in an Agile environment. So let's start with number one here, "We value individuals and interactions over and above processes and tools." Now that's not to say that we shouldn't have processes and tools, but simply that we should be prioritizing face-to-face human interactions above them. We shouldn't be blindly following workflows at the expense of having an actual chat with someone.

1:03Now, of course, it is likely that we do still need some processes and tools in our project environment to give our works and structure and to provide some efficiencies. But a really important shift in mindset here is to understand the importance of people in these kinds of projects. That's what this bit here is saying. We need to prioritize the actual human beings and the interactions between them and push processes and tools a little bit into the background, treating them as a support to those people.

1:34And if you think about it, this does make sense because with knowledge work, our biggest asset is our people. That knowledge work is coming out of their heads, isn't it? And problems are solved by people. So knowledge work is much more people-y, if that is a proper word, is much more people-y than industrial work. So therefore, given that these types of projects are more people-y, if a tool or a process gets in the way of that person doing their best work, then why have we got that process or tool?

2:04We need to rethink. So it is a shift in mindset. And also, taking this even further, our customers and the end users are people as well. And this first value does sometimes upset people a little bit. I mean, look at this poor chap here. He's saying, "Oh, but people are complicated and unpredictable. Human interactions are messy. I don't like it. I need a tidy, inanimate process or a tool to give me some structure and some predictability." But with knowledge work, that work, as I said, is coming out of people's heads, we need to change that mindset.

2:40I mean, yes, people are complicated, but that's why they can create innovative solutions. And fine, we can have processes, but only if it supports, rather than supp resses or hinders our people from doing their work. And that's why we need to keep a really open mind about that. Do you see, it's a shift of balance here. How often do we find people's creativity curbed because they have to work within a process that's perhaps outdated and maybe we can't even remember why we've always done it that way.

3:11Let's turn it on its head and prioritise individuals and interactions over and above processes and tools. Now, the second value is that we prioritise, as you can see here, working software over and above comprehensive documentation. Because traditionally, we would have seen heaps and heaps of documentation being produced before the product is released for testing. But here, with Agile, we're saying, "Well, actually, working software is more important."

3:41And so at the end of the iteration, we need just enough documentation and we need software that actually works. Remember, our goal at the end of each iteration is a working product increment. For sure, we might need some documentation, but not at the expense of creating software that works. The documentation by itself simply isn't useful, whereas working software absolutely is. Now, when we say just enough, we really do mean that and you'll sometimes see this described as barely sufficient.

4:13So we really want to keep our efforts focused on the thing that we're building. Let's not distract ourselves with writing documentation for an interim version of the product, because remember, we are delivering incrementally, aren't we? And so the documentation we might be creating now for this increment might not actually be that important for the overall product anyway. And again, for some teams, this is going to be quite a shift in mindset and we might even need to reset expectations of those around us as well. And we need to agree what exactly constitutes the term just enough or barely sufficient for our particular environment.

4:49And so therefore, because we're developing incrementally the documentation that we do produce, we produce just in time, sometimes described as the latest responsible moment, which I rather like, because we're expecting things to change, aren't we? It's not sensible to create documentation in advance ahead of changes that we know are inevitably around the corner. And so yes, we produce barely sufficient documentation only just in time whilst still fulfilling our needs.

5:20And those needs will vary depending, for example, what industry we work in. Because of course, there will be some industries where we do have much more regulatory documentation to deal with, so that needs to be taken into account when we are defining what just enough actually means for us. But you might even get particular stakeholders that particularly need a certain type of documentation or a certain level of detail at various points. Again, that's going to help us define what just enough means for us, given the particular stakeholders that we need to work with.

5:52But don't get complacent with this value, because sometimes I get people saying , "Well, that's just fantastic. We love that. We hate writing documentation anyway." But here's the thing. If you have skimped on documentation and your system doesn't work, then something's not right. The software needs to be working. That's our primary measure of progress, isn't it? And we do still need enough documentation. Okay, value number three is that customer collaboration trumps contract negotiation.

6:25Now, as before, we're not completely dismissing what's on the right-hand side here, so we're not dismissing having a contract altogether, because there will, of course, be elements of how we work that we might need to tie down contractually. But the contractual side of things should not extend to locking down all of the product details when the project hasn't even started. So we are expecting to collaborate with the customer to find the best solutions as we go along and as things evolve, because we can't be flexible if we've locked into that set of signed-off requirements.

6:58It's at the beginning of the project. Look, we don't want our poor customer to be thinking, "Well, you know, this list of requirements I've just signed off, and let's just hope that the product really does fit the bill by the time we actually come to get to release it." And as we know, this is the whole point of agile, isn't it? We do not gather all of those product requirements upfront and get it signed off and fiercely limit changes like we might do for an industrial product. No, with knowledge work, we develop incrementally. We get feedback on which we base our next steps and where do we get that feedback from?

7:32In order to support those inspect and adapt activities, well, we get that feedback from the customer. But look, I do acknowledge that this is easier said than done, because it can be very unsettling not to have that full clarity upfront. But it is another change in mindset and we need to really think about this because environments where things do change quickly, we have to work differently. This is the reality with knowledge work these days. And we can therefore address some of this discomfort that our poor little man is speeding here about not having a signed off list of requirements by remembering that typical agile life cycle.

8:10Do you remember this slide? With the yellow bit there, the yellow arrows representing the repeating iteration. But before we get to that point, we have established a vision. And that's going to be very useful for getting everybody on the same page as to what generally we are hoping to achieve with this product. And then the product roadmap, again, another useful tool for communicating to everybody involved to help us understand what we're aiming to achieve when. So once we've got our head around the idea of continually collaborating with the customer with regards to what we're actually producing, then yes, we can see that the development of our product or system will be much more of a flexible, collaborative partnership between us and the customer than a traditional contract would allow for.

8:56A normal contract simply wouldn't have provision for that sort of flexibility. Right, our final value is an easy one. We value responding to change over and above following a plan. So yes, when we're agile, we do understand that we are expecting changes, we welcome changes. But of course, we do need to plan what we're going to achieve in the very short term, but we are building software for today, not tomorrow. So it is a waste of time and effort to produce those enormous plans that try to predict two years into the future. So agile, of course, recognizes that these kinds of projects are unpredictable and there will be changes.

9:31And so you will remember from that typical agile lifecycle slide yet again that for sure we've done some of this high level planning, but then we get down to the detailed planning when we get into our iteration or our sprint. We only plan and commit to small chunks of work at a time. That's how we handle these unpredictable changing environments. So I think your key takeaways then for this video is simply going to be that set of four values from the manifesto. Remember, we're not saying that we don't need the things on the right, it's just that the things on the left in green are more important.

10:09So keep all of this in mind as we dig deeper into the 12 principles of agile. [BLANK_AUDIO]

0:00This is the first of a handful of videos in which we'll be chatting about the 12 principles of Agile. And to save us laboriously plugging through them one at a time, from principle number one straight through to principle number 12, I have arbitrarily chopped them up into groupings that kind of make sense to me . And there would be lots of different ways of organising them, of dividing them up. It doesn't really matter. What's important is that by the end of the skill that we have talked about all 12 of the principles, which you can see here. So this first grouping of three principles that we're going to cover in this video, I have called delivering value, and I have pulled out numbers one, three and seven from the list here, and that feels manageable to me for a single video.

0:42So let's start with this first one, which is also top of the list of 12, it's principle number one. And if there is one principle which sums up Agile, then I think this has to be it. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. But let's unpick this a little bit further. So yes, we want to satisfy the customer. That sounds obvious, doesn't it? But we're talking about the actual customer, the person who's paying for this product, the person who's sponsoring it.

1:14So we're not aiming to satisfy, I don't know, our IT director or the project management office. So we need to keep focused, don't let internal politics get in the way. It sounds easy, doesn't it? But it is hard sometimes to keep that clarity when there's other stuff going on and other pressures. Oh, and also don't forget that our customer might be internal or external. If we're creating a product for another department, then that would be an internal customer. But if it's another organization that we're creating the product for, then that would be an external customer. So yes, we're satisfying the customer through, look at this early delivery.

1:48So we need to be brave enough to share early work, to share draft work. And that does take a bit of courage and a bit of bravery. But we know that we need to uncover problems early on so that we do have time to fix them. That's the agile way, but it can take a while to get used to that. And we're also delivering continuously. So compared to an industrial project where we might only be delivering either at the very end of the project, if it's a smallish project, or maybe just here and there at the end of every major phase, with agile, we're aiming to be delivering value continuously.

2:22And yes, it does need to be valuable software or valuable bits of the product in general. So not plans, not designs, not user manuals or other documentation, valuable bits of product, valuable bits of the actual thing that we're building. And that does all sound jolly marvellous, but how do we do that? Well, the mechanism through which we deliver working software continuously is through those iterations, which we already know about. And so here's our next agile principle. We deliver working software frequently from a couple of weeks through to a couple of months with a preference to the shorter time scale.

2:57As I said, generally across the different agile frameworks, this principle is interpreted by working in iterations or in sprints, if we're talking about Scram, those short bursts of work, and the shorter time scale does generally mean that we're talking about weeks here. And typically when we do work like this, the assumption is that these iterations are time-boxed. That means that they're all the same length each, and I tend to use the example of every iteration being, say, two weeks long. Can ban, remember, though, is a little bit different.

3:28That's flow-based agile rather than iteration-based agile. But the idea of delivering working software frequently is really important for two key reasons here. So firstly, it's going to be crucial for frequent testing and frequent feedback . As we said with the last principle, it does take a little bit of courage and a shift of mindset to deliver frequently. It's so tempting, isn't it, to kind of hold on to something until it's as perfect as possible before we present it for feedback. But we need to let that go. We are all on the same team here.

3:59Let's get it working. Let's get feedback. Let's keep moving forward. That's how we're going to deliver value. And also, delivering software continuously is going to be fabulous for ongoing customer engagement. Do you remember this slide here from the last video? Let me just flip to it where we talked about those four core values. We said that we value customer collaboration. So this project is a partnership between us and the customer. We're on the same team. It's not them and us. And so delivering software frequently does support this.

4:29And so finally then, for this video, I have picked principle number seven here. Working software is our primary measure of progress. It sounds so simple, doesn't it? And so obvious. But as with all of these things, putting them into practice is often much harder than you might first think. And again, we mentioned this, didn't we, with the core value? Let me flip back to that from the video where we talked about those four core values where we said that, yes, we value working software over comprehensive documentation. Working software is actually useful and valuable, but complete documentation on its own is not.

5:02So yes, working software is our primary measure of progress, but there are a couple more points I'd like to put out here. So firstly, this principle gets us to shift our focus to actually doing stuff rather than planning and strategizing. And this does suit some personalities better than others. So someone like me, I am a doer. I'm very tactical. I get frustrated and bored with too much planning and too much strategizing. And that didn't do me any favors early on in my career. When exhaustive planning was very much the fashion.

5:33But of course, that means I'm very well suited to working in an agile environment. And secondly, note that partially completed work doesn't count in agile. This is quite an interesting concept because if a feature can't be tested, that means the customer can't accept it and it can't be considered to be complete. So all of this is going to help us to drive forward. It keeps us striving for working software, not fancy plans or strategies. Okay, I think those three principles are enough for one video.

6:03So here's our overall list of 12. The green ones are the three that we've just talked about. And so go and grab a coffee and I will see you in the next video for a couple more.

0:00In this video, we're going to tackle another couple of those 12 Agile principles, which I have grouped together under this heading of Embracing Change, which is certainly, as we have come to learn, a really important theme in Agile. And so the two principles that I'm going to pull off our list for this particular video are numbers 2 and 10. You can see them here. And we'll start with number 2. Let me just hide the other one for a second here. But you can see here that yes, in Agile, we welcome changing requirements, even late in development.

0:31Agile processes harness change for the competitor's customer advantage. I seem to have turned that into my very own tongue twister there, didn't I? No, I mean, it's the customer's competitive advantage. But yes, I think we've already got the point, haven't we, that with Agile, we do positively embrace we welcome changing requirements. Bring them on. We take the view that requirements are meant to be discovered, not dreamt up in advance. And so it's not about signing off a list of requirements in advance like we would do with an industrial project.

1:02Look at this little cartoon here. In those traditional projects, changes are really discouraged. And it's a very brave customer indeed, who, late in the day, wants to implement something that's only recently come to light, something new that wasn't on that original list of requirements. And while I know that Agile has been around for a while now, don't underestimate how radical it is that with Agile, we truly do welcome changes, even late in development. Very often, those traditional non-Agile project management environments have got such closely controlled change management processes that it makes any change really quite an ordeal and potentially somewhat problematic as per my cartoon here.

1:45But of course, the incremental and iterative nature of product development in Agile has been designed to incorporate change. So we don't suppress it or restrict it or discourage it. No, every iteration is an opportunity to explore changes. And in case it is obvious why welcoming change is a very, very good thing indeed for the customer, having a way of working, this approach that expects change creates a competitive advantage for the customer because it means we can react very fast to changing or emerging market conditions.

2:20We can keep up with the changing world of technology or whatever unpredictable or fast-changing environment that we happen to be operating in. Remember that product backlog? That's how we manage scope and changes in Agile. We are continually re-prioritizing and shuffling items on this list here. We're adding new things to the list. As new things come to light. We're removing things from the list, which are no longer needed. It's a brilliantly elegant way to handle changes. So Agile provides us with this really efficient method to deal with inevitable changes.

2:54And so clearly, it's going to give our customer a competitive advantage if we can respond to changes and re-prioritize the features that we develop as new information comes to light. Whether that information has come from feedback on the working software that we 've produced so far or from changing conditions of the environment that we're working in. Now another aspect of Agile to help us welcome and respond to change, the other principle that I picked out to mention in this video is principle number 10 here. Simplicity, the art of maximizing the amount of work not done is essential.

3:29So Agile very much promotes simplicity. Build only what the customer has asked for. Build it well. And don't add all of those bells and whistles that they don't need. And I think of this as kind of concentrating on the vanilla flavour of our product first. We can cautiously add more flavours as and when it becomes apparent that that is what we need. But our focus is to create a really good vanilla flavour. A strong skeleton if you like of the simplest possible configuration that actually works.

3:59And if you think about it, the more complexities we add, the longer the project is going to take and we also start to introduce risk because it's more likely to go wrong if it becomes more complex. And so the less simple we make our product, the less Agile we become. Simplicity frees us up to be able to respond to change in the way that Agile is designed to do. And so from a design perspective, this means that we do not build the all-en compassing infrastructure or design that will support every possible feature.

4:30No, we keep it simple. For sure, we need to be responsible enough to make sure that we don't end up with something that prevents future development. There is a balance to be struck here, but we must forever keep in our minds, don't waste time doing work that's not needed. Build software for today, not tomorrow. Because as discussed, we're not entirely sure yet what tomorrow's requirements will be. Who knows what the future has in store. Right, that's another two principles off our list of 12 here. Stay with me for the next video and we'll look at a few more.

0:00In this video we'll take a look at some of my favourite Agile principles, the ones where we focus on the people on our project team. And for that reason I always call them the 'peeple principles'. Although it troubles me as to whether this made up word 'peeple' should have that 'e' towards the end there or not. So from our list of 12 principles we've talked a little bit about the ones in green already and the people ones for this video are values 4, 6 and 5. You can see them here, we'll start with the top ones, I'll just hide the other two for now. And you can see that this principle states that the business people and developers should work together daily throughout the project. We don't want any disconnect between what the business needs are and what the developers are actually doing. It's a joint effort to remember. And it's worth pointing out here that when we say 'business people' as per the principle, we're meaning the customer or some kind of business representative who represents the needs of the customer. For example in the Scrum framework this would be the product owner role. In other environments it might even be a business analyst or something.

1:04But the point is with Adjile it's not a case that the customer hands off the project to the development team and only makes an appearance at infrequent check-ins. No, the customer or the business representative needs to be fully engaged so that they can make informed decisions about features and release dates and whatnot. And according to this principle when I say fully engaged that means daily contact. And so we can certainly say that Adjile therefore is much more dependent on customer engagement than traditional projects. That high degree of change that we are expecting with Adjile, you know it needs total transparency when it comes to feedback. We need to surface any problems or misalignments as they happen and that requires continual engagement. And you can really see the difference here if you were to plot customer engagement over time on a graph. Now this is a simplistic view but the point being that with traditional plan-based life cycles on the right here we will often see yes high engagement at the very beginning when we're gathering project requirements and whatnot. And then we go off and do the work with limited engagement with the customer until it comes to getting things signed off and accepted towards the end of the phase or the end of the project or a particular milestone or whatever. But of course with Adjile on the left here we're

2:21maintaining high levels of customer engagement throughout. It's continual engagement as depicted by the straight blue line there and it reinforces the idea that we are all on the same team. It's not them and us when it comes to the customer and the development team. We're a partnership, we're working in the spirit of co-creation as it were. Now I think this principle is sometimes really rather difficult to achieve in real life but it is worth the effort because it can make a really big difference in the degree to which the developers come to understand the business needs that they are solving with the product that they're building and of course the better they understand the problem then the better the thing will be that they're building to address it. Principle number six here says that the most efficient and effective method of conveying information to and within the development team is face-to-face conversation and this fits in well doesn't it? With that first of the four core values that we learned about from the Adjile Manifesto that individuals and their interactions are valued above processes and tools and so the best way to handle achieving this particular principle will be through co-location of the team. So that means that ideally we expect the team to be physically located

3:36together. Now in recent years with the COVID-19 pandemic and whatnot more and more people are working remotely so yes technology can certainly help us out here but ideally the team is co-located so that they can physically have these face-to-face conversations because it is much more efficient to just look up and ask a question across a desk rather than compose an email and wait for a response so we're getting answers quicker and since we're interacting in person with the full range of human emotions and personality quirks and body language and humor and whatnot rather than a written email which is kind of one-dimensional isn't it compared to actually speaking to someone if we're having those interactions in person then we will build better relationships.

4:22Now it does become harder to maintain face-to-face conversations as our number one communication method as we scale Adjile for bigger more complex projects and therefore will have larger or multiple teams but we should never forget the benefits of having a face-to-face conversation and then finally for this video principle number five here this principle promotes creating an empowering environment it says that we should build projects around motivated individuals give them the environment and the support they need and trust them to get the job done so there's no micromanagement we trust the team to do the work people work better when they're given autonomy to get the work done in the way that they decide to get the work done this knowledge work is coming out of people's heads remember we've hired them for their expertise so we don't tell them how to do the work but that doesn't mean that we just kind of lock them in a room and tell them not to come out until they finished no we support them and that means creating an environment for them to enable them to do their best work so we help to remove obstacles and we answer questions and this is as we'll learn another time where the role of scrum master from the scrum framework can really come into full play here so we aim to create an

5:39environment of trust and openness and respect in order to motivate and inspire team members which sounds wonderful but it is easier said than done of course but don't forget with knowledge work projects our people are our biggest asset it's worth the effort we need to support them so there we go that's the three peopleie principles for you and I think that leaves just four from our list of 12 which we're going to cover over the next couple of videos.

0:00In this video, we'll chat about two of our 12 principles, which promote some interesting and unique working practices of Agile. So here's our list, and the ones that we'll pick out for this video are principles number 11 and 8. Here they are, and we're going to come back to principle 8 in a second though, so I shall just hide that one for now. And you can see here that principle 11 states that "the best architectures, requirements and designs emerge from self-organizing teams".

0:31And to me, this is very much a progression of one of those people-y principles that we looked at in the last video. This one here, do you remember, we said that people work best when given autonomy, and we need to provide them with a supportive environment to enable them to do their best work rather than micromanaging them? Well, the working practice that helps us to achieve this is to have, as this principle says, self-organizing teams. And this is a really interesting principle, because it allows the team to therefore find the best approach for them.

1:01It allows them to find the best architecture, the best designs that they are going to be able to work with moving forward to deliver the product. And while that might be best for the team, it's also going to be best for the overall product itself, because the team are going to have increased buy-in, and ownership and pride therefore in the work that they do. Because, believe you me, there is nothing more annoying as a team member than having something imposed on you that you think is a stupid idea. So imagine these team members being told that they have to develop according to this architecture or according to that design that they think is stupid, then they're not going to be doing their best work, are they? They're not going to be working on it with their whole heart if they think that the ideas that have been forced upon them are idiotic.

1:41But if the team members themselves are responsible for finding the best solution, you know, the best architecture, the best design for what they're supposed to achieve, then they have that ownership of the solution that's going to keep them happier and it's going to create better work. And at the end of the day, they should be the ones to organize how they're going to do this, because they are the ones with the deepest technical knowledge, so it does make good sense. And so a good agile team should have their freedom to take its own direction. They find their own way. Now, it might take time for a brand new team of people who haven't worked together before. It might take a bit of time for them to find their own direction.

2:18And it might take time for everybody else in the organization to get used to the idea that the team self-organizes. But it is really amazing how creative a self-organizing or a self-managing team can be at solving problems and how fast they can move when they are empowered to just get the job done their way. Okay, the other one on our list for this video was principle number eight here. So it says, "Adjal processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely."

2:51So it's suggesting that we should strive to work at a sustainable pace. We should find a steady working rhythm that we can maintain long term. So it's not about working as hard and as fast as we can every single day. No, our competitive edge is going to come from being able to respond to change, remember, not from working at breakneck speed. So agility does not mean speed. Agility means being able to respond and make changes. And this is of course a benefit therefore of working in those sprints, those iterations.

3:23Every sprint is the same length. It's going to set a pace for us. It's going to give us a cadence for our work because we don't want burnout. We want happy team members. I say it again. Our people are our most important asset and we want them to find a good working balance. And it is interesting actually to compare this principle to the working pace that we often see in traditional non-adjal projects. So let me just sketch up some axes here. So imagine we've got a 12 month project running from January to December with the amount of work completed up the side here.

3:56And when we start off we might be working at quite a leisurely pace, but as the deadlines loom we suddenly have a surge of productivity. At the end there everything gets a bit frantic. We're all working overtime in order to get it finished on time for the December deadline or whatever it is. So we might see that surge of productivity at the end of the project on a miniature scale at the end of each iteration when we realize, "Oh my goodness, this has to be working by Friday." But it is on a miniature scale and it shouldn't be as intense as we might see for a traditional project where that surge of activity takes place over a few weeks at the end of the project.

4:30Having said that though, if workers do find working in sprints are too intense, they're finding too much pressure trying to get working software completed at the end of the sprint. Then we might need to rethink how much work we can realistically fit into a sprint, but more on that another time. Our focus here is to understand that Agile promotes a sustainable, maintainable working pace. So I think that's enough for this video. That means we've just got two principles left for the last video in this skill, and so I shall see you there.

0:00In this video, we'll take our last look at the Agile principles with a couple which promote continuous improvement. And since there are only two left on our list that we haven't yet talked about, then obviously the two of interest to us for this video are the ones that we've got left, numbers 9 and 12 here. So let's start with principle number 9 which says that continuous attention to technical excellence and good design enhances agility. And I think this is reminding us that behind all of this Agile talk, now I did kind of do air quotes around Agile talk, but behind all of this Agile talk, we should have some really solid foundations in excellent technical practices.

0:40Because I do occasionally get folks saying to me, "Oh yeah, all of this Agile stuff, it kind of seems a bit sloppy to me. I mean, we don't have to produce any documentation. The team can design the product however they fancy. And you tell me that simplicity is important. That sounds like a pretty easy gig to me. But my goodness, we've got to be really careful here because some of those other principles which might seem like shortcuts, well, they only work if we do pay continuous attention to technical excellence.

1:10Technical excellence should be our normal state with Agile projects. Otherwise, we simply don't have a viable product which makes everything else we 've talked about, totally redundant. And talking of technical excellence, you might remember from when we were looking at some of the distinguishing features of some of the different Agile frameworks, you might remember XP, extreme programming. And this is best known for its set of software development best practices. And we'll talk about more of these another time, but certainly for us in talking about this principle, we're talking about things like, developers don't wait until another time in order to clean up confusing or redundant code.

1:45Code gets better with every iteration. And we have shared ownership of the code . We all take responsibility for the technical excellence. And we create good design that accepts those inevitable changes that we know around the corner. The design we come up with should accept those changes gracefully. And our final value then, number 12 here, says that at regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly. So what we're saying here is that as a team, we regularly reflect on not just our work and our technical practices to look for improvements, but also to tweak and improve our behavior, our relationships, our processes and even our mindsets as well.

2:29Because working on an Agile team does present some tremendous opportunities for personal growth because we do have those inspect and adapt activities just kind of built into the philosophy of Agile. And if I just remind you of that typical Agile lifecycle that we've seen before , the type of activity that we're referring to here could be the sprint retrospective where we examine ourselves, our processes, our environment, our relationships, what went well and what didn't. And what can we do to improve our effectiveness for the very next sprint or iteration?

3:02And with that, my goodness, I think we've done it. That's our 12 principles of Agile completed. Now, I am aware that there was a lot to take in there, but I will be referring back to many of these as we progress through further skills. But for now, I hope this has been informative for you, and I'd like to thank you for viewing.