Lesson 04: The Agile Manifesto

Is Agile new?

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 – So, people talk about Agile as something that is extremely new and as a replacement for the other type, Waterfall, something like that, and my question was, in the previous lesson, in your idea, is it a new thing? Can it be a new thing?
00:27 – Well, when you think about it as a type of adaptive lifecycle, I have a very difficult time imagining a human being, society, culture, and civilization without using any type of adaptive systems until 20 years ago. I really can’t.
00:52 – And when I have classroom courses, I usually ask people to think if they can come up with examples of really, really old projects that were done with adaptive systems.
01:03 – And one of the examples is going to war, which used to be very popular in those days.
01:11 – You can’t do it with a predictive system. You cannot sit down and plan everything, “Okay, this is how we’re going to attack the enemy. That’s what they will do, and then we will do this other thing. This and that and then the whole war will be … will be finished.” That’s not what you do, that’s not possible. It has to be adaptive. You will have an overall strategy.
01:35 – You will go on, see what’s happening, and based on that, you will plan for the next steps. That’s adaptation.
01:45 – So, I think that we always had both of them, both the predictive and adaptive systems.
01:52 – However, when I think about it, maybe because of Taylorism and what used to be called scientific management, it’s still called scientific management, there was a lot of attention towards predictive systems for a while, and I think it caused people to underestimate the adaptive systems for some time, but then we moved on and especially with the IT development projects, we realized that limiting ourselves to one type of development lifecycle doesn’t work, especially for IT development projects, and that’s why we as a community try to rediscover adaptive systems, and then there was also the name Agile, the name, the label Agile is new.
02:45 – So, gradually, some people in the IT development started trying new things, and there were similarities among all of them and that similarity was the development lifecycle, and after a while, a group of them got together and they created the Agile Manifesto, which is about 20 years old now, almost 20 years old, and most people consider it as the ultimate definition and Bible for Agility, which I’m not sure about because at least when we are talking about the concept of Agility, we are expected to be adaptive, itself to be adaptive, and something that has not changed in the past almost 20 years doesn’t seem like a good thing to describe adaptation.
03:37 – Maybe that’s just me, but anyway, this is the Agile Manifesto. You need to know it very well.
03:44 – I’m going to go through these four values in the Agile Manifesto.
03:49 – The first one is that we value individuals and interactions over processes and tools.
03:54 – This is especially against Taylorism because in Taylorism, they try to reduce everything into processes and tools and don’t pay enough attention to people.
04:07 – People are complex, and in projects, when you have experienced projects, you know that many of the problems are because of the interactions among people.
04:20 – I’ve seen managers who try to replace that or to solve those problems by having a more complicated process or using more complicated tools.
04:32 – Many of the maybe ERP systems can be considered a response, at least partially, to that type of problem.
04:42 – Some managers think that if they have a great tool and they spend a lot of money on that tool, then everything will be fine, but you know that it never happens.
04:54 – It will be fine only if pay … if you pay enough attention to individuals and their interactions.
05:02 – Now, one of the reasons that I believe that the Agile Manifesto needs an update is that this one value needs some clarification because in the parallel systems, I’m not saying predictive, in parallel systems, think about the PMBOK Guide and PRINCE2, we always, always talk about the importance of human aspects.
05:26 – For example, in both of them we say that the Project Manager has to do – has to spend about 80 or 90% of their time on communications.
05:34 – And there are many different articles about the importance of negotiations, motivation, conflict resolution, and so on, but that doesn’t seem to be enough.
05:47 – What happened in Agile, which was really great, was that those human aspects were part of the process that we had in Agile systems, while in the parallel systems, it was not part of the process, it was bolted into, it was an afterthought.
06:06 – That’s the big difference. In all Agile systems, and we will talk about some of them in the future lessons, it’s as if everything is … everything is formed around the human aspects and things are integrated with each other. The best example is XP, which is one of our topics later on.
06:27 – You will see that we have a process, that’s on the other side, we have a process that enables these human aspects and that’s the great thing about Agile.
06:41 – So, the other thing that we have here is that we value working software over comprehensive documentation, and that’s the difference that we have here.
06:52 – In a predictive system, we have an upfront plan, upfront design, and all of those things are documentation.
07:00 – You can have modeling, but … well, mainly documentation.
07:05 – So, we try to understand what we need in the project and then we go on and create that thing, but in adaptive systems, instead of using that comprehensive documentation, we go on with the project and just adapt the things, and the way we can adapt is by creating the working software, showing it to the customer, and then users receiving feedback and using that feedback to see what’s the best thing to do next.
07:36 – Customer collaboration over contract negotiation.
07:42 – In a predictive system, we usually don’t have increments during the project, so we don’t have something to show the customer. We have deliverables, but most customers don’t understand deliverables very well, or if they understand, they can’t experience it, or even if they can, the end-users cannot do that because the end-users are a great source of feedback for a project.
08:10 – So, what happens is that we have all the acceptance at the end of the project and we will have a lot of problems, but in adaptive projects, it is done in every iteration and even not only at the end of each iteration, it’s done gradually but more at the end of the iteration.
08:31 – So, yeah, we need to have … by the way, when we say customer collaboration, it doesn’t mean that we believe that it’s a really good thing.
08:45 – Well, yes, we believe that it’s a good thing to have, but more importantly, we must have customer collaboration in Agile projects and that’s because in a predictive system, we have the upfront plan that can help us find our way during the project, but in adaptive systems, we don’t have that.
09:06 – We have to find our way and adapt to the environment and that requires talking to the customer, having access to the customer.
09:14 – You will have lots of acceptance tests during the project.
09:18 – So, it’s not only about the fact that it’s a good thing to have, it’s also about the fact that we really, really need it in adaptive projects more than we need it in a predictive project.
09:29 – So, if you want to have an Agile project, you must make sure that your customer is also ready to support the whole project in this way of working.
09:38 – That’s a big problem, I know.
09:42 – And the last one, responding to change over following a plan.
09:46 – Again, in a predictive system, we have an upfront plan, which is really comprehensive.
09:52 – That’s the best way, based on our initial understanding, that’s the best way to do the project.
09:59 – So, when we go on, when we need to make a change, it’s usually more expensive for us because we have to change our plans, change our design sometimes, and also in a predictive system, we usually have more dependencies among things.
10:18 – So, when you change something, there are more things to fix in order for that change to work, but in an adaptive project, we don’t have the upfront plan and design and so on.
10:30 – We are going on, we receive new ideas, and it’s even difficult to call them a change.
10:35 – That’s just new ideas, but we can still call them change and the customers like it, so why not?
10:43 – Okay. So, this is the Agile Manifesto.
10:47 – It’s a good description of what Agile is.
10:52 – What Agile was 20 years ago in the minds of those people who created it, and many of them are really, really smart people. Some of them are just great people, they have done a great thing for us, but I would say you don’t have to limit yourself to this.
11:09 – So, that was it, and in the next lesson, we will talk about the other thing that those people created, which is a set of 12 principles.

We’ll talk about the 12 Agile principles in the next lesson.

Self Evaluation

Open agilemanifesto.org, review the manifesto, and explain what each of the four statements mean.

Optional Extra Material

A retake on the Agile Manifesto (YouTube): a panel discussion, during which they talk about the way Agile Manifesto was created. This is told by people who were involved in that process.

Lesson 04: The Agile Manifesto

Self Evaluation

Optional Extra Material

Contact your trainer to ask questions