This is the first in a series of small posts aimed at new Scrum teams or those who have been doing Scrum for a while but are struggling to net the positive results they’ve heard about when going Agile. I’d like to start with a handful of highlights from the Scrum Guide:
- The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master…
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment…
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person…
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis…
All too often, key elements of Scrum fundamentals are ignored or rejected, because they are viewed as not applicable to the organization adopting it. These teams mistakenly assume from the beginning that they should tailor Scrum and require removal of these elements.
One thing I often see with customers adopting Scrum (as distinguished from other Agile frameworks) is the perception that they must avoid departmental “silos” in order to use it. Everyone must be one, big, happy team. Scrum only asks them to ignore these silos, not tear them down. The culture of departmental silos is strong and is, I think, a leading contributor to the failure or inefficiency many teams experience trying to implement Scrum or Agile practices.
In Scrum, everyone developing the software is part of the Development team. There are only 2 other people in the team: the Product Owner and the Scrum Master. There is not further distinction or description of other roles in the standard.
There is no other requirement or limitation I’ve seen as to who should be in the Development Team; only that the team collectively possesses all of the skills and capabilities required to create the product in increments, and that the team owns all of the activities, effort and project decisions.
To my mind, this means that roles should be left at the door and focus should be on activities. This does mean we can leverage our individual expertise and experience instead of our job titles. Ideally, Scrum says that an effective, self-organizing team is the best arbiter in deciding how to leverage that expertise and experience.
All this leads up to one (of many) question I hear my customers asking me and themselves: “Where does my Business Analyst (BA) and Quality Assurance tester (QA) fit in the Scrum team?” I feel this question has its origin in the apparent disconnect between the team approach in Scrum and the way many IT groups are organized (see silos above).
Here is where I suggest that the BA and QA are -or should be- members of the Development team. In my activity-centric approach, the activities involved in building and managing a product’s development lifecycle end-to-end, necessarily include those owned by the BA and QA. If the team is to be cross-functional (bullet 2 above) then these activities and their owners belong in the Development team.
To see this in practice, you can start by decomposing and mapping out all of the activities that are required to deliver functional software that delivers against the stories in the Product Backlog. Once you’ve listed the activities, you have a good idea of the team to gather that can execute those activities in their entirety.