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.
Brett Maytom commented
It is more about delivery of product than development of the the product. Value is only achieved when we deliver it and real feedback can be received. Until the product is delivered the value is zero.
The scrum.org mission is to "improve software delivery"! So delivery is most probably more appropriate too.
I think emphasizing the development team is more about delivery than development is a better approach.
It also reduces the confusion with software programmers which is just a constant annoyance conversation. But this conversation highlights one of the confusions people have about the guide. I feel we should adapt and try rid these confusions as this is what will address zombie/dark/fake scrum.
Thank you all for the discussion here. I feel the topic is closed now.
Anon A. Anon commented
@KenS I can see your team-oriented spirit shining through! I know you're "actually a big deal", but that attitude wins no hearts.
Ken Schwaber commented
We could really chase our tails on this.
I did a blog post awhile ago that basically said we have important work to do, and quibbling is not one of them. So I made a decision that is pretty good for many reasons and am sticking with it.
There seems to be a misunderstanding. This "delivery team" as mentioned above, does program and test and create marketing initiatives and trainings and ... whatever is necessary to produce regularly a potentially shipable product increment according to their DoD. I do understand that you and Jeff mean all this with the term "development".
You introduced new role names like Scrum Master and Product Owner to clearly identify these new roles. The role "developer" is already loaded. And I often see - due to a long time of referring to "programmers" as developers - that this causes some confusion. Thus, people don't feel included when we speak about the Development Team though they also contribute to the successful creation of the product increment. Therefore I wrote this proposal.
I learned by now that the term "delivery team" is also loaded and negatively conotated and thus neither appropriate. An alternative mentioned in the discussion below is "Product Development Team". Others are also mentioned.
My hope with this proposal is that the adoption of Scrum is simplified and accepted equally by all members of the Scrum Team.
Ken Schwaber commented
"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".
We cannot sneak anything by you!!! We were trying to get the other cross-functional skills to see their role in developing something that is delivered. They are "developers", not just people who program.
Developers of course deliver, if that is part of the definition of done for that Sprint. In my blog, I refer to this in the SDK entry.
You are suggesting that a "delivery" team wouldn't have any development activities?
Eric Lee commented
I would support changing the name of 'Team', 'Development Team' to a more generallised term that teams from fields other than software development can relate to. Fact is there are many teams that do not think of themselves as a 'development' team, or are from other fields that this term does not make sense to them.
What to change it to... i don't think there will ever be agreement.
Personally i like 'Product Development Team'. It's retains the 'Development team' part, but includes the broader 'product' scope, which helps teams better relate that it is 'anyone that contributes to the development of the product'.
I like such group discussions. I overlooked that a "Delivery Team" exists in some organizations (with a "Delivery Manager"), meaning a special team that kicks out the software (thank you, Alasdair for pointing that out to me). In this case this would add to confusion rather than reducing it.
@Anonymous: regarding the downvote, maybe that can be raised with another proposal. I would even vote for that. And could you please elaborate, what I should consider in this case to raise my understanding. I found some aspects of this discussion far more helpful than your (general) comment. I'm happy to learn...
And the number of votes as well as the discussion here indicate to me that there is a problem with the term "Development Team" to some. So how could we adapt this proposal to make it more valuable and to address the bigger picture?
There really should be a "downvote" option (like Reddit I guess?) - this is an appalling idea and shows a complete lack of understanding.
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
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.