You must log in or register to comment.
mmmm spaghetti code
I’ve had this conversation:
We need to increase our velocity! Has the customer told us yet what they would like us to build?
Unfortunately I can’t have that chat ever. I’m the one (in most of my career, not now) responsible for telling my folks what the customer wants, and not in a sales way.
“Boss, most of the bricks we have are broken in pieces. We can’t build the wall per specifications.”
“We have a deadline, get it done however possible by the end of the day today.”
You can fix it later, but that doesn’t mean you’re going to.
Nothing’s more permanent than a temporary solution.
I’ve seen a “temporary fix” serve as a core element of a service stack for a company with annual revenue in the hundreds of millions for like at least 5 years.
Technical debt goes brrrrrrrrr
You have a problem with agile methodology, you have a problem with me, and I suggest you let that one marinate.
I loved agile as an analyst, we used to use waterfall and you’d hear about incorrect designs months later, or not at all, where in agile you can work out the details with the programmers and get both nearer the business requirements, and better designs
Also I absolutely love the job of scrum master which had no equivalent in waterfall
I love waterfall as an developer, I’m using agile now and we have incomplete, conflicting designs every sprint, or spills which affect our metrics, where in waterfall you can workout all the details and have full vision of product and better design with less reworks.
Not to mock you. My point is that methodology is not import when team consists from responsible professionals
There are some instances in which waterfall is not only entirely appropriate, but also the best possible choice in terms of work organization.
There are some instances in which agile is the best fit. Likewise kanban.
Different domains have different optimal workflows.
