The 11th post in my series on the Agile principles is ….. Self-organizing teams.
“The best architectures, requirements and designs “emerge” from self-organizing teams.”
How can that be???? Surely a team needs a leader dictating the direction to deliver the best results. Just as a sports team needs a coach / manager. Or does it????
Actually a team does not really need a single responsible person “no top” dictating who will do what. (At least not in the old fashioned sense of team management often still found in many organisations.)
Assuming the team members have the required skills to create the product and roles within the team are clear the team members should be more than capable of organising themselves. To return to my sports analogy, the coach plays a big part in team training and selection. But during the game (or sprint if you like) the coach takes a back seat as the team has to adapt / react to the game as it progresses in real time.
Within Agile the scrum master will be supporting the team, helping plan their training / development plus diverting any unnecessary “politics” away from the developers. Leaving the team able and ready to do what they do best, develop code. (Without the need to constant top down management.)
This principle is actually quite fundamental in supporting the earlier Agile principles. For example: for Agile to work the developers need to interact very closely with the actual business users. This implies making decisions rapidly and taking responsibility for the associated outcomes. You can’t expect the developers to take on this responsibility without also allowing them the space to self-organise their work.
Let’s just go back to the underlying principle I quoted at the start, what is implied by the word “emerge“? Agile by its nature is about evolution not revolution. Delivery in regular small chunks means the solutions evolve. During that solution evolution best practices, new technical advances and refinements in supporting processes will also evolve or “emerge”. All of these enhancements will not “emerge” from senior management passing down instructions, they will grow from the bottom up driven by the delivery team.
So what does this specifically imply in the Microsoft Dynamics CRM world?
CRM projects (by their nature) require some pretty skilled / experiences developers. Also CRM solutions can be created relatively quickly also the business requirements in the CRM space tend to be changeable. And of course, business expectations on rapid delivery are high. These are all reasons why generally Agile is a good approach to CRM development.
But specifically the nature of the “developers” and the need to work very closely with the business will mean self-organising development teams fit perfectly with CRM projects.