7 things about working in Scrum Teams and Microservice Architecture

1. 1. SAFe is not scaled if you get requirements in big bulks every 6 months. This is fully explained in this article: https://medium.com/@almirx101/scaled-agile-framework-safe-isnt-really-scaled-if-you-f933fc78a738. This can be avoided.
2. 2. Microservices are micro if you follow the rule of “single purpose, singe microservice”. You need to establish the guidelines for your teams and you need to keep each other in check. Otherwise, they become macro-services or even worse, monoliths in the cloud. Old habits are hard get rid of, but it is possible.
3. 3. Story estimation by complexity value may not work for you. This may not work when you are doing sprint planning because you would not know how much you can commit into the sprint. It also does not help you predict how much work you have in your product backlog. Complexity does not directly proportional to the level of effort. That’s why story point estimation generally works better when you talk about the level of effort.
4. 4. Watch for this anti-pattern: Building an enterprise-bus type of solution centralized for everybody with microservices under the hood does not really make your architecture a microservice type of architecture. If you find yourself centralizing things or coding a hub that everybody shares, it means that your design is becoming an anti-pattern in your microservice architecture.
5. 5. From DevOps point of view, automate the heck out of everything or at least have that attitude with the team on the floor because good attitude radiates.
6. 6. Manually test to get the insight of how things work or are supposed to work, and then write API automation code. The common mistake is that you tend to roll up the sleeves right away wanting to write automation code, but you end up automating without understanding. The QA automation engineer should know the API as good as any other client of these APIs and even better. In a nutshell, manual testing is about getting the insight into your application and automated testing is about making sure what worked before still works
7. 7. Understand microservice dependencies, paint the big picture and have low-level engineering monitoring in place for each group of microservices. Having this type of view into your system will save you so much time with troubleshooting issues in production; it also gives you that extra confidence to launch more often because you have ability to see the impact (positive or negative) very easily. The value of understanding microservice dependencies is explained in this article: https://medium.com/@almirx101/microservice-dependency-analysis-tool-trust-me-you-need-this-cdd25b934c6c.

Thank you for reading.

Almir Mustafic