Understand Agile Principles

0:00This skill is focused on the Agile Manifesto, which is a set of core values and

0:06guiding

0:06principles for Agile project management practices, and my goal is that by the

0:11end of the skill

0:12you're going to be very familiar indeed with those values and principles.

0:16But anyway, we already know that Agile is the principle of software development

0:21based

0:21on iterative and incremental development, but as we also know, there are

0:26different ways

0:27of being Agile. There's a number of different methodologies and frameworks.

0:30There are lots

0:30of different ways to actually be Agile, and all of these have evolved since Ag

0:35ile as a

0:36project management approach was first born back in 2001. And all of these

0:40different frameworks

0:41and methodologies all apply and interpret the core values and guiding

0:45principles of the

0:46Agile Manifesto in different ways. So the values and principles that we're

0:50going to

0:50look at in this skill was the kind of the fundamental guidance that then

0:54developed or

0:55evolved into these different flavors of Agile. So you can see here from the PMI

1:00's brief history

1:01of Agile that when that bunch of software developers put their heads together

1:05back in

1:052001 to solve the problem of traditional project management methods not being

1:11well suited to

1:11software development projects, that the output of this brainstorm was the Agile

1:17Manifesto.

1:18Now I have put a link to this PDF from the PMI that you're looking at here in

1:22the skill,

1:23but I'm not saying it's an especially important document for you to have a look

1:26at at all.

1:27But you know what it's like if you haven't got it, you're always left thinking,

1:30"Oh,

1:30I'm sure that would have been a really terribly useful document if only I had

1:33the link."

1:34But much more usefully for us though in this skill is the official home of the

1:38Agile Manifesto.

1:40You can see it here, AgileManifesto.org, of course I've given you that link in

1:43the skill.

1:45And these are the four core values that we're going to look at in some detail

1:49in the next

1:49video, but look, there are also rather exciting 12 principles of Agile software

1:55.

1:55And I absolutely love these and these will form the bulk of what we will talk

1:58about in

1:59this skill and I'll be grouping them into related topics just to make them a

2:03little

2:04bit more digestible for us to go through them.

2:07So by all means have a quick look at this website and obviously this will be

2:10your main

2:10reference for the manifesto itself, but you can also see there's a bit more

2:13information

2:14about the authors and a bit of history about the Agile Manifesto.

2:18But I think really another useful resource for you for this particular skill is

2:23the Agile

2:23Alliance website.

2:26In particular I love this Agile Glossary that you're looking at here and you

2:29will find

2:30this on the Agile Essentials menu, there we go, Agile Glossary.

2:33And this also gives you links to the Agile Manifesto and those 12 principles.

2:38So you may prefer this website, but I'll give you those two resources for you

2:41to use

2:42as required as we start learning about these values and principles of Agile.

2:47Now there is something else I should mention before we crack on and learn about

2:50those values

2:51and principles is that if you are watching this with a view to preparing for

2:55the PMIs

2:56Agile Certified Practitioner exam, please be aware that you're not going to be

3:00tested

3:00on this content directly in the exam.

3:03So you're not going to get questions such as, "Which is the seventh Agile

3:07principle?"

3:08No, no, no.

3:09It's much more subtle than that.

3:11You're going to need to be able to understand and apply the principles.

3:15So our emphasis in this skill isn't going to be about simply learning them off

3:19by heart.

3:20It's going to be more about developing an Agile mindset in order to help you to

3:24spot

3:25the right answer in the exam.

3:27So you can imagine with a multiple choice question, you might get four possible

3:31answers

3:31to choose the right answer from.

3:33And hopefully there's one complete nonsense one you can disregard.

3:36So that leaves three.

3:37Hopefully one of those three after a bit of thought you can also disregard.

3:40But very often you're left with two very feasible sounding answers.

3:44Well, a good solid understanding of these core values and guiding principles

3:49will help you

3:50identify which one of those two remaining answers is the most Agile.

3:55And also please be aware that although as we go through these values and

3:59principles,

4:00because they were developed with a view to improving projects for software

4:03development,

4:04in the exam these principles will be applied to different scenarios, not just

4:09software

4:09development.

4:10So bear that in mind.

4:11Even though I will be generally using software development examples because

4:14they're the

4:15clearest ones to highlight the Agile principles.

4:18And although it's not really an exam tip as such, please also be aware that as

4:23we progress

4:23through this course, I shall be referring back to these principles time and

4:28time again

4:28as we learn more about Agile.

4:31So really from this short introductory video, I've got just a couple of key

4:34takeaways for

4:35you.

4:36So yes, these values and principles that we're going to learn about are at the

