[kwlug-disc] Automation, tools and agile

[Mikalai Birukou]

On 2020-01-14 9:21 p.m., Chris Frey wrote:
> On Tue, Jan 07, 2020 at 11:08:46AM -0500, Mikalai Birukou via kwlug-disc wrote:
>> Modulo upfront granular hourly estimation forced by managers.
> If you're estimating in hours, you're not doing Scrum, as I understand it.
>
> 	https://www.youtube.com/watch?v=7nTxdl29ePY
>
> - Chris

I have just watched completely the video you sent about story points. As 
early as 1:00 we see a clock where hours are substituted by points. It's 
not fooling me. (Allen's video 8:55)

Well, there are a few things trying to jump from my fingers. Let's go 
step by step.


a) Somehow it totally feels that you haven't looked completely through 
the video, mentioned in the first post: 
https://www.youtube.com/watch?v=QVBlnCTu9Ms

In this video Allen talks about comparison of counting tech tickets 
versus doing story points with and without fibonacci, saying that 
evidence, yes, evidence doesn't support a claim that story points are 
any better than just counting tickets. More so, Allen talks about 
progress in time and how prognosis (estimate) becomes more accurate 
(Allen 29:45).

So, Chris, I watched video you've sent. You should watch Allen's video. 
Do it before reading following points we are going to touch.


b) Now, after watching Allen's video, let's start story points video. 
Immediately jumps into the face a background hubris of indicating 
different work with carpenter tasks, i.e. physical, known for centuries 
work, while what software developer will be doing, she has never done 
before (Allen around 0:40).

I recently had an additional "story" that was a small improvement on an 
already completed "story". Guess what? At a certain level of abstraction 
they are similar. But we still needed to drastically change the whole 
underlying foundation.

Let's put my experience into carpenter task analogy (points video, 
2:23). We are at wiring position. We need to add another plug. Looks 
similar to the rest of the completed wiring. But in reality we had to 
change layout of foundation under carpets.

Relative comparison (points video 0:35) also fails! Software development 
is not like carpentry!

Unfortunately, these nice graphics (man with a tool belt) are suggesting 
on a subliminal level that all tasks are completely known before work on 
task starts. And this is fed into manager's psyche. And when he hears 
(carpenter analogy) that addition of a plug needs a change in 
foundation, while it has been estimated that it is a task like the one 
that has already been successfully completed, he usually turns on ... 
cause (Allen 3:16) any dev's guess is taken as a contract.


c) In story points video agile stories are shown. Ok. Now at 6:30, by 
virtue of putting story points onto the same card we see that customer 
story are conflated with functional requirement/tickets.

UX story is not equal to tickets with tasks to build elements that are 
needed to be done to deliver story's UX.

And we should look at progress with functional tickets to see how things 
are moving.


d) The question that we should ask is why simple counting of tickets works.

When you give a developer tool to split tasks into sub-tasks, people 
naturally do this splitting down to something that becomes 
small/graspable for that person. Every person may have a different level 
of granularity in sub-tasking, and this influences slopes of lines in 
tickets counting. But personal preferences stay same allowing to have 
simple straight lines. Bingo.


e) Let's grant a proposition that every dev task is totally simple and 
countable, like it is in carpentry.

Then I have an uncomfortable news. Simple, similar, repetitive tasks 
must be automated instead of making people perform these tasks. In other 
words, manager in this situation has failed to find an obvious 10x 
productivity increase by automating and moving to high levels, where, of 
course, tasks are not repetitive like in carpentry. Owners must fire 
such lazy management!

Interesting perspective, right? :)