4 ms·

I absolutely think you should plan out how your customer will solve their problem with your product, including concrete examples, and make sure you are always h

I absolutely think you should plan out how your customer will solve their problem with your product, including concrete examples, and make sure you are always headed towards that goal. I'm very waterfally that way. In this case I'm talking about the tasks in each sprint. I think 1 day of planning per sprint is a lot. We are supposed to be agile. If we missed a task, swap it with another. If something isn't actually important, bring in something new. We end up doing this anyway... so why all the upfront planning each sprint? Related back to the above comment, (my opinion) people really love to establish rules and processes and are not able to handle ambiguity. I spend a lot of time (remember the 4 hours a week) arguing whether a story is a mouse or a hedgehog. IMHO it's splitting hairs, let's just do the work and we estimated a little wrong it just isn't that important.

scarface74 4y ago
I don’t work for a service team. I work in Professional Services. I was working on a project and I found a bug in one of the APIs. I reached out to the service team and they found the bug - it was a 3 line change in some front end code (long story). They put a fix in almost immediately. But as I was tracking the weeks long deployment process across regions, I came to appreciate how costly any changes are at the scale of AWS. You have to measure twice and cut once. My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers. I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.
- throwaway9191aa 4y ago
  Oh yes, the pipeline deployment process is pretty amazing. I agree, for good reason. My manager has actually recommended I look at profserv teams because of the ability to deliver results for customers. When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now. Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems. I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.

scarface74 4y ago

I don’t work for a service team. I work in Professional Services. I was working on a project and I found a bug in one of the APIs. I reached out to the service team and they found the bug - it was a 3 line change in some front end code (long story). They put a fix in almost immediately. But as I was tracking the weeks long deployment process across regions, I came to appreciate how costly any changes are at the scale of AWS. You have to measure twice and cut once. My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers. I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.

throwaway9191aa 4y ago
Oh yes, the pipeline deployment process is pretty amazing. I agree, for good reason. My manager has actually recommended I look at profserv teams because of the ability to deliver results for customers. When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now. Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems. I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.