I like this thought. Would these ideas apply much to a small team that doesn't really have enough overall activity to develop "rates" yet? Would love to take a small step in this direction for the future.
Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
I apply this with 2-pizza teams so it doesn't have to be big teams. But if you're talking about 2-3 people, I prefer agile's "people over process" and just poll the group asking how they'd rate quality, what's working, where are the gaps, etc
I like this thought. Would these ideas apply much to a small team that doesn't really have enough overall activity to develop "rates" yet? Would love to take a small step in this direction for the future.
I apply this with 2-pizza teams so it doesn't have to be big teams. But if you're talking about 2-3 people, I prefer agile's "people over process" and just poll the group asking how they'd rate quality, what's working, where are the gaps, etc
I am with James.
I just published Error budget: Google's solution for innovating at a sustainable pace that explains how do you know if you are going too fast.
A couple of tools that you may also want to take into consideration: