If your projects are running without any milestones defined, I have very bad news for you and the managers you hire.
Great engineering teams focus on milestones instead of projects
61–70 of 93 posts
Re: Great engineering teams focus on milestones instead of projects
#62Great engineering teams have great engineers. Nothing else matters.
In my experience, there's no architecture or methodology that can make bad engineers build good software. But there's definitely ways to ensure that good engineers end up making shit software.
Re: Great engineering teams focus on milestones instead of projects
#63It seems NASA understands the value of milestones https://blogs.nasa.gov/webb/2021/12/24/key-milestones-after-...
Re: Great engineering teams focus on milestones instead of projects
#64The ideas in the article are similar (in a good way) to Shape Up by Basecamp [0]. I once got so inspired by it I translated it into Russian, just to better understand what's written :-) If you're intereseted in the topic, I highly recommend investing some time and reading it.
Re: Great engineering teams focus on milestones instead of projects
#65Earlier quoted context omitted.
At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...
The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
We usually start by discussing the outliers on both sides.
This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
Re: Great engineering teams focus on milestones instead of projects
#66> Estimating one to three weeks of work is easy So a slightly more flexible sprint? I personally hate sprints - they tend to be inflexible and sometimes force you to make the wrong compromises. They are typically filled with many disparate tasks that often require you to context switch back and forth repeatedly. If you under estimate the time some tasks take, the numbers paint you as a weak performer. Those who game…
That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing. Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed. [0] http://pokershirt.io
I'm also a fan of using Kanban for most corporate line-of-business development.
In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum.
At the end of the iteration, they have a unfinished tasks and one of two things happens.
The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up).
Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close.
They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem.
And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality.
Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.
Re: Great engineering teams focus on milestones instead of projects
#67Earlier quoted context omitted.
That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing. Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed. [0] http://pokershirt.io
I'm also a fan of using Kanban for most corporate line-of-business development. In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum. At the end of the iteration, they have a unfinished tasks and one of two things happens. The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to comp…
I have seen much of these problems with Scrum, as well. Redefining "complete" so we can book the points, but actually finish it in the next sprint is very, very common. Finishing early, starting on a future story, but the scrum master asking you to not bring that story into the current sprint, in case you don't finish it, is also a frequent occurrence. My view is "if I don't finish it, it rolls over, so who cares", but this is frowned upon since it throws off the reports.
Re: Great engineering teams focus on milestones instead of projects
#68Great engineering teams have great engineers. Nothing else matters.
This still won't make a great company. I've seen companies work on great tech, but had no marketing or sales in place, so very few resulting customers. You build it and nobody shows up.
Or companies that had no support/customer service, so engineers are constantly getting interrupted. We get cranky real quick when this happens too many times.
Or companies with poor product management, so engineers waste time building the wrong thing. This goes on despite our objections, only to have it thrown all away in a month or two.
Great engineers are necessary, but not sufficient, for a great tech company.
Re: Great engineering teams focus on milestones instead of projects
#69Earlier quoted context omitted.
The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
We usually start by discussing the outliers on both sides. This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
Yes, that's exactly what I meant to describe.
Re: Great engineering teams focus on milestones instead of projects
#70Earlier quoted context omitted.
Sorry, definitely wasn't saying "hide projects from devs" As PdO I see my job (and also that of my partner Dev Manager) as sheltering dev from the shit churning shit above and my sole purpose as providing backlog/semi-coherent guidance. My downward job is to make sure every 2 weeks some contiguous stories get created and I sign off on their completion on the way back up - and if my requests match what I get back, I h…
I still think you’ve set things up so that the direction for the whole team almost exclusively has to come from you. If you could share this responsibility with the team so they know the context and outcomes desired by the business, you’ll have a larger pool of good ideas, including from folks who deeply know the code and push the roadmap from that perspective. E.g. creating a holistic thinking environment: https://h…
On the bi-weekly sprint planning - yes.
From what's actually on the backlog - definitely not.
Opportunity Team meetings (or stakeholder chats - lead devs, architects, support peeps etc) always cover the general direction we want to go and are where the ideas for the backlog come from.
Example of easy benefit is if we have two things we want the product to do - this is where you learn what the options are and more importantly the rough costs/impacts. If something's going to cost 10x as much and require refactoring, I suddenly decide I don't want it as much as the other option.
Can also come up from mid-sprint from dev. (Real example) I had a US to add a new button. Dev noticed there was an internal 'button framework' already in place (as somebody had some a good job in the distant past). She asked if I could add a new US for next sprint to continue this work, so she could extend this framework and allow us to publish it. i.e. Focus on adding new controls to the config tool, and then delivering on the original US with a bit of config. I had no idea this untapped potential even existed - but for 2 weeks effort of one person, my product now has a configurable UI. Lost count of the number of issues where a customer query can now be answered with - Just add a new button/tab/menu (and then over time it's been easy to add contextual controls, make more tokens available to the target builder etc etc)
"Technical Debt" is often mentioned (hidden cost of a hacked together mess, increasing the cost of the next feature to be piled on top). What's satisfying are the "Technical Assets" like this - not just for me as I get a better product, but for the dev who can take pride in building something elegant and knowing this feature is theirs.