“The moment that story estimating becomes time estimating…stop.”
I know this is how it is supposed to be done but estimating time is so much easier 
Both. The goal is for all those frustrated developers out there to read it, hopefully connect to issues they see in their own organizations and then share with the business people.
I’ve already gotten feedback from a couple of experienced PMs who received it well, so that’s promising.
2 Likes
One of the comments from HN pointed me to a Joel on Software article from 2007 when he pushes for hourly but also pushes for only the developer doing the work to estimate it.
I think that’s a reasonable take. The problem that I describe is time variability by person so it definitely aligns.
This is pretty much how we do it +/-
Found some interesting links. This puts the finger on the sore spot I am seeing again at the moment in an agile / scrum project.
https://www.batimes.com/keith-ellis/it-ain-t-easy-being-agile.html
More from the same writer: https://www.batimes.com/blog/keith-ellis.html
Very well said. I’ve found that people who complain about Agile usually complain about what a company called Agile. Unfortunately that what never was Agile. And no, doing a daily standup, a sprint planning and a retrospective on a periodic basis is not Agile.
1 Like
The best UML tool I ever used was TogetherJ from TogetherSoft. Architect, design, develop, deploy and debug all from the one tool. Drag’n’drop your classes and relations and it is immediately reflected in code.
There is a conspiracy belief that UML was developed to sell tools.
In general software engineering is about risk management. It doesn’t matter what name you call your process, waterfall/Agile, each behaviour should address a particular risk. OPEN toolbox of techniques by Brian Henderson-Sellers et al is a good overview of techniques for different stages of software development and the risk each manages.
1 Like
A business analyst and a programmer (maybe that’s me 
) discuss a user story in jira.
P: How is your story supposed to fit in the current business rules?
BA: What rules?
P: < demos the application>
BA: I’m surprised how that works […].
P: Are these rules not documented?
BA: In what time do you live? Can you reverse-engineer that code for me?
Many more studies can be found pointing at the same sore spot. F.e. this paper https://www.ru.nl/publish/pages/769526/master_thesis_jasper_van_duijnhoven.pdf
I’ve found this tweet by our old friend DHH:
https://twitter.com/dhh/status/574675385163501568?lang=en
And here’s even more, from basecamp
1 Like
I’ve grown to dislike Rails over the years but I can’t deny DHH is a really no-BS and smart guy. His articles are always a great read.
1 Like
2 Likes
My experience of it was that it’s used as a way to avoid thinking deeply about problems, and as a way to put pressure on devs as they can only see the short term. It also lets a minority of “devs who would rather talk than code” do just that, by becoming the local agile gurus.
4 Likes
Saw this on reddit today. It’s perfect 
1 Like
Wow, I would have written the same. To me, whenever someone says “We work in an agile way”, I know they have no idea what they want to get done. Often times, it is the management that blocks everything because they either don’t decide on things or change their mind every second day.
I can’t count how often I asked for the exact requirements in the last couple of years and nobody was able to answer.
2 Likes
Looks like a great way to bury:
Individuals and interactions over processes and tools.
It’s a plan, not a bloody prison.
1 Like
