Lesson 05: Agile Principles

We’re going to talk about the Agile Principles in this lesson.

2020 update notes

A few things have changed in the latest version of the Scrum Guide (2020), and the ASF exam is updated based on those changes. However, our videos are not updated yet; so, please note the following changes:

There’s no “development team” anymore, but only Developers.
The recommended team size is now “10 people or less” for the whole Scrum Team.
It’s now called “self-managing” instead of “self-organizing” (same concept, different name).
There’s a Product Goal now, which is part of the Product Backlog, and sets the overall direction for the product.
The Sprint Goal is now considered as part of the Sprint Backlog.
The concept of commitments is introduced for the artifacts:
- Product Goal is the commitment for the Product Backlog.
- Sprint Goal is the commitment for the Sprint Backlog.
- Definition of Done is the commitment for the Increment.
The Definition of Done is created by the whole Scrum Team now, and not only by the Developers.
Now, any time you finish an item (based on the Definition of Done), a new Increment is formed. It’s not about having just one Increment at the end of the Sprint.
The guide doesn’t suggest 10% as the ceiling for the amount of time Developers spend on Product Backlog refinement.
Sprint Planning has three topics now:
- Why? -> Sprint Goal
- What? -> Items from the Product Backlog
- How? -> Tasks created by decomposing the items
“Estimating” is now called “sizing”. So, it’s the responsibility of the Developers to size the Product Backlog items.
“Value” is no longer one of the mandatory attributes of the Product Backlog items. The mandatory attributes are description, size, and order.
Instead of calling the Increments “potentially releasable”, the new guide calls them “usable” (more or less the same concept).

