Lesson 06: Practical aspects of adaptive development

Is Agile faster?

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 – What do you think? Is Agile faster?
00:11 – In fact, it’s … it’s difficult to say if you want to be precise and correct.
00:17 – Well, we can say that it seems like Agile works much better for IT development projects, but being faster, that’s really difficult to say.
00:27 – However, if it’s correct to say that it’s faster, then there can be two main reasons for its success and speed.
00:40 – The first one that … do you want to think about it? The two reasons.
00:45 – You can come up with more than two, I don’t know.
00:49 – Well, one of them is with the way we work because in a predictive system, we are not so flexible about changes because some of the changes may affect our upfront design and plans and when they do, then when we want to accept those changes, we have to make more things differently. Change more things.
01:14 – They are dependent. We have way more dependencies in a predictive system, but in an adaptive system, it’s easier and less expensive. It takes less effort to apply changes.
01:28 – That’s one thing that makes it easier and faster to apply changes and we know that we always have changes.
01:36 – That’s one reason that Agile can be faster, but there’s also another reason and I think that’s even more important.
01:45 – The reason is that in most projects, think about the predictive system.
01:53 – It usually comes with a fixed price contract and the customer, the people in the customer’s side or business side who are responsible for the software, try to give you a complete specification of all the requirements that they have.
02:10 – What happens is that if you go on and in the middle of the project, they ask you for a new requirement because they forgot about it before, then you will probably ask for more money, and that’s difficult for those people, and you deserve to ask for more money because you have to go back and revise your architecture maybe.
02:31 – There’s a lot of rework. So, what happens is that those people, when it’s in the beginning of the project, they try to think about as many features as possible, everything that they may need some time somehow in the product, and what happens is that they turn out to be too creative and in fact there are some statistics that show that a really large percentage of the features that we have in an average piece of software are never or rarely used, and that’s a disaster. If you think that, for example, half of the features are not used, then it means that you are spending twice as much money and time on your projects. That’s a disaster.
03:20 – Now, in an Agile project, you don’t have to force the customer to come up with all the requirements in the beginning.
03:28 – They can tell you during the project. So, that type of thing doesn’t happen.
03:35 – You can prevent that type of thing from happening, so that can help you being faster.
03:44 – So, that was one thing, I think, that’s important to consider.
03:48 – Now, there are a few practical things related to adaptive systems. Let’s review some of them.
03:55 – Let’s start with the iterations, okay? I can think of two alternatives.
04:01 – One is to have Fixed-Duration Iterations during which you will try to develop as many features as possible, and the other is to have Fixed-Scope Iteration, where you pick a number of features, and the iteration is not finished until you finish all those features.
04:22 – Which one of these two alternatives is better in your idea?
04:27 – Would you go for Fixed-Duration or Fixed-Scope?
04:33 – Okay. Do you remember the conversation that we had before when you end up with a lot of features that are not really useful?
04:44 – The same thing can happen within each and every feature.
04:49 – Whenever you think about a feature, think about … my previous example was Microsoft Word.
04:54 – Let’s say you want to create something like that and one of the features is to print. Okay?
05:02 – And you believe that is important, you need to have it.
05:05 – Now, when it is time to develop that feature, within that feature, you have multiple options.
05:13 – You can have a simple way of printing or printing with a lot of fancy SOP features.
05:19 – How do you do that?
05:22 – If you go for iterations that have fixed scope, in practice, what happens is that you will end up spending too much time for fancy elements in your features.
05:37 – That’s the way it works usually, but if you have a fixed duration, there are multiple advantages.
05:44 – One of them is that it encourages everyone to focus on the most important things, most valuable things, and not to spend their time on fancy features or fancy elements of the features. That’s one thing and the other is that that makes it much simpler, doesn’t it?
06:01 – If you know, for example, that you have 2-week iterations, you will know that after each 2-week duration, you will have a new piece of product, you can show it to the customer. The customer can schedule it.
06:13 – They will know that, for example, every other Monday, you will have a short meeting together to see the product and they are supposed to tell you what they think about it. That’s much easier.
06:24 – That’s why in almost all Agile systems, we prefer to have a fixed duration, and we have a name for that.
06:33 – We call it Timeboxed. Timeboxed is when you have a deadline, you say that it’s going to be 2 weeks, and you really keep it.
06:42 – You don’t extend it for even one day. You don’t care.
06:46 – Maybe you couldn’t develop more than half of the features.
06:49 – That’s fine. You will show that 50% of the features, and that’s fine. You will go to the next iteration.
06:55 – That’s the concept of Timeboxing.
06:59 – Do you remember the duration of the timeboxes?
07:02 – We talked about it in the … one of the previous lessons about the principles.
07:07 – It was the last one, yeah.
07:11 – Based on the principles, those 12 principles, the maximum is 2 months, but as I told you before, in Scrum, the maximum is 1 month, and we prefer to have even shorter times if it’s possible; 2 weeks, 1 week.
07:26 – For us, for myself, it’s been usually about 2 weeks or sometimes 1 week, but 1 week is really special.
07:35 – That’s difficult. Another thing.
07:41 – We said that it’s a good idea to have fixed duration or timeboxed iterations.
07:47 – Now, still we have two options. You can have the same timeboxed duration for all iterations, say that all my iterations are going to be 2 weeks.
07:59 – The other one is to timebox each iteration differently.
08:04 – Say that, okay, the first iteration will be 3 weeks long and you will keep it, you won’t extend it.
08:10 – That’s what timeboxing means, but for the next iteration, you will check and decide.
08:15 – You will say that the next one is due in 2 weeks, the next one 3 weeks again, the next one 1 week.
08:23 – Which one of these two options is better, in your opinion?
08:27 – Okay. In fact, both of those options exist in different systems.
08:35 – It doesn’t mean that one of them is wrong. Both of them can be used, but the first one is simpler. So, we prefer the first one.
08:46 – In Scrum, that’s how it works, but for example, in DSDM, we can have timeboxes with different sizes to cover more complicated projects, needs in the projects.
09:01 – The other thing, now let’s say we are within the iteration, we’re going to work.
09:08 – How do you work inside the iteration?
09:12 – There can be two generic approaches, these two.
09:16 – One is to run the development processes.
09:19 – Do you still remember the development processes? You do.
09:24 – The first one A is to run the development processes one after the other, which means that we will analyze all the features that we’ve selected for the iteration, then we will design all of them, then we will construct all of them, integrate, and test.
09:41 – That’s one option, and the other option is to go based on the features.
09:47 – So, we start with the first feature and then for that feature, we will specify, design, construct, and so on, and then we will go for the next feature or do some of them in parallel. Which one is better?
10:07 – Okay. I think it wasn’t so difficult.
10:12 – B is much, much better. So much better that maybe we can say that A is wrong.
10:19 – And that’s because we prefer to have Timeboxed Iterations.
10:24 – Now, what happens if we don’t have enough time?
10:27 – In A, for example, we will have all features analyzed, designed, and constructed, but maybe they’re not integrated and tested.
10:39 – So, in that case, what happens is that we don’t have anything useful until the end of the iteration, but in option B, if we don’t have enough time, instead of delivering those 5 features, we can still deliver 3 or 2 features, and that’s fine.
10:58 – That’s why we prefer option B. Okay?
11:03 – The other thing which I’ve mentioned before, but it’s really important and it’s a good idea to think about it again and again, is about escalation and self-organization.
11:17 – Escalation is where you have a decision to make or an issue about the project and you send it to the high-level managers to decide and tell you what to do.
11:29 – And what’s different between these two is that in a predictive system, most of the critical decisions are in the beginning or at the end of the project.
11:41 – That makes it easier to escalate all of them. You will have some of them during the project, but not many, so again you will escalate them during the project.
11:51 – That is possible to do, but when you come to adaptive systems, we are always specifying new things, we are always checking to accept new things, so practically what you see is that we have the same type of important decisions almost every day.
12:10 – So, if you want to keep escalating them all the time, then you have to wait all the time.
12:17 – You can’t really work. That’s not possible.
12:21 – That’s why the team has to be self-organized as it is usually set, which means that they can make some decisions, many of the important decisions.
12:33 – It doesn’t have to be absolute empowerment, it can be still with a certain level, but we need to have more empowered people in Agile because of this.
12:46 – And you see, I’m trying to tell you why we need these things.
12:50 – It’s not because they are, they seem fine, not because they are fancy, and not because they are modern and that type of thing.
12:57 – That’s because of our development lifecycle. Okay?
13:01 – Alright. So, we’re done with the first section, which was about the concept of Agility, and I believe that you have a really good fundamental understanding of what Agility is about.
13:15 – And in the next lessons, we can start talking about different approaches that makes it possible because whatever we talked about so far was about the abstract idea of Agility. Now, you need to know a little bit of more practical things, and the best way to do it is to talk about Scrum because it’s very simple and it’s very, very common.
13:38 – So, the next section, which is the biggest section of the course, is going to be about Scrum.

Congratulations! You’ve just finished the first section of the course, which was about the concept of Agility.

From the next lessons, we’re going to start discussing Scrum, which is the most popular Agile framework.

Self Evaluation

Assuming that Agile is faster, what would be the two reasons for that?
Which one is better, fixed-duration iterations or fixed-scope ones? Why?
Which one is better, same-duration iterations, or those with different lengths? Why?
How should we work during the iteration, one development process at a time or one feature at a time? Why?
Why do we need to have self-organization in Agile?

Lesson 06: Practical aspects of adaptive development

Self Evaluation

Contact your trainer to ask questions