I am part of a new and small agency/consultancy and we are having decent success and growing pretty steadily. Within the past month we have doubled our team and now have a lot of pressure for everyone to know exactly what is going on in different areas of the process. And we are having growing pains trying to figure out the best way to manage everything. Specifically related to hours/budgets/time.
To give a specific example, one of the roles we’ve added recently is a product owner (aka more friendly way of saying project manager) and now her job is to make sure we are within budget and on track. So as a developer this is obviously causing significant friction for me. A lot of checking in with me to see how much i’ve done, how far i am, is there anything i can do quicker/easier or cut altogether.
One example process that we have recently had implemented is a weekly meeting on monday where the product owner team has allocated time for each developer per project. i.e. You have 10 hours on project A, 3 hours on project B and 15 hours on project C. And then we as developers are asked if those numbers ‘feel right’ to us. And we’re able to say they’re not and have the hours shuffled around but its very hard to grok my effort in terms of hours in the future like that. I can understand how the management team needs this information but I’m also struggling on if this data is at all accurate and on that note is this just an exercise in futility. I really don’t like this process, but understand I can’t really make a change in how we do things unless I have a better idea. Which is where I’m at now – stuck. I really want my fellow developers to focus on the quality of their code more than the time frame in which it is finished. However I do know both of these need to be a concern, I just want quality to be the prime factor. How do you reconcile the two? As an agency/consultancy we have to work within our client’s budget and can’t always get a client that says “here’s a blank check. I trust you’ll do the best work possible and you’re worth it.”
So I’m curious how thoughtbot, and others on the forum are welcome to discuss as well of course, manages their process. We use pivotal tracker and assign points to user stories, but seems to always end up degrading into ‘how long do you think this will take?’ in terms of real time blocks instead of relative effort. Would love to hear about how you track hours spent on a task or on a project as a whole. How product owners maintain visibility on it all as well as the eternal question of ‘how does one make everyone happy?’ If that doesn’t give you much direction on the discussion, I’ll add a few specific questions below.
How do you manage the trade off between making it under budget and making it in a sustainable and correct way?
How do you reconcile the conflicting goals of product planning management and development? (cheaper vs better)
What are some good methods/processes to track hours but not add an overbearing pressure of hour constraints to developers?
How do you plan for the next week of effort allocation?
How do you keep a growing team from developing cliques that end up feeling like an ‘us vs them’ mentality?
How can you limit friction and distress for developers?
Look forward to hearing everyone’s ideas
p.s. im not sure if the learn category is best for this but i didn’t see a better category.
Wow, that is a lot of questions so I’ll try and hit as many as I can effectively answer.
Quality should be a goal of the projects and everyone should be involved in making sure that is the case. That also comes with a caveat that what we as developers see as quality may not always be necessary. Going overboard only kills time and productivity so you must reach a certain limit of ‘good enough’ on quality.
These aren’t too opposing forces, you have to work together. I would give all my estimates with the included time of making the code to be quality code. If you get push back from that and need to provide another estimate, I would explain what the downside to that is and explain that you’re only delaying the time it costs and adding that time to future features.
We don’t track hours in the way that most consultancies do, we are only assigned to one project at a time so we only track how many days you worked that week and each day is 8 hours. Sorry I can’t be too helpful here.
We already know from the project kickoff how long we will be allocated to the project so the only thing week to week to discuss is what features are coming up and who will be handling them. This allows us to use our weekly retrospectives and daily standups to determine what we are each going to tackle. We then make sure to check back on these ‘goals’ at the end of the week retro to see how we progressed.
Team rotations! Put different people on each project. Obviously friendships grow in a business but making sure that everyone is comfortable working with everyone else is key. We rotate off of projects typically every 3 months. This gives us the ability to make sure that we put new people together constantly and it also has the added benefit of being able to key fresh ideas and eyes on the projects.
Don’t worry, be happy! Seriously, the number one thing is promoting open communication. Any ideas you have should be well received both between management and the developers but also between developers and clients. You should be able to talk about what is working well and what is not at all points in your project. Speak up, even if you don’t necessarily have a solution, others probably feel the same way and you can all think of a solution. Keep ideas constantly moving and flowing.
This sounds very strange to me. Why would this obviously cause friction? I would be happy if the product owner checks in with me to make sure everything is going OK. It means that they are managing the project which is precisely what their responsibility is. It means that they are doing their job.
It sounds like a personality conflict where you feel like the product owner is not being respectful to you, or perhaps that you have not communicated to them the importance of high quality code.
I think that it is about sharing perspective. As developers we accept that projects should come in under budget. If not, the company runs out of money, the developers and all the other employees don’t get paid, and the company closes. It’s a loss for everyone.
Product owners (as well as everyone in the company) should understand that code quality is very important. But how would a non-developer ever be aware of this? How would they even know that there is a concept of code quality? As developers we need to educate them and explain to them in terms that they can understand.
With a shared perspective, the ‘us vs them’ mentality disappears. It’s about mutual respect and putting the company before our own desires.
If that doesn’t give you much direction on the discussion, I’ll add a few specific questions below.