00:06 – Okay. So, in the previous lessons, we talked about the difference between Predictive and Adaptive systems.
00:15 – Now you know that in a predictive system, we start with a complete plan, we try to understand what’s the best way to realize the product, and then we follow the plan to create that. In adaptive systems, we have multiple iterations, and in each iteration, we will focus on a subset of the features for the product, create something, show it to the customer and end-users, receive feedback, and use that feedback to see what’s the best way forward. Okay.
00:49 – And then I asked you if you think that Agile and adaptive systems are new, and my answer is that I don’t think so.
01:01 – And then we started with the first time when the label Agile was really used to refer to this type of work, which was with the Agile Manifesto. This one.
01:12 – We talked about it, and then the same people who have created this Agile Manifesto have also created a set of principles, 12 principles, and that’s what we’re going to talk about now.
01:27 – So, the first principle. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
01:36 – Can you explain what it is? It’s not so difficult.
01:42 – In adaptive systems, we use Incremental Delivery, which creates multiple versions of the product throughout the project, and we do that because we want to receive feedback and use that feedback to see what to do in the next iterations.
01:59 – That’s one of the advantages of using Incremental Delivery.
02:04 – There is a second advantage as well. Can you think of that?
02:08 – The first one is that it enables feedback, feedback that can be used for the next iterations.
02:15 – The second advantage is that when we do have that product, we also have the option.
02:21 – Sometimes, not always, we may have the option to release the product and really use it and generate value in the company for the customer. That’s also good.
02:34 – Okay. The next one, the second principle.
02:38 – Welcome changing requirements, even late in development, Agile processes harness change for the customer’s competitive advantage.
02:45 – What do you think about this one?
02:50 – That’s simple. We can always accept changes, and it’s even a little bit difficult to call them changes.
02:57 – They’re just ideas that are coming and it’s very easy for us to incorporate those new ideas or changes, if you will, because we are not basing everything on an upfront design and plan, and so on.
03:11 – There are difficulties, of course.
03:15 – For example, we have to work in a way that different features are not dependent on each other.
03:21 – That’s tricky, but well, there are developers out there who know how to do that.
03:27 – There are also courses for developers about that.
03:32 – So, the – oh, also, remember, that when we are thinking about that, we are not removing planning as you see here, we are replacing one type of planning, which is upfront, with continuous planning plus adaptation.
03:51 – That’s important for us. It’s an adaptive lifecycle.
03:54 – It’s not chaotic. That’s the main message.
03:57 – The third principle. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
04:07 – Nowadays, if you say, if you tell someone that we are Agile and we have iterations that are 2 months long, then people may laugh at you, but in those days, when those people wrote these principles, 2-month iteration was really short.
04:25 – And what you see here, the maximum of 2 months, is the type of generic approach to Agility, but in Scrum, for example, we say that the maximum is 1 month.
04:38 – If we can have shorter iterations, that’s usually, not necessarily, but usually better. Okay.
04:47 – The fourth principle. Business people and developers must work together daily throughout the project.
04:55 – Okay. It’s always a good thing. It is not limited to Agile projects.
05:01 – It can always help and we have always been talking about this need.
05:07 – However, as you see here, in a predictive system, most of the important things that we need to do are done, well, those things that need involvement of the customer or business people or high-level managers, are done in the beginning or at the end of the project, when we are specifying and when we are accepting, approving the product.
05:32 – So, it is possible to escalate everything in a predictive system because it’s done in a limited time, but in an adaptive system, we are always doing new types of specifications, we are always creating new pieces of working software that need some type of acceptance, and therefore, we always need to have that type of involvement of the person or people who are supposed to be involved, and that’s why in adaptive systems, we must have access to business people.
06:11 – It’s not that we like to have it, we must have it.
06:14 – If you don’t, you can’t have access to business people, then you cannot really use an adaptive system like this.
06:22 – You see what I mean? And that’s very important.
06:25 – Most people who want to start using Agile and run into different problems, one of the common problems is that their business people don’t support them.
06:34 – That’s one of these things. Okay.
06:37 – The fifth principle. Build projects around motivated individuals.
06:43 – Give them the environment and support their need and trust them to get the job done.
06:47 – Nice. Good. Want more?
06:51 – Okay. In adaptive systems, as we talked about here, we have more special decisions to make and because we are doing it continuously, we cannot escalate all those decisions to the higher managers, and therefore, we need to let people in the team decide about things.
07:14 – What does it mean? That’s responsibility.
07:18 – So, basically a type of person who prefers to have a simple work, come to work every morning, leave work in the afternoon, don’t care about the whole big picture of the project, what happens to the value that we are creating, that type of person may not be the best for an Agile project.
07:39 – We need people who are enthusiastic about the project.
07:43 – They would like to get more and more responsibility. That works.
07:47 – Yes, that’s difficult.
07:50 – Okay. The next one. The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.
07:59 – That is, instead of sending millions of emails and things like that, we prefer to get together and talk about things.
08:08 – Face-to-face communication.
08:11 – By the way, that’s one of the things that you may see in the exam that’s very exam friendly.
08:16 – They may give you a few options in response to a question and one of them is about the preference for face-to-face communication, which is probably the right answer.
08:26 – Okay. The next one. Working software is the primary measure of progress.
08:33 – The way we measure progress is always very, very important, and many people in many projects measure the wrong thing and what happens is that they achieve the thing that they didn’t want, the wrong thing.
08:49 – You get what you measure and that’s about every type of project.
08:55 – In many Agile projects, even people measure the wrong thing, and we will talk about many of them during the course, but one basic thing that we have here is that when you want to measure, it has to be about the product.
09:07 – Well, ideally it has to be about the value you create, but that’s very difficult to measure, so let’s focus on the product, and that is instead of things such as lines of code that you’re creating or the number of man-hours spent on the project.
09:22 – Those are not good measures. Okay. The next one.
09:28 – Agile processes promote sustainable development.
09:32 – The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
09:37 – Don’t do over-work a lot before releases because then your quality will be lower, and in the long term, your productivity will be much lower. Just work normally.
09:50 – We will get back to this in the XP section.
09:55 – The next one. Continuous attention to technical excellence and good design enhances agility.
10:01 – Yes. It enhances every type of project.
10:05 – In fact, one of the problems that people who are not really big fans of Agile have to say is that we don’t have technical excellence in Agile, and in fact, there’s a risk for us.
10:21 – The risk is that we don’t have upfront architecture and we don’t have upfront plan, and therefore we do have the risk of having a poor architecture for our software.
10:35 – Therefore, we should be really careful about this. How?
10:40 – One common way is what, some of the practices that we have in XP.
10:46 – We will talk about it in the XP section, but they are not limited to XP.
10:50 – You can use them in every type of Agile project.
10:54 – Number ten. Simplicity - the art of maximizing the amount of work not done - is essential.
11:00 – That’s funny, isn’t it? It’s a very complicated way of talking about simplicity.
11:06 – What do you think about this?
11:10 – Okay. You may be thinking that it refers to the way we work.
11:17 – The simplicity of the system that we have for the project, but in fact, it’s mainly about the simplicity of the product that we create.
11:25 – Okay? For each product, you can have many different features and sometimes many of those features, not sometimes, always, many of those features are not so useful and by adding them to the product, we make things more complicated. It will be more expensive to maintain the product in the future, and it will be more difficult to add new features, important features, in the future.
11:51 – Also, we will have to spend more time and money.
11:54 – Now, you can think of the project as something that creates a product and gives that product to operations. That’s why we do it.
12:06 – Projects are about changes, about enabling new types of business as usual.
12:13 – So, it goes to production. Now what happens with money here?
12:17 – We spend some money creating the product, that’s the money we spend in the project, and then we have to spend some money maintaining the product in the production, and in return, we will earn some benefits, and we hope that the benefits will be higher than the cost.
12:33 – One problem here is that most people don’t think about the maintenance cost and only think about the project cost. Now, what happens if you add as many features as you can, even the crazy features that no one uses?
12:49 – Then you will have a longer project, a bigger product which costs you more money to build, and will probably cost you more to maintain, which is an important thing, and it may not increase your benefits so much.
13:08 – So, in fact, your return on investment will be lower. That’s what this principle tries to say.
13:17 – Okay. Which one was it? Ten? Okay, now eleven.
13:23 – The best architectures, requirements, and designs emerge from self-organizing teams.
13:30 – Self-organizing team is one that finds its own way instead of receiving orders.
13:36 – In other words, you empower people, you let them decide about certain things about the project, and that’s because of this that we talked about before because in type of development, we cannot always escalate issues or questions or decisions.
13:54 – In other words, we need to have at least a certain level of self-organization in Agile.
14:01 – It’s not that we say, “Okay, it’s a good idea,” it’s because we really need it for agility.
14:08 – Twelve, and the last one, by the way.
14:11 – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
14:20 – Every once in a while, we get together, we think about the way we are working, and wonder how can we make it even better, and in case you don’t know … do you know the name for this type of meeting?
14:34 – That’s called Retrospective Meeting. So, we have them all the time and, well, you know that we already work in iterations, right?
14:44 – For example, 2-week or 3-week or 4-week iterations.
14:47 – It’s a good idea to have one retrospective at the end of each iteration.
14:51 – Okay. So, that was it, and my next question.
14:58 – In your idea, in your opinion, is Agile faster?

Is Agile faster?

Self Evaluation

Go to the Agile Principles page, review them, and try to explain them to someone.

Lesson 05: Agile Principles

Self Evaluation

Contact your trainer to ask questions