4:39heart of all

4:39of those different Agile frameworks.

4:41They've all used that as their basis for the methodology that they promote.

4:46As we go through these values and principles, remember that they can apply to

4:50other environments,

4:51not just software development.

4:53Remember the exam won't test you on these principles directly, but you really

4:57do need

4:57a thorough understanding of them.

4:59And those are your references that I pointed you to earlier on in this video.

5:04But 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

0:05in the Agile

0:06Manifesto.

0:07And you can see them listed here, there are four of them, and although we will

0:10go through

0:11them one at a time, just a quick note about how they are worded.

0:14So you can see at the top here it says, "We value," and then number one, "

0:17individuals

0:18and interactions over processes and tools."

0:22So as we will see as we go through them, each value has kind of got two halves

0:26to it.

0:27The 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

0:33the things

0:34on the left are more important.

0:36The items in green is what should take the priority in an Agile environment.

0:41So let's start with number one here, "We value individuals and interactions

0:46over and

0:46above processes and tools."

0:49Now that's not to say that we shouldn't have processes and tools, but simply

0:52that we should

0:53be prioritizing face-to-face human interactions above them.

0:58We shouldn't be blindly following workflows at the expense of having an actual

1:02chat with

1:02someone.

1:03Now, of course, it is likely that we do still need some processes and tools in

1:07our project

1:08environment to give our works and structure and to provide some efficiencies.

1:13But a really important shift in mindset here is to understand the importance of

1:18people

1:18in these kinds of projects.

1:20That's what this bit here is saying.

1:22We need to prioritize the actual human beings and the interactions between them

1:26and push

1:27processes and tools a little bit into the background, treating them as a

1:32support to those

1:33people.

1:34And if you think about it, this does make sense because with knowledge work,

1:38our biggest

1:39asset is our people.

1:41That knowledge work is coming out of their heads, isn't it?

1:44And problems are solved by people.

1:46So knowledge work is much more people-y, if that is a proper word, is much more

1:50people-y

1:50than industrial work.

1:52So therefore, given that these types of projects are more people-y, if a tool

1:57or a process

1:58gets in the way of that person doing their best work, then why have we got that

2:03process

2:03or tool?

2:04We need to rethink.

2:05So it is a shift in mindset.

2:08And also, taking this even further, our customers and the end users are people

2:11as well.

2:13And this first value does sometimes upset people a little bit.

2:17I mean, look at this poor chap here.

2:19He's saying, "Oh, but people are complicated and unpredictable.

2:23Human interactions are messy.

2:26I don't like it.

2:27I need a tidy, inanimate process or a tool to give me some structure and some

2:32predictability."

2:33But with knowledge work, that work, as I said, is coming out of people's heads,

2:38we

2:38need to change that mindset.

2:40I mean, yes, people are complicated, but that's why they can create innovative

2:46solutions.

2:47And fine, we can have processes, but only if it supports, rather than supp

2:53resses or hinders

2:54our people from doing their work.

2:56And that's why we need to keep a really open mind about that.

2:59Do you see, it's a shift of balance here.

3:01How often do we find people's creativity curbed because they have to work

3:05within a process

3:06that's perhaps outdated and maybe we can't even remember why we've always done

3:10it that

3:10way.

3:11Let's turn it on its head and prioritise individuals and interactions over and

3:16above processes

3:17and tools.

3:18Now, the second value is that we prioritise, as you can see here, working

3:22software over

3:24and above comprehensive documentation.

3:27Because traditionally, we would have seen heaps and heaps of documentation

3:31being produced

3:32before the product is released for testing.

3:36But here, with Agile, we're saying, "Well, actually, working software is more

3:41important."

3:41And so at the end of the iteration, we need just enough documentation and we

3:46need software

3:47that actually works.

3:48Remember, our goal at the end of each iteration is a working product increment.

3:53For sure, we might need some documentation, but not at the expense of creating

3:58software

3:59that works.

4:00The documentation by itself simply isn't useful, whereas working software

4:04absolutely

4:05is.

4:06Now, when we say just enough, we really do mean that and you'll sometimes see

4:10this described

4:11as barely sufficient.

4:13So we really want to keep our efforts focused on the thing that we're building.

4:18Let's not distract ourselves with writing documentation for an interim version

4:21of the

4:22product, because remember, we are delivering incrementally, aren't we?

4:25And so the documentation we might be creating now for this increment might not

4:29actually be

4:30that important for the overall product anyway.

4:33And again, for some teams, this is going to be quite a shift in mindset and we

4:36might

4:37even need to reset expectations of those around us as well.

