Lesson 10: Development Team

Now, let’s see how a Development Team works…

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, we have three roles in Scrum - the Product Owner, the Scrum Master, and the Development Team.
00:12 – Now, we’re going to talk about the Development Team.
00:16 – There are 3 to 9 people, they are technical people, and there are a few things that are special about them.
00:23 – First is that they share accountability for the things they do.
00:31 – And, for example, they don’t have titles, the titles such as Tester.
00:39 – We don’t have testers in Scrum. What we have is a developer who is expert in testing.
00:48 – Do you see the difference? It’s interesting, I think, because when you say that this person is a tester, it implies that that person is only responsible for testing, and if you have a difficulty somewhere else, that person doesn’t have anything to do with it, but we don’t want that. We want them to share accountability and that’s why we don’t give them titles.
01:13 – Of course, they have different skills such as testing, but no titles. They are all called Developers.
01:21 – It’s also important. In many companies, when they say developer, they mean programmer.
01:26 – That’s programmer, that’s different. Anyone who is doing something for the project in the Agile context is called a developer.
01:35 – It can be an analyst, a programmer, a tester, designer, UI designer, or architect or anything else that you need, they’re all called developers. Okay?
01:50 – So, they have to be cross-functional. Cross-functional means that they need to have all the skills needed to create the product, they are not dependent on other people.
02:00 – For example, you don’t want to wait for an external team to do something with the database and then let you continue working.
02:10 – If it has anything to do with the database or anything else, it has to be done inside the team.
02:16 – That’s key. That’s very important.
02:20 – There’s one problem here. Some people think that when we say cross-functional, they think that it’s about individual people.
02:30 – We don’t expect individual people to be cross-functional and have all the skills.
02:36 – Each of them has one or a few skills, but when you have them together as a team, then the team, inside the team, you will have all the skills and the team as a whole becomes cross-functional.
02:52 – So, it’s normal to have people who have only one or a few skills.
02:57 – In practice, what happens is that we have T-shaped skills inside the team for individuals, which means that they are familiar with everything, they have a good understanding of everything that is done in the project, and still they have one area of expertise and there they will have full knowledge, a deep understanding, but they are still aware of everything, that’s the top of the T. That’s a very good thing.
03:30 – They are also self-organized, which means that they find their own way instead of receiving orders.
03:38 – Do you remember our conversation about the different consequences of adaptive lifecycles?
03:46 – One of them was about the way we can escalate.
03:49 – In a Predictive system, your key decisions are limited to certain times and it’s possible for you to escalate them to higher managers, but in Adaptive systems, you’re always dealing with those key decisions, and therefore if you want to keep escalating all of them, then it doesn’t work. You’re always waiting.
04:11 – Therefore, you need to ask the people inside the team to make those decisions.
04:16 – That’s the concept of Self-Organization.
04:19 – It means that we really need it, not only because it’s a good thing, because we need it in this type of lifecycle.
04:26 – There are 3 to 9 developers, remember the meaning of developer.
04:31 – There are 3 to 9 developers inside the team. That’s it.
04:36 – And one reason is that as you see, we don’t have any managers here, we don’t have a hierarchy. It’s a flat system.
04:44 – The Product Owner or the Scrum Masters are not managers.
04:48 – They’re all in the same level, and you know that it usually doesn’t work without a hierarchy.
04:55 – You can’t expect 200 people to self-organize without any hierarchy.
05:01 – That’s why the number of people is limited in Scrum.
05:05 – The maximum is 9 people. It’s very difficult to coordinate, and less than 3 people, it’s hard to even call it a project sometimes, but still even if you do, then the type of Scrum that we talk about here may not be suitable for 1 or 2 people.
05:27 – So, we have 3 to 9 people, but what happens if you have a really large project and you need more people?
05:35 – In that case, you can have multiple teams in Scrum and that is called Scaled Scrum, and that’s a big problem, really.
05:46 – Scrum was originally created for a small team like this, for a small project, and that was almost the case for all Agile systems.
05:55 – That’s one of our problems nowadays because we like Agile and we would like to use it in different types of project and it doesn’t work well with larger projects, and therefore, we have many different ways of scaling up the Scrum framework.
06:15 – We will talk a little bit about that at the end of this section, okay?
06:19 – But for now, know that the term Scaled Scrum is that you’re using your Scrum and you have multiple teams, and almost everything else that we will talk about is for one team, for the normal type of Scrum project.
06:35 – Okay. That’s was it.
06:38 – Just one more lesson about the team and then we will move on to the next topic.
06:44 – My question.
06:47 – Who is the Project Manager here?

Who’s the project manager in Scrum?

Lesson 10: Development Team

Contact your trainer to ask questions