I think you got the idea, now you got to play around with it to become more familiar and drag your team with you on this road.
The context on who you're working with doesn't really matter, what need to be understood (but I think you already did) and now accepted is that writing the code is the "easy" part, the hard part of our job is to understand what the client actually want.
Once you have a good grasp around the need, now it's time to do the analysis and planning part (my favorite). Here, we can't really help you, it's all about your experience : you'll fall into dead ends, activate some traps here and there, but hopefully you'll get out of it with a feature. The more and more you'll do it, the more traps you'll avoid. This part is the most important, this is where you'll uncover problems you didn't even think about : What happen if I did X then Y ? Do I end up having Z, or something else ? Does it fit nicely with the already existing code, or do we need a rework in order to keep this maintainable long terms ?
Then, the easiest part : code.
how much time do you guys usually put into planning a new feature ?
It depend on the feature, for complex one I would go for a solid 40% planning, (this includes the comprehension of the feature/problem, planning the workflow and put some times into writing down tests workflows), and 60% coding.
The more you plan, the less obstacles you'll meet during your coding process, as you already eliminated them through the planning process.
Now considering your team workflow :
The planning should be done by the dev(s) responsible for the task, then shared for advices when needed. Do not block your entire team into a meeting where they'll have to agree on a design or an architecture they won't work on (for now at least). This is usually a job on his own.
To avoid falling into the same traps over and over, do a retrospective at the end of your sprint : what went nicely, and what went poorly. Honesty without blaming will allow your team to go forward and get better over time. -> If you fail, you fail as a team, no "Dammit X, if you went faster we would have been in times !" should be allowed.
Don't fool yourself either, all of this take times - or should I say experiences, and only practice will buy you experiences.
Thanks! this surely does help a lot.
What you said is so true. All of this will indeed take experience and practice, more importantly getting in the right headspace. But help from the community and learning from others' wisdom always makes the path easier :)
What happen if I did X then Y ? Do I end up having Z, or something else ?
This is a very nice point. Right now we are experimenting with questions like this, and trying to come up with a bunch of those which we can ask during planning phase.
Sprint retrospectives are one thing that I'm thinking of taking up first.
Slowly but surely, we're getting there.
Hopefully I'll write a second part to this post, and talk a bit more about what parts we've incorporated into our day-to-day workflow, and probably even list out a set of basic questions so others can also benefit from it.
Hi !
I think you got the idea, now you got to play around with it to become more familiar and drag your team with you on this road.
The context on who you're working with doesn't really matter, what need to be understood (but I think you already did) and now accepted is that writing the code is the "easy" part, the hard part of our job is to understand what the client actually want.
Once you have a good grasp around the need, now it's time to do the analysis and planning part (my favorite). Here, we can't really help you, it's all about your experience : you'll fall into dead ends, activate some traps here and there, but hopefully you'll get out of it with a feature. The more and more you'll do it, the more traps you'll avoid. This part is the most important, this is where you'll uncover problems you didn't even think about : What happen if I did X then Y ? Do I end up having Z, or something else ? Does it fit nicely with the already existing code, or do we need a rework in order to keep this maintainable long terms ?
Then, the easiest part : code.
how much time do you guys usually put into planning a new feature ?
It depend on the feature, for complex one I would go for a solid 40% planning, (this includes the comprehension of the feature/problem, planning the workflow and put some times into writing down tests workflows), and 60% coding.
The more you plan, the less obstacles you'll meet during your coding process, as you already eliminated them through the planning process.
Now considering your team workflow :
The planning should be done by the dev(s) responsible for the task, then shared for advices when needed. Do not block your entire team into a meeting where they'll have to agree on a design or an architecture they won't work on (for now at least). This is usually a job on his own.
To avoid falling into the same traps over and over, do a retrospective at the end of your sprint : what went nicely, and what went poorly. Honesty without blaming will allow your team to go forward and get better over time. -> If you fail, you fail as a team, no "Dammit X, if you went faster we would have been in times !" should be allowed.
Don't fool yourself either, all of this take times - or should I say experiences, and only practice will buy you experiences.
Hope it help, even a bit ❤️
Thanks! this surely does help a lot.
What you said is so true. All of this will indeed take experience and practice, more importantly getting in the right headspace. But help from the community and learning from others' wisdom always makes the path easier :)
This is a very nice point. Right now we are experimenting with questions like this, and trying to come up with a bunch of those which we can ask during planning phase.
Sprint retrospectives are one thing that I'm thinking of taking up first.
Slowly but surely, we're getting there.
Hopefully I'll write a second part to this post, and talk a bit more about what parts we've incorporated into our day-to-day workflow, and probably even list out a set of basic questions so others can also benefit from it.
Can't wait to hear from you and see what you have done