4:41And we need to agree what exactly constitutes the term just enough or barely

4:46sufficient

4:46for our particular environment.

4:49And so therefore, because we're developing incrementally the documentation that

4:53we do

4:53produce, we produce just in time, sometimes described as the latest responsible

4:59moment,

5:00which I rather like, because we're expecting things to change, aren't we?

5:04It's not sensible to create documentation in advance ahead of changes that we

5:09know are

5:09inevitably around the corner.

5:12And so yes, we produce barely sufficient documentation only just in time whilst

5:17still

5:18fulfilling our needs.

5:20And those needs will vary depending, for example, what industry we work in.

5:25Because of course, there will be some industries where we do have much more

5:28regulatory documentation

5:30to deal with, so that needs to be taken into account when we are defining what

5:34just enough

5:35actually means for us.

5:37But you might even get particular stakeholders that particularly need a certain

5:40type of documentation

5:41or a certain level of detail at various points.

5:44Again, that's going to help us define what just enough means for us, given the

5:48particular

5:49stakeholders that we need to work with.

5:52But don't get complacent with this value, because sometimes I get people saying

5:56, "Well,

5:57that's just fantastic.

5:58We love that.

5:59We hate writing documentation anyway."

6:01But here's the thing.

6:02If you have skimped on documentation and your system doesn't work, then

6:07something's not

6:08right.

6:09The software needs to be working.

6:11That's our primary measure of progress, isn't it?

6:14And we do still need enough documentation.

6:18Okay, value number three is that customer collaboration trumps contract

6:23negotiation.

6:25Now, as before, we're not completely dismissing what's on the right-hand side

6:29here, so we're

6:30not dismissing having a contract altogether, because there will, of course, be

6:33elements

6:34of how we work that we might need to tie down contractually.

6:38But the contractual side of things should not extend to locking down all of the

6:42product

6:43details when the project hasn't even started.

6:46So we are expecting to collaborate with the customer to find the best solutions

6:52as we

6:52go along and as things evolve, because we can't be flexible if we've locked

6:56into that

6:57set of signed-off requirements.

6:58It's at the beginning of the project.

7:00Look, we don't want our poor customer to be thinking, "Well, you know, this

7:04list of

7:04requirements I've just signed off, and let's just hope that the product really

7:07does fit

7:08the bill by the time we actually come to get to release it."

7:11And as we know, this is the whole point of agile, isn't it?

7:14We do not gather all of those product requirements upfront and get it signed

7:18off and fiercely

7:19limit changes like we might do for an industrial product.

7:23No, with knowledge work, we develop incrementally.

7:26We get feedback on which we base our next steps and where do we get that

7:31feedback from?

7:32In order to support those inspect and adapt activities, well, we get that

7:36feedback from

7:37the customer.

7:38But look, I do acknowledge that this is easier said than done, because it can

7:43be very unsettling

7:45not to have that full clarity upfront.

7:48But it is another change in mindset and we need to really think about this

7:52because environments

7:53where things do change quickly, we have to work differently.

7:56This is the reality with knowledge work these days.

7:59And we can therefore address some of this discomfort that our poor little man

8:03is speeding

8:04here about not having a signed off list of requirements by remembering that

8:08typical agile

8:09life cycle.

8:10Do you remember this slide?

8:11With the yellow bit there, the yellow arrows representing the repeating

8:15iteration.

8:16But before we get to that point, we have established a vision.

8:21And that's going to be very useful for getting everybody on the same page as to

8:24what generally

8:25we are hoping to achieve with this product.

8:28And then the product roadmap, again, another useful tool for communicating to

8:32everybody

8:33involved to help us understand what we're aiming to achieve when.

8:37So once we've got our head around the idea of continually collaborating with

8:40the customer

8:41with regards to what we're actually producing, then yes, we can see that the

8:46development

8:47of our product or system will be much more of a flexible, collaborative

8:50partnership between

8:52us and the customer than a traditional contract would allow for.

8:56A normal contract simply wouldn't have provision for that sort of flexibility.

9:00Right, our final value is an easy one.

9:03We value responding to change over and above following a plan.

9:06So yes, when we're agile, we do understand that we are expecting changes, we

9:11welcome

9:11changes.

9:12But of course, we do need to plan what we're going to achieve in the very short

9:16term, but

9:17we are building software for today, not tomorrow.

9:19So it is a waste of time and effort to produce those enormous plans that try to

9:23predict two

9:24years into the future.

9:26So agile, of course, recognizes that these kinds of projects are unpredictable

9:30and there

9:30will be changes.

9:31And so you will remember from that typical agile lifecycle slide yet again that

