HI Sten. I really enjoy your post. However, I just started the start-up project and all of my development team is working over-sea. It is being quite while (4 months) , but the outcome seems really bad. Should I negatively judge them for having a delayed so long?
Thank you
Hi! A lot of people have already given great responses so I'll try not to repeat their advice. As I said in the post bad outcomes can be valuable if you learn from it and fix things.
As it stands it seems that maybe there's a lack of communication/visibility (I'm echoing @ben
here). And my number one suggestion would be to start having weekly demos if you don't have them already. That's a quick, easy way to make sure that you and your dev team is aligned, and it'll give them the opportunity to ask questions and clarify the scope of the project.
From my experience, most projects end up delayed or with a different result than the original specs. And that's where Agile practices come in handy to make sure you can revise your backlog often, change priorities if needed, but more importantly to ensure that you can ship bits of value early and get feedback on it.
So, the second thing I'd ask is how far are you from being able to put your product in the hands of people? If it's not done already you need to absolutely focus on getting to a shareable state, even if it's with close friends. The reason why it's important is that on the one hand, it'll give the team a sense of completion and will help to keep people motivated, and on the other hand, it'll teach you a lot about what people want.
Should I negatively judge them for having a delayed so long?
You need to embrace that responsibility as well. It's rarely the fault of a single party when things go south, and there can be many factors responsible for a delay in delivery. The best approach to move forward, in my opinion, would be to address that collectively rather than finding someone to blame.
Say "Alright, this is where we are, and this is where we need to be. What's the best way to get there folks?". You need to reach out to your team and see what they think, and understand how they can best deliver the product. Asking that question is a way to empower them and make them accountable. If you just tell people how they should do their work, then you'll only be projecting what's best for you.
I hope this helps, in the end, it's a lot about communication.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
First question: are you a developer? If so you should have a feel for what needs to be done and how long it should take. If not you need to have a strong tech lead that does and will take on the responsibility to deliver.
Expectations should be communicated, planning and estimation performed, and commitments to deliver made.
What have they to show after four months? If you are using agile the result of each sprint or iteration should be visible to the product owner. If not you have to know why. If you have seen nothing in four months I would suggest you lay down the law; give them two weeks to get a minimum viable product, or at least demonstration of progress, or they are gone.
While I agree with Ben that you need trust, and that threats do not help trust, but you must ensure they understand that they must deliver. You also need to ensure that your expectations are in line with reality. But four months work by multiple developers is a substantial effort and should see significant progress.
First can be addressed by enabling proper code review, design guidelines and a involved technical team lead.
All the above three can be addressed easily by periodic check-in. Define the periodic check-in's and what's expected after each phase. This will ensure that there are no surprises at the end. The involvement of product owners is as important and sometimes more important than others. Product owners should be part of these check-in and flag anything that doesn't meet expectations right away.
Managing and working with a remote team is skill and luckily I have always worked with a mix of remote plus office folks. You have to try out things that work for you like tools for collaboration, what's the sync up frequency between teams, etc. Setting up a team from ground up takes time and you should be open for difficulties during the initial phase. Take lessons out of all this and apply them to your next improved process.
It seems like there could be some general lack of transparency, trust, and communication here.
Before judging these outcomes, I'd definitely make an attempt to sure up the communication and shared goal understanding.
How regular are your check-ins, what kind of things are you discussing when you touch base?
There are legitimate, and illegitimate reasons for a delay. I think communication enhancements are the only way to get to the bottom of this and earn mutual trust.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
HI Sten. I really enjoy your post. However, I just started the start-up project and all of my development team is working over-sea. It is being quite while (4 months) , but the outcome seems really bad. Should I negatively judge them for having a delayed so long?
Thank you
Hi! A lot of people have already given great responses so I'll try not to repeat their advice. As I said in the post bad outcomes can be valuable if you learn from it and fix things.
As it stands it seems that maybe there's a lack of communication/visibility (I'm echoing @ben here). And my number one suggestion would be to start having weekly demos if you don't have them already. That's a quick, easy way to make sure that you and your dev team is aligned, and it'll give them the opportunity to ask questions and clarify the scope of the project.
From my experience, most projects end up delayed or with a different result than the original specs. And that's where Agile practices come in handy to make sure you can revise your backlog often, change priorities if needed, but more importantly to ensure that you can ship bits of value early and get feedback on it.
So, the second thing I'd ask is how far are you from being able to put your product in the hands of people? If it's not done already you need to absolutely focus on getting to a shareable state, even if it's with close friends. The reason why it's important is that on the one hand, it'll give the team a sense of completion and will help to keep people motivated, and on the other hand, it'll teach you a lot about what people want.
You need to embrace that responsibility as well. It's rarely the fault of a single party when things go south, and there can be many factors responsible for a delay in delivery. The best approach to move forward, in my opinion, would be to address that collectively rather than finding someone to blame.
Say "Alright, this is where we are, and this is where we need to be. What's the best way to get there folks?". You need to reach out to your team and see what they think, and understand how they can best deliver the product. Asking that question is a way to empower them and make them accountable. If you just tell people how they should do their work, then you'll only be projecting what's best for you.
I hope this helps, in the end, it's a lot about communication.
(As a FYI this is one of the issue we want to solve with Squadlytics by making weekly check-ins easier)
First question: are you a developer? If so you should have a feel for what needs to be done and how long it should take. If not you need to have a strong tech lead that does and will take on the responsibility to deliver.
Expectations should be communicated, planning and estimation performed, and commitments to deliver made.
What have they to show after four months? If you are using agile the result of each sprint or iteration should be visible to the product owner. If not you have to know why. If you have seen nothing in four months I would suggest you lay down the law; give them two weeks to get a minimum viable product, or at least demonstration of progress, or they are gone.
While I agree with Ben that you need trust, and that threats do not help trust, but you must ensure they understand that they must deliver. You also need to ensure that your expectations are in line with reality. But four months work by multiple developers is a substantial effort and should see significant progress.
'Outcome is really bad' is a vague term for me.
First can be addressed by enabling proper code review, design guidelines and a involved technical team lead.
All the above three can be addressed easily by periodic check-in. Define the periodic check-in's and what's expected after each phase. This will ensure that there are no surprises at the end. The involvement of product owners is as important and sometimes more important than others. Product owners should be part of these check-in and flag anything that doesn't meet expectations right away.
Managing and working with a remote team is skill and luckily I have always worked with a mix of remote plus office folks. You have to try out things that work for you like tools for collaboration, what's the sync up frequency between teams, etc. Setting up a team from ground up takes time and you should be open for difficulties during the initial phase. Take lessons out of all this and apply them to your next improved process.
Thank you for the response.
It seems like there could be some general lack of transparency, trust, and communication here.
Before judging these outcomes, I'd definitely make an attempt to sure up the communication and shared goal understanding.
How regular are your check-ins, what kind of things are you discussing when you touch base?
There are legitimate, and illegitimate reasons for a delay. I think communication enhancements are the only way to get to the bottom of this and earn mutual trust.