Rename "Development Team" to "Delivery Team"
In my opinion, there are at least three rationals for my suggestion. I look forward to your insights and thoughts about this suggestion.
1.) The term "Development Team" fits well for software development teams - while term "Delivery Team" could also be appealing to other areas outside software development. For example we deliver trainings, we delivery hardware, we deliver marketing campains...
2.) The members of a "Development Team" are often seen as "developers" - missing all the other roles that are necessary to create a shippable increment, such as testers, build and integration specialist, etc. Yes, we say the team must be cross-functional and I believe the term "Delivery Team" would address this better than "Development Team".
3.) "Delivery Team" is also more goal oriented to me - get things out to the public - while development seems more internal to me. So "Delivery Team" would add more customer focus, in my opinion.
David Sabine commented
I do not support this proposal and don't believe it would have any positive benefit.
The development team is all about delivering working software, I like this proposal.
Nimesh Contractor commented
Yes should rename development team to Delivery team.
in development team there are testers , analyst or architect included and they are not developers.
But they are part of the delivery team to make task done.
PSM Guy commented
+1 Alasdair Macleod
Josh Bruce commented
I apologize. I voted for this because I think it's a wonderful step in getting us "there" - wherever there is. My apology is that I did not read the other comments before posting this one; therefore, have no idea if this is a repeat.
I think, the issue raised is 100% valid.
Further, it does not address what I consider is a bigger issue - separation.
The PO and Scrum Master are not, strictly speaking, part of the "delivery team" (despite being part of the Scrum Team). This separation can present us with an accidental hierarchical antipattern, which is, admittedly, the truly complex problem, from my experience.
This antipattern may be an issue of not fully embracing the concept of:
- Service to others
If you embody these things already, this may seem strange, but having the PO and Scrum Master exist outside of the "delivery team" (only using the term because context of this request) can lead to feelings by both POs and Scrum Masters that, in my opinion, they should be willing to, "Show up, roll up, and get dirty with the 'delivery team'," if necessary; or, at least make transparent to the "delivery team" what they are doing to support them somehow.
Ahmed Moawad commented
Great suggestion Ralph and a great discussion by everyone!
The name "Delivery Team" emphasizes a great aspect of the team's responsibility. I very much like it, but I can also relate to other's concerns, especially Michael James's. So, here's another proposal.
What about calling it the "Execution Team". This can be suitable as:
- It's agnostic from software and other businesses where scrum is applied
- It covers the cross-functional nature of the team
- It's short, I don't like a 3-words name
To help you make up your mind, here are the alternatives suggested in this thread:
- Delivery Team
- Product Team
- Product Development Team
- Product Delivery Team
- Increment Team
- Execution Team
Ralph Miarka commented
Mike, I see your point that the "Uses of Scrum" section tries to add clarity of what "develop" and "development" means through examples and the last sentence. Though "development = programming" is (to me) a piece of complex work already.
And the Scrum Guide says: "The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint." Here I read that "Development" is defined as "delivering" - to me that makes even more the case for "Delivery Team". When reading the comments I see the limits of this term too and there seems to be some desire to change the term. Thus, I wouldn't say this is "completed".
PS: This suggestion seems also related to "Slightly change the Scrum Roles definitions to avoid newcomer confusion" => https://scrumguide.uservoice.com/forums/241958-general/suggestions/31757773-slightly-change-the-scrum-roles-definitions-to-avo
Mike Jones (MikeJonesTechno) commented
I believe this is addressed by the 'uses of Scrum' section in the November 2017 update to the Scrum Guide which clarifies "development" refers to complex work in research, product development, releasing, and sustaining operational environments i.e. develop and development does not refer to 'programming'.
I suggest this could be marked as completed and improvements to the 2017 wording raised in a new suggestion.
Mark Arrowsmith commented
Like they say in programming... naming things is hard!
I was in favor of Delivery Team but see lots of good points as to why that term may also have unwanted connotations the same as Development Team.
Now I'm conflicted, as to what to call the team!!
I do however think that "Developer" is too heavily associated with Programming in the English language now, and this upsets/does not seem to fit, not just the people specializing in Testing or Analysis but also those outside of the IT profession where Scrum is being used more and more.
Pierre Mengal commented
I vote for your suggestion, but I prefer "Product Development Team" than "Delivery Team".
Denise Wolf-Hill commented
I am helping non-software-developing teams use Scrum, so I would love seeing the guide shift away from Development team for two reasons: 1. New people always seem to ask "but what about testers," causing wasted time re-explaining this over and over; 2. The term does not resonate with non-IT people whose product increment is not software, but something else.
please do not -- unless we talk about delivering an order at a table
Frank Gales commented
In bigger organizations there are / can be some teams besides development teams that help in getting the product to the customers and who keep contact to customers.
A delivery team in a release oriented delivery can have the task to organize the delivery e.g. fix dates for quality gates or organize tests outside the ones run by the dev teams. In case of continuous deployment a delivery team could be the team that decides on what features should be switched on for productive use. I have products in mind with several hundred developers involved.
A product team in big organisations could be a team that is in tight contact with the customers being the catalyst for the product roll-out and the dev request roll-in. You would say that this should be the task of the product owners. In case you have for example 20 teams working on a product it may be very difficult to establish the direct contact between the dev teams and a big number of customers. There will be contact between customers and dev teams / POs but it does not scale well without dedicated people / teams.
So I would keep the name development team.
Richard Banks commented
The most common problem with the "Development Team" name, is item #2, and organisations forgetting about the cross-functional aspect of the team.
I personally like "Product Delivery Team" (because delivery is important :-D), and the D-team is delivering on the Product Owner's vision.
On the other hand, Product Development Team is an incremental change to an existing name that makes it more apparent that the team needs to be concerned with "product development", not just in a group of software devs performing the activity of "development".
Joel Silberman commented
How about calling it the "Increment Team?" This makes its accountability clearer, which is at the heart of Scrum: i.e., to develop and deliver an Increment of "Done" potentially releasable product every Sprint.
This would help reinforce the message: If we don’t have an Increment, we don’t have Scrum. (“Development” activities alone are not enough. There must be an “Increment.”)
Michael James (MJ) commented
I'm opposed to this. To me "delivery team" implies we are just order takers not involved in the research, discovery, and analysis. We don't just deliver, we develop. The best solution would be to stop using "Scrum Team" to describe the development team + the PO + the ScrumMaster. Unfortunately that isn't seen as politically possible, so "development team" (or maybe "product development team") is a fair compromise.
Look at the "Scrum Developer Open assessment" at Scrum.org. There are lots of questions there about testing and integration.
However it doesn't really apply to people who use Scrum outside the software development arena who also have to be called Developers (there are no exceptions to this rule) but do not need knowledge of technical debt or test harnesses and so will be assessed as really bad Scrum Developers.
Alasdair Macleod commented
Its a pity that programmers and even Scrum Masters have appropriated Developer to mean programmer. But if it is changed to Delivery team does that not actually describe the Product Owner as well as what is currently the Development team or is the Product Owner not involved in Delivery. Does it not also play into the ScrumBut currently quite popular where the Scrum Master & Product Owner are rolled up into the Delivery Manager as most organisations would see a Delivery Team as the perfect description to be managed by a Delivery Manager.
Mark Levison commented
I would be happier with "Product Development Team" - but would settle for anything that makes it clear Scrum isn't just about the coders, but everyone on the team. I would also like it to be clear that Scrum works well beyond just software.
Ralph Miarka commented
I also like the term "Product Team" and the point by Mikkel that "Delivery" can be part of the DoD.
And I can also see the point by Stefan that in the worst case "you delivery what I (PO) order" could be inferred.