9:36for sure

9:37we've done some of this high level planning, but then we get down to the

9:41detailed planning

9:42when we get into our iteration or our sprint.

9:45We only plan and commit to small chunks of work at a time.

9:49That's how we handle these unpredictable changing environments.

9:54So I think your key takeaways then for this video is simply going to be that

9:58set of four

9:59values from the manifesto.

10:01Remember, we're not saying that we don't need the things on the right, it's

10:05just that

10:05the 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.

10:13[BLANK_AUDIO]

0:00This is the first of a handful of videos in which we'll be chatting about the

0:0412 principles of Agile.

0:06And to save us laboriously plugging through them one at a time, from principle

0:10number one straight through to principle number 12,

0:12I have arbitrarily chopped them up into groupings that kind of make sense to me

0:16.

0:17And there would be lots of different ways of organising them, of dividing them

0:19up.

0:20It doesn't really matter. What's important is that by the end of the skill that

0:24we have talked about all 12 of the principles, which you can see here.

0:28So this first grouping of three principles that we're going to cover in this

0:32video, I have called delivering value,

0:34and I have pulled out numbers one, three and seven from the list here, and that

0:39feels 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

0:45principle number one.

0:47And if there is one principle which sums up Agile, then I think this has to be

0:50it.

0:51Our highest priority is to satisfy the customer through early and continuous

0:56delivery of valuable software.

0:59But let's unpick this a little bit further.

1:03So yes, we want to satisfy the customer. That sounds obvious, doesn't it?

1:08But we're talking about the actual customer, the person who's paying for this

1:11product, the person who's sponsoring it.

1:14So we're not aiming to satisfy, I don't know, our IT director or the project

1:18management office.

1:20So we need to keep focused, don't let internal politics get in the way.

1:24It sounds easy, doesn't it? But it is hard sometimes to keep that clarity when

1:28there's other stuff going on and other pressures.

1:30Oh, and also don't forget that our customer might be internal or external.

1:35If we're creating a product for another department, then that would be an

1:38internal customer.

1:39But if it's another organization that we're creating the product for, then that

1:41would be an external customer.

1:43So 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.

1:53And that does take a bit of courage and a bit of bravery.

1:56But we know that we need to uncover problems early on so that we do have time

2:00to fix them.

2:01That's the agile way, but it can take a while to get used to that.

2:05And we're also delivering continuously.

2:08So compared to an industrial project where we might only be delivering either

2:12at the very end of the project,

2:13if it's a smallish project, or maybe just here and there at the end of every

2:17major phase,

2:18with 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

2:27in general.

2:28So not plans, not designs, not user manuals or other documentation, valuable

2:33bits of product,

2:34valuable bits of the actual thing that we're building.

2:38And that does all sound jolly marvellous, but how do we do that?

2:41Well, the mechanism through which we deliver working software continuously is

2:45through those iterations,

2:47which we already know about.

2:48And so here's our next agile principle.

2:50We deliver working software frequently from a couple of weeks through to a

2:54couple of months

2:54with a preference to the shorter time scale.

2:57As I said, generally across the different agile frameworks, this principle is

3:02interpreted by working in iterations

3:04or in sprints, if we're talking about Scram, those short bursts of work,

3:09and the shorter time scale does generally mean that we're talking about weeks

3:13here.

3:14And typically when we do work like this, the assumption is that these

3:17iterations are time-boxed.

3:19That means that they're all the same length each, and I tend to use the example

3:23of every iteration being, say, two weeks long.

3:26Can ban, remember, though, is a little bit different.

3:28That's flow-based agile rather than iteration-based agile.

3:32But the idea of delivering working software frequently is really important for

3:36two key reasons here.

3:38So firstly, it's going to be crucial for frequent testing and frequent feedback

3:42.

3:43As we said with the last principle, it does take a little bit of courage and a

3:46shift of mindset to deliver frequently.

3:49It's so tempting, isn't it, to kind of hold on to something until it's as

3:52perfect as possible

3:53before we present it for feedback.

3:55But we need to let that go.

3:57We are all on the same team here.

3:59Let's get it working. Let's get feedback. Let's keep moving forward.

4:02That's how we're going to deliver value.

4:04And also, delivering software continuously is going to be fabulous for ongoing

4:08customer engagement.

4:10Do you remember this slide here from the last video?

4:13Let me just flip to it where we talked about those four core values.

4:16We said that we value customer collaboration.

4:19So this project is a partnership between us and the customer.

4:22We're on the same team. It's not them and us.

4:25And so delivering software frequently does support this.

4:29And so finally then, for this video, I have picked principle number seven here.

