As a developer, have you ever found out about something too late?
Timing is everything. If you're meeting up with a friend, it's a world of a difference if they bail when you're still at home versus already on the train there.
This principle also applies to building software. I built an MVP that helps managers with this (letting them know early what work will fall behind, when Sprint goals won't be hit, etc) so they can alert stakeholders sooner.
But I also want to give developers critical information when they need it. To all my fellow developers out there, can you name some instances when you found out an important piece of information too late (big or small)?
Some time ago, when my older daughter was born, I was eager to create a web app which will allow users to create photo albums with nice templates mixed up with brilliant photos of your lovely kids. As a newby but startaper, I did a market analysis looking for another "photo albums" app and there were 0. I was so happy and dived in development, purchased templates, design, hosting... And suddenly, after some time, I saw a phrase "photo book".... when I searched it I was so upset.... there were tens of applications running for a long time and doing even better that I was dreaming about my app :(. It was my first "failure in market analysis". I wish I knew it earlier. It could've saved me time and money...
Thanks Grigori! This is really interesting - the problem of searchability. I was thinking about issues for engineers working on teams, but what you mentioned is actually quite universal to that case as well. Maybe when engineers are starting work, it'd be helpful to understand what other similar work was already done and proactively surface those suggestions. I know there have been plenty of times when I started on a project, and then when I talked to a few other people about it, they mentioned that another person on a different team had already worked on a similar concept.
Finding the common term for something after looking for it a lot and thinking it doesn't exist is probably more common than people talk about it 😔
Project or feature getting scraped - working for the bin
Thanks Hatky!
Do you think there are times when others knew the project/feature was getting scrapped and there was a lag in the communication? I'm trying to brainstorm ways to give a heads up as sooner rather than later, but I can't think of much outside of faster communication
I don't know, you know how ideas get started, then grow, get approval/certainty, then distribute...
I don't know if there is a clear inefficiency there to be solved, I'm not sure the distribution is the slow part, when it is, it's due to politics or other soft-skill stuff
The biggest thing is more transparency, but I'm not sure there is what to improve really
Yeah maybe it's more about shortening time to review/evaluate impact of features so that everyone knows sooner + actively discusses the merits of continuing work
I'll paint the picture of how I think this goes
company does planning for the quarter, assuming it happens well, we start the quarter working on a thing. (with 2 weeks sprints let's say if that matters, but the project assigned is way bigger than a few sprints to be MVP worthy or production worthy)
One day during the quarter something in either the external or internal environment of a C level person plants a seed of something that is 10x more important than the current plan and he wants to cut the losses on the current plan and start a different one, or at least one new project is going to tear a current one out
The time between that seed until the project is killed take a while
hopefully, with more 'mature'/expreienced groups this is less frequent, but given reality, it always happens
The same could happen in smaller scales or where either some details of the story are missing or have changed in a way that would affect the work but weren't properly communicated
The current agile way is to try to show early versions frequently and far up the chain to the project owner so gaps can be discovered earlier
Two things come to mind:
Thanks Marcus!
For #1 - do you think what's missing are the prioritizations and expectations for the stories? Or it's an underlying problem with lack of the back and forth necessary to come up with the right stories?
The PR pain is so true. Sometimes there are critical comments that get ignored just because people don't want to do the work all over again. It's just a sign that there should've been a design review before any coding started. I wonder if there are ways to give a heads up on major work. Like detecting something that has high number of story points and giving a heads up checklist (design review, talk to security, load testing, etc). Or if something like that would feel more "naggy"
I don't know how much this helps, but here's a go. I don't think anyone could ever pre-estimate any non-trivial feature development—it's all just about managing everyones' expectations in a process that can never be reliably predicted.
I'm a fan of "hypothesis-driven" stories. The focus is the business outcome and not the feature or technical outcome. It makes it more compelling and is open to more and different solutions. Just because someone is a developer doesn't mean that they won't advocate for a solution that actually doesn't add any code at all, maybe even using what exists in a smart way. In short—the idea that coders code, designers design and product owners write feature specs is a terrible misuse of human potential. People are more than their job title! :)
Adding to the process with more steps can feel slow and annoying, but mob-work or pairing is a very informal way of introducing "impromptu design review" without actually calling it that. I'm just a big fan of the positive effects of never ever working alone (at least in development).
Yes, visibility is everything.
The impression regarding the quality and impact of my work is deeply connected to how and how often I talk about it. People don't have a crystal ball, and just completing a task gives 0 idea about how you performed it or how challenging or interesting it was. If I don't go out of my way to discuss what I've been working on, nobody will recognize it, specially being a woman in tech. I now intentionally keep a brag list to remind people during review time.
Thanks Etiene! This is really interesting, because you point out that there are some areas where both the manager and developer want high visibility. And it's actually much harder to surface the good things you should be recognized for.
I wonder if there are ways a brag list could be auto-generated. Maybe particular epics that you've done a ton of work on, or areas of code you worked on that didn't have a lot of bugs, or particular work that took longer / had high story points
Thanks for the help!
https://thakurintl.com/custom-software-development/