The CRM development team are the people who implement the CRM platform guided by the vision and goals set by the product owner and the under the mentorship of the scrum master. It's their role to analyse the requirements, the design, configure, customise, and test features that meet those requirements.
How many team members should be on the CRM development team?
It doesn't matter how many team members your dev team has, as long as the team has all the skills needed to implement the CRM system.
When I implemented a Microsoft Dynamics CRM system for medical asset management at Guy's Hospital, I was the only person in the team for several months before Greg Owens joined the project. (This was a few years before he became a famous racing driver.)
When I was the scrum master for the Salesforce Sales Cloud implementation at Red Bull, Tiffany Chen was the dev team.
So really small teams can work. The Scrum Guide says that dev teams should be at least three people otherwise they may not have all the skills needed to do the work. But an experienced Dynamics CRM consultant can implement a simple system single-handed. I don't recommend a dev team of 1 or 2 people, but it is possible to succeed with teams this small.
How about bigger teams? What's the upper limit?
Communication becomes exponentially harder with every additional team member you add.
If you are nervous at the daily standup that you miss your turn because it takes too long for everyone else to quickly check-in then your team is too big.
If you can't remember what stories the team worked on in the last sprint then your team is too big.
I've found that a team with about seven or eight team members is usually about the limit.
At American Homes 4 Rent, we split the program up so that we had separate teams working on the CRM platform, the website, business process improvement, and the data integration platform. At one point we probably had 30 consultants involved, but the core CRM dev team was never bigger than ten people.
What roles do dev team members have?
Scrum says that team members don't have titles. They might have areas of specialisation but that the team is collectively accountable for achieving its goals.
In my Scrum CRM projects, I've found that team members definitely tend to retain their area of focus. Analysts analyse requirements, architects design solutions, functional consultants configure features, developers develop custom code and integrate systems, and testers invent new acceptance criteria.
But after a few sprints, the team members have an appreciation for each other's skills and become attuned to how other team members work. Analysts write better acceptance criteria, architects design simpler solutions, functional consultants and developers build features that are easier to test, and testers work in parallel with other team members to ensure better quality releases.
Great teams share tasks
In the best dev teams I've worked with, team members often assigned themselves to a task that was outside their area of specialisation. This has lots of benefits for us as team members:
- We broaden their skills so we become more useful to the team
- We improve velocity by removing resource constraints
- We become better at our own area of specialisation by learning how our usual work impacts others
- We expand our knowledge of the system so we don't become reliant on a single team member
Can a business analyst really develop custom code? Usually not, but they can help a developer with a code review. Even if the analyst doesn't understand every method being explained, often the simple act of explaining the code's design out loud to someone else will help the developer enhance the quality of his or her own work.
Great teams uphold agile principles
Great teams uphold the Scrum's values of commitment, courage, focus, openness and respect.
They are committed to the project and to the team's goals. They are courageous enough to tackle tough challenges with bold solutions. They focus on the CRM project without distraction. They are open with each other and with all the project's stakeholders. They show respect for each others' contributions.
Think about the best agile CRM projects you've worked on? What qualities did they have tat made them special. I'd love to hear your comments below.