Lesson 01: The Predictive Approach

Did you think about the types of technical work in your project?

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:05 – So, what are the different types of technical things that you have to do in your project?
00:12 – We call them Development Processes and that’s in contrast to Management Processes.
00:18 – These are fancy words that you need to know. It’s a good thing to know them.
00:22 – If, for example, you are familiar with the PMBOK Guide, it’s all about processes, but those are Management Processes in contrast to Development Processes.
00:32 – Now, the type of things that you have to do depends on the type of project that you have.
00:37 – If it’s going to be an IT project, then these are the typical activities that you have.
00:42 – Activity is not the best word to use here. Let’s call them Development Processes. Okay.
00:48 – For those of you who are not working in IT projects, I’m going to give you a quick review of those.
00:54 – Analyze is where you try to understand the requirements, try to understand the problems that the customer has, problems that you’re going to solve.
01:04 – In the Design process, you try to see how you can solve those problems.
01:10 – You create the architecture for your software.
01:14 – In Construct, you will create those functions, those units, that solve the problems.
01:21 – Think of something like Microsoft Word.
01:24 – There we have functions related to printing, related to creating tables, to formatting text, and so on.
01:32 – Each of them requires a process for constructing them, creating the code for that, and yet we have to integrate them because things work very well as long as you’re testing them as isolated things, but when you put them together as one piece of software, then there are many strange problems. That’s Integration.
01:59 – And, of course, I also mentioned Testing. We have many different types of testing.
02:03 – Unit testing that’s only about isolated features, integration testing, recreation testing, user acceptance testing, there are many different types of them.
02:14 – Now, for those of you who are working in other types of project, you can see how you can create development processes for your project probably, but it’s never as simple and as straightforward as IT projects, normally, at least for the type of projects that I know. In Process Plan Project, for example, you have development processes such as basic design, then you have detailed design and procurement for each of your units.
02:44 – Then you construct and assemble and install each unit.
02:51 – Then you have some type of unit test isolated from other things, and then a type of integrated test with the load and everything else.
03:00 – And still, these development processes for a process plan doesn’t explain everything that you have to create there.
03:07 – You have other things; for example, the building inside which you will have those units, and so on, but that’s okay.
03:16 – By the way, in this course, we are going to use examples for IT development, and the reason is that IT development is the best example where you can use Agile projects.
03:27 – That’s actually one of the topics that we’re going to have, if it’s possible to use Agile in other types of project. So, for now, let’s think about IT development.
03:37 – So, these are the Development Processes. Now I have a more important question.
03:42 – How can we run these processes? In which order?
03:47 – With what type of lifecycle? Another fancy word. Okay.
03:53 – There are two types of generic lifecycles. Let me see if you can think about both of them.
04:00 – Take your time. I’m here. I’m okay. I have time. Okay.
04:06 – This is one type. It’s very simple, very straightforward.
04:11 – We run the development processes one at a time.
04:14 – We start with analyzing. We try to understand all the requirements that the customer has, then we design everything, create the whole architecture for the software.
04:24 – Then we create all units, all functions, that’s the construct process. Then we will integrate all of them.
04:34 – We will run into many problems in that process, and then we will test and try to solve them.
04:40 – This is simplified, of course, because those of you who are into this type of industry, this type of project, know that there are different types of tests and you have to run them in different stages here, but that’s fine. Let’s keep it simple.
04:56 – In here, we have different deliverables, if you will.
05:02 – At the end of the analyze process, we will have an understanding of the scope of the project.
05:07 – You can document the scope, and that can also be used in your contract.
05:12 – Then, at the end of the design process, we will have the architecture for the project, and related to that, at the end of analyze, we can also have a high-level plan for the project because we have a good understanding of what we are going to create, but still the details depend on your design. That’s about how you’re going to create the solution.
05:34 – So, at the end of the design stage, or design process, you can create a detailed plan for your project, and that’s usually the thing that you will use throughout your project to achieve what you have in mind, and one common problem is that people create a detailed plan there and they don’t change it at all.
05:55 – That’s not the type of plan that we need in projects. That doesn’t work.
05:58 – A plan should always be adjusted, updated, and so on. It’s a living document.
06:05 – We have other development – other deliverables in this type of project.
06:11 – At the end of Construct and Integrate, we will have pieces of code, and at the end of the project, we will have the product.
06:19 – That’s the product that you can give to the customer or to the end-users and let them use them.
06:25 – There’s a difference between product and code. That’s important.
06:30 – The product has to be ready to be used. It has to be complete. It has to make sense.
06:36 – But what we have at the end of the Construct process is a number of isolated pieces of code, it’s not a product.
06:47 – Okay. We need to have a name for this and one of the most important characteristics in this type of lifecycle is that we try to predict everything in the beginning of the project.
07:02 – We try to predict the product that we have to create.
07:07 – We try to predict the quality requirements, the time needed, the cost and so on.
07:14 – That’s the plans that we have here, and because of that, it is called the Predictive Lifecycle.
07:20 – That’s our first type of generic lifecycle.
07:24 – In practice, of course, we never have things like this in sequence.
07:28 – We always have overlaps, that’s fine, that’s still the same kind of lifecycle because we have the concept of prediction, prediction in the beginning of the project.
07:41 – We have upfront plan, upfront design, and upfront specification.
07:47 – For simplicity, from now on, we won’t think about having overlaps and we’ll think of this lifecycle like this. Okay? Alright.
07:57 – Now, we have one issue here. Do you see the product?
08:02 – It’s created all the way at the end of the project.
08:07 – Now, if you want to create a building, it’s fine.
08:13 – The supplier and the customer can get together, think about the building that they want, design something on paper, specify different things, and at the end, what the supplier gives to the customer is almost what the customer wanted.
08:32 – That works, that’s fine, but there are some types of projects. Are there? Yes.
08:38 – IT development where it doesn’t matter how much time you spend in the beginning of the project, thinking about what you need.
08:46 – If the customer is going to see the product only at the end of the project, you will be in trouble because, based on experience, it doesn’t work on paper. They have to see the product.
08:58 – That’s when they realize what they really want. That’s the problem that we have, and when it is created at the end of the project, we have a big problem because that’s too expensive to change the product at that point.
09:11 – Because of this, it’s a good idea if we can have a different lifecycle for this type of project.
09:19 – So, can you think of a different lifecycle that solves this problem?
09:25 – We’ll talk about it in the next lesson.

Having the working product at the end of the project is risky in some cases. Can you think of another development lifecycle that solves this problem?

Lesson 01: The Predictive Approach

Contact your trainer to ask questions