4:33Working software is our primary measure of progress.

4:36It sounds so simple, doesn't it? And so obvious.

4:39But as with all of these things, putting them into practice is often much

4:41harder than you might first think.

4:44And again, we mentioned this, didn't we, with the core value?

4:47Let me flip back to that from the video where we talked about those four core

4:50values

4:51where we said that, yes, we value working software over comprehensive

4:55documentation.

4:56Working software is actually useful and valuable, but complete documentation on

5:00its own is not.

5:02So yes, working software is our primary measure of progress,

5:06but there are a couple more points I'd like to put out here.

5:09So firstly, this principle gets us to shift our focus to actually doing stuff

5:14rather than planning and strategizing.

5:17And this does suit some personalities better than others.

5:20So someone like me, I am a doer. I'm very tactical.

5:23I get frustrated and bored with too much planning and too much strategizing.

5:27And that didn't do me any favors early on in my career.

5:30When exhaustive planning was very much the fashion.

5:33But of course, that means I'm very well suited to working in an agile

5:36environment.

5:37And secondly, note that partially completed work doesn't count in agile.

5:44This is quite an interesting concept because if a feature can't be tested,

5:48that means the customer can't accept it and it can't be considered to be

5:51complete.

5:52So all of this is going to help us to drive forward.

5:54It keeps us striving for working software, not fancy plans or strategies.

5:59Okay, I think those three principles are enough for one video.

6:03So here's our overall list of 12.

6:05The green ones are the three that we've just talked about.

6:08And so go and grab a coffee and I will see you in the next video for a couple

6:11more.

0:00In this video, we're going to tackle another couple of those 12 Agile

0:04principles, which

0:05I have grouped together under this heading of Embracing Change, which is

0:09certainly, as

0:10we have come to learn, a really important theme in Agile.

0:13And so the two principles that I'm going to pull off our list for this

0:16particular video

0:17are numbers 2 and 10.

0:20You can see them here.

0:21And we'll start with number 2.

0:22Let me just hide the other one for a second here.

0:24But you can see here that yes, in Agile, we welcome changing requirements, even

0:29late

0:29in development.

0:31Agile processes harness change for the competitor's customer advantage.

0:36I seem to have turned that into my very own tongue twister there, didn't I?

0:38No, I mean, it's the customer's competitive advantage.

0:42But yes, I think we've already got the point, haven't we, that with Agile, we

0:46do positively

0:47embrace we welcome changing requirements.

0:50Bring them on.

0:51We take the view that requirements are meant to be discovered, not dreamt up in

0:56advance.

0:57And so it's not about signing off a list of requirements in advance like we

1:00would do

1:01with an industrial project.

1:02Look at this little cartoon here.

1:05In those traditional projects, changes are really discouraged.

1:08And it's a very brave customer indeed, who, late in the day, wants to implement

1:13something

1:13that's only recently come to light, something new that wasn't on that original

1:17list of

1:18requirements.

1:19And while I know that Agile has been around for a while now, don't

1:23underestimate how radical

1:24it is that with Agile, we truly do welcome changes, even late in development.

1:30Very often, those traditional non-Agile project management environments have

1:34got such closely

1:35controlled change management processes that it makes any change really quite an

1:40ordeal

1:40and potentially somewhat problematic as per my cartoon here.

1:45But of course, the incremental and iterative nature of product development in

1:50Agile has

1:50been designed to incorporate change.

1:53So we don't suppress it or restrict it or discourage it.

1:56No, every iteration is an opportunity to explore changes.

2:01And in case it is obvious why welcoming change is a very, very good thing

2:05indeed for the

2:05customer, having a way of working, this approach that expects change creates a

2:11competitive

2:12advantage for the customer because it means we can react very fast to changing

2:18or emerging

2:19market conditions.

2:20We can keep up with the changing world of technology or whatever unpredictable

2:24or fast-changing

2:25environment that we happen to be operating in.

2:28Remember that product backlog?

2:30That's how we manage scope and changes in Agile.

2:33We are continually re-prioritizing and shuffling items on this list here.

2:38We're adding new things to the list.

2:40As new things come to light.

2:41We're removing things from the list, which are no longer needed.

2:45It's a brilliantly elegant way to handle changes.

2:48So Agile provides us with this really efficient method to deal with inevitable

2:53changes.

2:54And so clearly, it's going to give our customer a competitive advantage if we

2:57can respond to

2:58changes and re-prioritize the features that we develop as new information comes

3:03to light.

3:04Whether that information has come from feedback on the working software that we

3:07've produced

3:08so far or from changing conditions of the environment that we're working in.

