2 ms·

I used to think I would want to lose the commute. I mean I still do. But the loss of co-located colleagues is a real genuine barrier to effective productive w

I used to think I would want to lose the commute. I mean I still do. But the loss of co-located colleagues is a real genuine barrier to effective productive working. So many issues that affect a "team" - misunderstandings that would have been a chair roll away are elevated to the status of conflict. Code has been written, lines have been drawn. And yet we pretend that it can all be dealt with by more "teamwork".

freitzkriesler2 4y ago
I haven't had this experience at all. My swes are based all around the world and I proudly manage them without having to do all of the annoying agile ceremonies. My philosophy is simple: keep the developers developing. If they aren't then you're wasting your money. I only break out the agile ceremonies for junior engineers who need the guidance and I do it all over video conferencing. But at the end of the day, our products get delivered, timelines met on or ahead of schedule, and typically on budget.
- lifeisstillgood 4y ago
  But what do they develop? How does the business (which is also dislocated over great distances) know what it wants / express it when ... aww never mind. I know the answers Unless you (ie you) are the product owner / guiding light / main decisin maker then any "keep developers developing" is false. But in the likely circumstance that you taking a "product goal" and running with it - then are you getting the recognition and then the linked monetary rewards and access to other resources? or are you just doing a great job while others benefit? I hope it's the former
  - freitzkriesler2 4y ago
    Former is it! I am a product owner. We're a contract dev shop and build a myriad of things, at the end of the day, I define the functional requirements, work with UX designers, and work with my devs to pass that vision along. Once we have the MVP scoped and designs locked, there's a kick off meeting with the devs to explain it all and off we go. I'm particularly precise about how I define my stories with granular acceptance criteria linked to UX designs for how it should work. At the end of the day, I'm just a waiter for my devs to keep them going and prioritized. I don't reap rewards other than a paycheck and the satisfaction of a delivered product. Post MVP, we'll define a roadmap of what the customer wants depending on budget and do 4 week sprints to deliver. After working in a agile safe corporate environment for years, this was a breathe of fresh air. I see the agile tools as guidelines for picking and choosing depending on need. This wouldn't work in my old corporate job. Hope this explains it.

freitzkriesler2 4y ago

I haven't had this experience at all. My swes are based all around the world and I proudly manage them without having to do all of the annoying agile ceremonies. My philosophy is simple: keep the developers developing. If they aren't then you're wasting your money. I only break out the agile ceremonies for junior engineers who need the guidance and I do it all over video conferencing. But at the end of the day, our products get delivered, timelines met on or ahead of schedule, and typically on budget.

lifeisstillgood 4y ago
But what do they develop? How does the business (which is also dislocated over great distances) know what it wants / express it when ... aww never mind. I know the answers Unless you (ie you) are the product owner / guiding light / main decisin maker then any "keep developers developing" is false. But in the likely circumstance that you taking a "product goal" and running with it - then are you getting the recognition and then the linked monetary rewards and access to other resources? or are you just doing a great job while others benefit? I hope it's the former
- freitzkriesler2 4y ago
  Former is it! I am a product owner. We're a contract dev shop and build a myriad of things, at the end of the day, I define the functional requirements, work with UX designers, and work with my devs to pass that vision along. Once we have the MVP scoped and designs locked, there's a kick off meeting with the devs to explain it all and off we go. I'm particularly precise about how I define my stories with granular acceptance criteria linked to UX designs for how it should work. At the end of the day, I'm just a waiter for my devs to keep them going and prioritized. I don't reap rewards other than a paycheck and the satisfaction of a delivered product. Post MVP, we'll define a roadmap of what the customer wants depending on budget and do 4 week sprints to deliver. After working in a agile safe corporate environment for years, this was a breathe of fresh air. I see the agile tools as guidelines for picking and choosing depending on need. This wouldn't work in my old corporate job. Hope this explains it.