That’s why lots of agile/scrum projects burst and die. Probably the main reason why most startups fail. This might be an exaggeration, but we tend to forget about careful planning and design which make our code written so quickly every sprint with no specific plans (or even standards) made for the years ahead (because the business said so, because the deadline said so). Combined with the fast-paced always changing/always updating/always new/always obsoleting technologies (like js), it almost looks like a snowball effect for the devs. We can’t avoid it.
I always look at the oldies (engineers who work on old businesses like banking, stock-trading, transportation, etc), they always work with careful planning and specific kind of professionalism and contract negotiation, something we don’t see in startups world. They might not get hyped with the new shiny-wow-js-library out there. They probably don’t care about TDD or pair programming. But they know, they damn-sure-know what they are going to code for the next year.
Meanwhile, most of startups engineerings (tech department, or engineering department) are perfect reflection of their business counterpart, quick iteration and quick market validation.
Developers in new business market are getting better at writing codes, lots of coding bootcamps are founded, but there are 2 important things in software engineering missing: planning and designing, which probably has small interest in developers mind nowaday. Developers no longer know how to plan, document and design their system. We are no longer involved. And we are no longer allowed to.
This is the origin of the death of software design tools (why do we need one, when we have no careful planning at the first place?), and the rising of scrum/kanban whatever. Our plans, designs and documentations are there, right on the board. Read them. And guess what, near the end of the sprint? Let’s change it, so we have to adapt with it, refactor everything we have written, even worse, the ticket we are working on suddenly got discarded. And btw, we have to do this in only 2-3 weeks. Just a board with texts (given bla bla bla, i want to bla bla bla and then bla bla bla) and whatever. No clear communication, no clear agreement, on how to translate this business requirements into technical aspects. (Doesn’t this lead to misinformation and wrong delivery of the products to customers? what is wrong, what is right? our documentation are only some paragraphs of subjective texts that we, the devs must subjectively translate into technical aspects.)
x: “Well, this feature is big, don’t we need to carefully draw this requirements into some kind of charts we agree on, so we can know better in overview and in detail? something like a database diagram or a use case diagram, we might draw some simple flowcharts to validate this design in accordance to the current one, so we can catch early design issue and adapt it with the current system on production.”
y: “do you have time for this?”
x: “no, but we can surely extend the schedule”
y: “we don’t have time”
x: “at least some UI mockups”
y: “just code and ship it, make sure it is green, this ticket is only 11 complexity points, you got 3 weeks”
x: “do you have any future plan that might correlate with this feature? at least something that we can anticipate in this feature?”
y: “we don’t know yet”
Like it or not, this is something that we have to deal with every day, until the end of our career.