3:13Now another aspect of Agile to help us welcome and respond to change, the other

3:17principle

3:18that I picked out to mention in this video is principle number 10 here.

3:23Simplicity, the art of maximizing the amount of work not done is essential.

3:29So Agile very much promotes simplicity.

3:33Build only what the customer has asked for.

3:35Build it well.

3:36And don't add all of those bells and whistles that they don't need.

3:40And I think of this as kind of concentrating on the vanilla flavour of our

3:44product first.

3:45We can cautiously add more flavours as and when it becomes apparent that that

3:49is what

3:49we need.

3:50But our focus is to create a really good vanilla flavour.

3:53A strong skeleton if you like of the simplest possible configuration that

3:58actually works.

3:59And if you think about it, the more complexities we add, the longer the project

4:04is going to

4:04take and we also start to introduce risk because it's more likely to go wrong

4:08if it becomes

4:09more complex.

4:10And so the less simple we make our product, the less Agile we become.

4:16Simplicity frees us up to be able to respond to change in the way that Agile is

4:19designed

4:20to do.

4:21And so from a design perspective, this means that we do not build the all-en

4:25compassing

4:26infrastructure or design that will support every possible feature.

4:30No, we keep it simple.

4:32For sure, we need to be responsible enough to make sure that we don't end up

4:35with something

4:36that prevents future development.

4:38There is a balance to be struck here, but we must forever keep in our minds,

4:43don't waste

4:43time doing work that's not needed.

4:46Build software for today, not tomorrow.

4:48Because as discussed, we're not entirely sure yet what tomorrow's requirements

4:51will

4:52be.

4:53Who knows what the future has in store.

4:55Right, that's another two principles off our list of 12 here.

4:59Stay 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

0:04ones

0:05where we focus on the people on our project team. And for that reason I always

0:09call them the 'peeple principles'. Although it troubles me as to whether this

0:13made up word 'peeple' should have that 'e' towards the end there or not.

0:16So from our list of 12 principles we've talked a little bit about the ones in

0:21green already and the people ones for this video are values 4, 6 and 5. You can

0:26see them here, we'll start with the top ones, I'll just hide the other two for

0:30now. And you can see that this principle states that the business people and

0:34developers should work together daily throughout the project. We don't want any

0:39disconnect between what the business needs are and what the developers are

0:43actually doing. It's a joint effort to remember. And it's worth pointing out

0:47here

0:47that when we say 'business people' as per the principle, we're meaning the

0:52customer or some kind of business representative who represents the needs

0:56of the customer. For example in the Scrum framework this would be the product

1:00owner

1:00role. In other environments it might even be a business analyst or something.

1:04But

1:04the point is with Adjile it's not a case that the customer hands off the

1:08project to the development team and only makes an appearance at infrequent

1:12check-ins. No, the customer or the business representative needs to be

1:16fully engaged so that they can make informed decisions about features and

1:20release dates and whatnot. And according to this principle when I say fully

1:23engaged that means daily contact. And so we can certainly say that Adjile

1:29therefore is much more dependent on customer engagement than traditional

1:33projects. That high degree of change that we are expecting with Adjile, you

1:38know it needs total transparency when it comes to feedback. We need to surface

1:42any problems or misalignments as they happen and that requires continual

1:48engagement. And you can really see the difference here if you were to plot

1:51customer engagement over time on a graph. Now this is a simplistic view but the

1:56point being that with traditional plan-based life cycles on the right here we

2:01will often see yes high engagement at the very beginning when we're gathering

2:05project requirements and whatnot. And then we go off and do the work with

2:08limited

2:09engagement with the customer until it comes to getting things signed off and

2:13accepted towards the end of the phase or the end of the project or a particular

2:16milestone or whatever. But of course with Adjile on the left here we're

2:21maintaining high levels of customer engagement throughout. It's continual

2:25engagement as depicted by the straight blue line there and it reinforces the

2:30idea that we are all on the same team. It's not them and us when it comes to

2:34the

2:34customer and the development team. We're a partnership, we're working in the

2:38spirit of co-creation as it were. Now I think this principle is sometimes

2:43really rather difficult to achieve in real life but it is worth the effort

2:47because it can make a really big difference in the degree to which the

2:50developers come to understand the business needs that they are solving

2:54with the product that they're building and of course the better they understand

2:57the problem then the better the thing will be that they're building to address

3:00it. Principle number six here says that the most efficient and effective method

3:06of conveying information to and within the development team is face-to-face

3:11conversation and this fits in well doesn't it? With that first of the four core

3:16values that we learned about from the Adjile Manifesto that individuals and

