Structuring Teams

ESDC has been doing Dynamics 365 development for a long time on our internal infrastructure and has been fairly successful in delivering solutions on the product. We have now transitioned to the cloud and have access to many more features.  The challenge that comes with these great new features is that it may affect the way that we structure our teams and how we deliver and evolve solutions.   

 Here is some back-story on the issue. In our legacy environment, the premise for our Dynamics solution delivery was that the team operates as a cross-functional team with the ability to deliver a solution to production with little to no blocking dependencies outside the team. This means that each developer needs to cross-train to learn all parts of the technology and design process to be able to deliver a solution to the client. This includes activities like: 

• Business Analysis and options assessment with the client 
• Modeling the data 
• Creating the database/Entities 
• Configuring the screens 
• Testing 
• Creating Business Rules/Code/Integration 
• Working with the client on User Experience 
• Create Business Process and factoring this into the system 
• Working with the client on reporting requirements and creating reports 
• Data Migration activities 
• Security controls 

This was a long list of skills and the expectation was not for everyone on the team to master these but to work as a team to cover them. Some people were stronger in working with the client and others were stronger in Data Modeling or Migration. The key was that in a normal team size, typically 3-8 people, the team was able to cover these.    

The challenge with the cloud is that there are so many new technical capabilities, including: Power BI, Artificial Intelligence, Power Automate, Canvas Apps, PowerApps Portal, Application Insights, Azure Data Lakes, Common Data Service, Virtual Agents, Web Accessibility, Azure Maps, Altered Reality, etc..... 

It is quickly becoming impossible for a fairly small team to cover these off due to the added complexity. This had led to thoughts on team structure and how this can changed without introducing major roadblocks.   

This is not a unique issue so hopefully we can find a solution from the industry. I have just started reading the book "Team Topologies" . This book has the best alignment with my thoughts on how to scale without introducing bottlenecks that slow things down.   

I am only 20% through the book but there are already a lot of great concepts that we can apply.   

Here are two big ideas: 

• Conway's Law is a concept from the 1960's that states that organizations design systems that mimic their communication structure. Since this communication structure is often driven by the Org chart, this should make organizational design a key focus for Architecture teams. Instead, it is typically an afterthought.   
• Cognitive load is the idea that a person can only effectively contain so much knowledge on technology in their brain. This has become more important in IT as systems have become more complex. For complex systems, it is not easy for a single person to even know all of the pieces let alone have deep knowledge of them. This is why a team is important.  

Hopefully when I finish the book I will have some more ideas and maybe a new Organizational model that I can propose.   

Thanks for reading and feel free to leave a comment.