The Development Team
Scrum runs as a team process. Part of the Scrum Team is the Development Team. Having a dedicated team of professionals delivering fully “Done” product is something that every form of Agile can relate to. An unfortunate side-effect of the name is that not every team is created with the ability to deliver a “Done” product.
Software development takes multiple people. The people who need the software. The people who translate that need to something that can guide a build. The people who take that guide and actually build something. The people providing the architecture that it is built upon. The people testing what is being built. The only people in these groups that are almost 100% of the time software developers are the people building something. In some organizations the people providing architecture are also referred to as software developers, but not in all. Additionally, not all that architecture is going to be software related, some could be specific hardware.
In some Agile transformations the idea of the Development Team is taken as the Software Developers. Scrum does not help matters by specifically calling out the only title on the Development Team as “Developer.” Looking above at the incomplete list of who is needed to create software we can immediately tell that some people are missing. The question then becomes, where do these non-developers go?
Decisions are made to have the analysts not on the team. The testers are given the Development Teams “Done” work to test after the fact. Architecture groups are formed and divide their time between all the teams in the organization. When this happens Scrum fails. Agile breaks down. Things need to change.
The key point that gets missed is that the Development Team is not just a place for developers. A better name for this team might be the Delivery Team. Instead of calling all team members “Developers” perhaps it is time to call them “Team Members.” This is the team that delivers a potentially releasable product every iteration. The team should not be hindered by analysts not being available, architecture requiring weeks of process and forms, or throwing code back and forth with a testing team. These people belong on the team right next to the software developers.
This team takes the needs of the people who the software is for as an input. That isn’t to say they work in a bubble of isolation, but their first input is that initial requirement. The team needs the ability to translate that requirement all the way to a product filling the needs of the user, part of which is fully ready every iteration.
This requires people with skills in working with the user to extract what is really wanted and needed. There need to be people with the authority to decide on technology and structure for the product. The product needs to be tested within the team as it is being built. The team needs to be cross-functional.
Agile, even the Scrum Guide specifically, does not call for every member of the team to be able to do any job required for achieving “Done.” With the level of specialized knowledge and skills needed for the various tasks this would be nearly impossible anyhow. It is the whole team that needs to be able to do any job required to achieve “Done.”
To grow Agile beyond software development we need to be sure that we aren’t excluding others based on terminology alone. Scrum could work well for a team creating a school curriculum, but not one of them will likely relate the title “Developer.”
Do you find resistance in getting all the required talent on your Development Teams? How do you compensate for that and still reach a valid “Done” state every iteration?