3:21their interactions are valued above processes and tools and so the best way

3:26to handle achieving this particular principle will be through co-location of

3:31the team. So that means that ideally we expect the team to be physically

3:35located

3:36together. Now in recent years with the COVID-19 pandemic and whatnot more and

3:41more people are working remotely so yes technology can certainly help us out

3:45here but ideally the team is co-located so that they can physically have these

3:50face-to-face conversations because it is much more efficient to just look up

3:55and

3:55ask a question across a desk rather than compose an email and wait for a

3:59response so we're getting answers quicker and since we're interacting in

4:03person with the full range of human emotions and personality quirks and

4:09body language and humor and whatnot rather than a written email which is kind

4:13of one-dimensional isn't it compared to actually speaking to someone if we're

4:17having 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

4:28one communication method as we scale Adjile for bigger more complex projects

4:33and therefore will have larger or multiple teams but we should never forget

4:37the benefits of having a face-to-face conversation and then finally for this

4:42video principle number five here this principle promotes creating an

4:46empowering environment it says that we should build projects around motivated

4:51individuals give them the environment and the support they need and trust them

4:56to get the job done so there's no micromanagement we trust the team to do

5:00the work people work better when they're given autonomy to get the work done in

5:05the way that they decide to get the work done this knowledge work is coming out

5:08of people's heads remember we've hired them for their expertise so we don't

5:13tell them how to do the work but that doesn't mean that we just kind of lock

5:17them in a room and tell them not to come out until they finished no we support

5:21them and that means creating an environment for them to enable them to

5:25do their best work so we help to remove obstacles and we answer questions and

5:29this is as we'll learn another time where the role of scrum master from the

5:33scrum 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

5:43inspire team members which sounds wonderful but it is easier said than done

5:48of course but don't forget with knowledge work projects our people are

5:52our biggest asset it's worth the effort we need to support them so there we go

5:58that's the three peopleie principles for you and I think that leaves just four

6:02from 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

0:04interesting and unique working practices of Agile.

0:09So here's our list, and the ones that we'll pick out for this video are

0:12principles number 11 and 8.

0:15Here they are, and we're going to come back to principle 8 in a second though,

0:18so I shall just hide that one for now.

0:20And you can see here that principle 11 states that "the best architectures,

0:26requirements and designs emerge from self-organizing teams".

0:31And to me, this is very much a progression of one of those people-y principles

0:34that we looked at in the last video.

0:37This one here, do you remember, we said that people work best when given

0:40autonomy, and we need to provide them with a supportive environment to enable

0:44them to do their best work rather than micromanaging them?

0:47Well, the working practice that helps us to achieve this is to have, as this

0:51principle says, self-organizing teams.

0:54And this is a really interesting principle, because it allows the team to

0:58therefore find the best approach for them.

1:01It allows them to find the best architecture, the best designs that they are

1:04going to be able to work with moving forward to deliver the product.

1:08And while that might be best for the team, it's also going to be best for the

1:11overall product itself, because the team are going to have increased buy-in,

1:15and ownership and pride therefore in the work that they do. Because, believe

1:19you me, there is nothing more annoying as a team member than having something

1:24imposed on you that you think is a stupid idea.

1:27So imagine these team members being told that they have to develop according to

1:30this architecture or according to that design that they think is stupid,

1:33then they're not going to be doing their best work, are they? They're not going

1:36to be working on it with their whole heart if they think that the ideas that

1:39have been forced upon them are idiotic.

1:41But if the team members themselves are responsible for finding the best

1:44solution, you know, the best architecture, the best design for what they're

1:48supposed to achieve,

1:49then they have that ownership of the solution that's going to keep them happier

1:53and it's going to create better work.

1:55And at the end of the day, they should be the ones to organize how they're

1:58going to do this, because they are the ones with the deepest technical

2:01knowledge, so it does make good sense.

2:03And so a good agile team should have their freedom to take its own direction.

2:09They find their own way.

2:10Now, it might take time for a brand new team of people who haven't worked

2:13together before. It might take a bit of time for them to find their own

2:17direction.

2:18And it might take time for everybody else in the organization to get used to

2:21the idea that the team self-organizes.

2:24But it is really amazing how creative a self-organizing or a self-managing team

2:29can be at solving problems and how fast they can move when they are empowered

2:33to just get the job done their way.

2:37Okay, the other one on our list for this video was principle number eight here.

2:41So it says, "Adjal processes promote sustainable development.

2:45The sponsors, developers and users should be able to maintain a constant pace

2:49indefinitely."

2:51So it's suggesting that we should strive to work at a sustainable pace.

