201–210 of 387 posts
Earlier quoted context omitted.
In a non-broken organization technical leads (or equivalent) have same level of authority to guide development as feature driven personnel and the necessity of features vs. quality can be triaged in bright daylight. If the organization is not sane, that's another thing of course (and often the case, sadly).
True, but don't forget that non-broken organizations are very rare :-)
I agree with a lot of what the author is saying. They're describing a process that appears to be relatively broken, and identifying some good reasons why they're broken.
What's missing is flexibility. As per e.g. the Agile Manifesto (http://www.agilemanifesto.org), the entire point of frameworks like Scrum is to provide a loose set of processes that you adjust and tweak to your specific team. If you're blindly following the process, and slavishly adhering to things like how precisely your daily standup MUST work, you're following the letter but not the spirit. You're being "Agile" with a capital A, but your team isn't actually being "agile" (the adjective), which is actually the important bit.
The correct response to "our team is unhealthily obsessed with story points, and yet doesn't get value out of them" (or standups, or retros, or whatever) isn't to say "story points are broken". It's to say "this bit of process isn't helping us right now. What can we do to modify the process to provide more value to our team?"
Earlier quoted context omitted.
A few defining characteristics of scrum that lead to overly optimistic predictions: * The prediction is made in a meeting while your head is "out of the code". * The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink. * The prediction is made up to 2/4 weeks in advance of actually doing the work. * The prediction is made without risk of overshoot attache…
It sounds as though you objecting to being required to give any estimate at all.
In such an environment, developers prefer to drastically over test their code, and to undertake work in manageable sprints that let management claim success and understanding even when neither exist.
If you already have a very strong product market fit, and you need to hire developers whose judgement you don't trust, or if there are extrinsic sources of timeline pressure (like investors or non-technical management who think developers are lazy... essentially anyone other than users or customers), then Scrum is perfect for your organization.
The other constituency that seems to love Scrum is product managers who either have no vision for the product or no control of the vision, and are essentially being asked to be cat herders and manage engineers without earning their respect or having any authority over them.
Earlier quoted context omitted.
I've been in situations like this, and when I've brought up techdebt issues, I get "YAGNI". I've tried to frame technical debt issues in terms of how it will impact future feature requests, performance, etc, and YAGNI is what normally comes back. Until... they actually NI. Then it's a hair on fire crisis. Fortunately have not been in that type of situation for years, but I know they still happen.
For those that didn't know - "You aren't gonna need it" (acronym: YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.
"YAGNI" is... in general... not that useful when used by people who've never worked on a particular type of project, because, almost by definition, they don't what what they will and won't need.
And... defining "needs" is its own set of headache. Needed by who? I'll tell you what, we need to ensure we have a logging system in place that can alert folks, and we'll need the ability to view logs in production, and share access to those. Years ago I got "YAGNI" back on that, and months later... weird bugs that no one could reproduce, and the minimal logging in place was only accessible by one guy who was out of town for a week. But hey... we got those "rounded corners" to work in IE5 and IE6 with only an extra week of work - yay...
YAGNI is a good principle, but as with most ideas, you get problems when you introduce various types of people in to the mix. Someone who's never done a project type X should not be the one making YAGNI decisions when other people on the team have done multiple "project type X" before, and are trying to introduce basic requirements.
It's a dev methodology not a religion :/
do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice. if a software engineer is more than a couple years out of college, i don't think she/he should put up with it either.
Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resem…
> Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then res…
My impression is that he means something like identifying a part of the codebase that anytime a story requires working in it, it sucks. I remember we had some old UI object written in some arcane javascript and everyone felt like dying when they had to work in it. But in my experience, the pointing process naturally included that as a consideration. I believe my brain already processes that algebra of complexity in it's native operations when I estimate a point value. I'm not sure that attempting to materialize this "algebra" into some system of equations would be very helpful.
Earlier quoted context omitted.
One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?
I believe the technical debt could be measured as: The time it takes to change code that is already written. For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt. So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as…