2:56We should find a steady working rhythm that we can maintain long term.

3:01So it's not about working as hard and as fast as we can every single day.

3:05No, our competitive edge is going to come from being able to respond to change,

3:09remember, not from working at breakneck speed.

3:12So agility does not mean speed. Agility means being able to respond and make

3:17changes.

3:18And this is of course a benefit therefore of working in those sprints, those

3:22iterations.

3:23Every sprint is the same length. It's going to set a pace for us.

3:27It's going to give us a cadence for our work because we don't want burnout.

3:31We want happy team members.

3:33I say it again. Our people are our most important asset and we want them to

3:37find a good working balance.

3:39And it is interesting actually to compare this principle to the working pace

3:43that we often see in traditional non-adjal projects.

3:47So let me just sketch up some axes here.

3:49So imagine we've got a 12 month project running from January to December with

3:54the 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

3:59deadlines loom we suddenly have a surge of productivity.

4:02At the end there everything gets a bit frantic. We're all working overtime in

4:06order to get it finished on time for the December deadline or whatever it is.

4:10So we might see that surge of productivity at the end of the project on a

4:14miniature scale at the end of each iteration when we realize,

4:18"Oh my goodness, this has to be working by Friday."

4:20But it is on a miniature scale and it shouldn't be as intense as we might see

4:25for a traditional project where that surge of activity takes place over a few

4:29weeks at the end of the project.

4:30Having said that though, if workers do find working in sprints are too intense,

4:35they're finding too much pressure trying to get working software completed at

4:38the end of the sprint.

4:39Then we might need to rethink how much work we can realistically fit into a

4:43sprint, but more on that another time.

4:47Our focus here is to understand that Agile promotes a sustainable, maintainable

4:51working pace.

4:53So I think that's enough for this video. That means we've just got two

4:57principles 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

0:04which promote continuous improvement.

0:07And since there are only two left on our list that we haven't yet talked about,

0:11then obviously the two of interest to us for this video are the ones that we've

0:14got left, numbers 9 and 12 here.

0:16So let's start with principle number 9 which says that continuous attention to

0:21technical excellence and good design enhances agility.

0:25And I think this is reminding us that behind all of this Agile talk, now I did

0:30kind of do air quotes around Agile talk, but behind all of this Agile talk, we

0:35should 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

0:44stuff, it kind of seems a bit sloppy to me.

0:47I mean, we don't have to produce any documentation. The team can design the

0:50product however they fancy.

0:52And you tell me that simplicity is important. That sounds like a pretty easy

0:55gig to me. But my goodness, we've got to be really careful here because some of

1:00those other principles which might seem like shortcuts, well, they only work if

1:05we do pay continuous attention to technical excellence.

1:10Technical excellence should be our normal state with Agile projects.

1:14Otherwise, we simply don't have a viable product which makes everything else we

1:17've talked about, totally redundant.

1:19And talking of technical excellence, you might remember from when we were

1:22looking at some of the distinguishing features of some of the different Agile

1:25frameworks, you might remember XP, extreme programming.

1:29And this is best known for its set of software development best practices.

1:33And we'll talk about more of these another time, but certainly for us in

1:36talking about this principle, we're talking about things like, developers don't

1:41wait 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

1:49. We all take responsibility for the technical excellence.

1:53And we create good design that accepts those inevitable changes that we know

1:57around the corner.

1:58The design we come up with should accept those changes gracefully.

2:02And our final value then, number 12 here, says that at regular intervals, the

2:08team reflects on how to become more effective and then tunes and adjusts its

2:12behavior accordingly.

2:14So what we're saying here is that as a team, we regularly reflect on not just

2:18our work and our technical practices to look for improvements, but also to

2:22tweak and improve our behavior, our relationships, our processes and even our

2:28mindsets as well.

2:29Because working on an Agile team does present some tremendous opportunities for

2:33personal growth because we do have those inspect and adapt activities just kind

2:38of built into the philosophy of Agile.

2:41And if I just remind you of that typical Agile lifecycle that we've seen before

2:45, the type of activity that we're referring to here could be the sprint

2:49retrospective where we examine ourselves, our processes, our environment, our

2:53relationships, what went well and what didn't.

2:56And what can we do to improve our effectiveness for the very next sprint or

3:01iteration?

3:02And with that, my goodness, I think we've done it. That's our 12 principles of

3:07Agile completed.

3:09Now, I am aware that there was a lot to take in there, but I will be referring

3:12back to many of these as we progress through further skills.

3:16But for now, I hope this has been informative for you, and I'd like to thank

3:20you for viewing.