
Agility Follows an S-Curve - ingve
https://sandofsky.com/blog/the-s-curve.html
======
tootie
I'm curious what their QA process is like. We don't mark a story as complete
until it's been tested and bugs are fixed. So it's rare for a new bug to crop
up and if it does, the story is not accepted and the feature doesn't get to
release.

------
jacques_chester
It took me a while to realise that this is meaningful for Scrum shops.

For places practicing something that is lean-flavoured, or Extreme
Programming, it's very odd, because the software is supposed to be releasable
_at all times_.

------
p4wnc6
The second chart -- where it's referred to negatively as a "cliff" \-- is the
only kind of workflow that I think is healthy (at least for the kinds of
problems that I've tended to work on). I rarely work longer hours in that set-
up, and all those early parts of the curve where it looks like things aren't
being completed -- that part is usually where I am the most productive.

I spend the first while reading, researching, drawing pictures, and just
generally _thinking_ about the problem. The idea of even caring at all about
closing a ticket or issue at the early stage doesn't cross my mind. It's too
soon. Zero tickets should be closing. You haven't thought hard enough yet.
This applies equally well in a two-week time frame as in a multi-month pilot
or prototype research phase.

Later on, I am reaping the rewards of the compounded growth of the thinking
and ruminating that I did. I can close issues way faster than normal (without
working longer hours, without exhausting myself, and without introducing
dangerous bugs). This is because I took the time to actually _think_ about
what I was doing. I didn't let the false productivity of merely closing
tickets or issues (i.e. stupid bullshit overhead that I enter into a stupid
bullshit tracking system) get in the way of actually doing my job (which is to
_think_ first and act on that thinking later).

The fact that these graphs tend to converge, naturally, to the "cliff"
scenario should be a big signal to people that that's what humans do. That's
how they work. Humans produce solutions to hard knowledge problems in a way
that is like a Poisson process. After "integrating" on the problem for a
while, a solution "discharges" like a lightning strike, based on the
compounded growth of your investment into actually thinking, instead of
prematurely trying to do something just for appearances sake.

This is relatively more true for "research" problems, where you can have a
chance encounter with something that suddenly makes the problem way harder
than anyone thought, as opposed to what some people seem to think are "mere
implementation" problems, but the effect still happens in both cases. And even
more, "mere implementation" problems usually aren't. Usually those too involve
research time regarding refactoring and design ramifications of the
implementation.

This is among the fundamental reasons why I disagree with the premise of
modern Agile-like techniques. They take a view that fundamentally, all of the
tasks within a given cycle are roughly fungible and commodity work. Management
seems to think that it's somehow a managerial task to "drive" workers into
situations where they produce linear-like burndown. Instead of stopping and
saying, wait, we should be figuring out how people work and then setting up
the stream of business needs so that it gets satisfied by the way people work.
_Not_ saying that you have some preconceived idea of how the business needs
have to be satisfied (usually because it would be politically convenient for
you if it could be true), and then seeking to implement that regardless of
what human beings do when they work.

Anyway, in a sense it depresses me that this kind of burndown bullshit has
been so erroneously legitimized by middle management in bureaucratic
organizations that we now actually have to spend even more brain cycles
debating exactly what shape the burndown graph should have. Total bikeshedding
loss for us all. Why not just not have burndown and stop pretending like
keeping one's finger on the pulse of ticket-closure-velocity has any
relationship to the real world aside from whatever one can politically sell to
one's boss?

~~~
YZF
At what resolution does this look like a cliff though?

Let's say we're building Google Mail. This is a project with a life of perhaps
30 years. Throughout the project we obviously need to think and deliver. We
can't think for 29 years and then start working.

Let's zoom in to some 2 week cycle in this project. If you don't actually know
what you need to get done during those two weeks it's too late to start
thinking about it. You want to be in a situation where you've already
identified some features you need to deliver and you already have a pretty
good idea about how they'll be delivered and how they fit into the
architecture etc.

That "how to/thinking" stage is just background processing that happens all
the time. It shouldn't be counted in the burndown. That background processing
could consume anything between 100% of the time in a project that is just
getting kicked off and 20% of the time in a more mature project.

Every now and then a problem might come along that requires more serious
thought. But to just have the entire team go and think about it for months is
very rarely the right thing to do. You just put it on the back burner. If
there's some urgency then you just think quickly and accept the fact that the
solution is very unlikely to be perfect.

Regardless of process or how management is trying to drive people you need
some mix of stuff that gets done and thinking about what else needs to be done
and where to steer the overall project towards. These really have to happen
somewhat concurrently since you want to get feedback on your ideas as soon as
reasonably possible. Every situation is different in terms of the time scale
and what this mix looks like. Whatever the buzzword of the day bad management
will find a way to abuse it. Agile was supposed to be a way of avoiding that
but the forces it tries to fight are too strong.

EDIT (more thoughts).

If you've thought about architecture and how features work and are implemented
than tracking burn-down can indeed give you some insight about the actual
progress being made. It's just a visual way of seeing how close you are to
where you thought you'd be. There are a lot of things that need to happen
though for this to really work. You need to have done the thinking. You need
to be reasonably good at estimation. You need to be reasonably good at
planning the work out. The team needs to understand what "done" actually
means. The process shouldn't be abused by management (which I think is the
complaint?).

I've seen this work. I've seen "smooth" work reflected as smooth burn down
charts and I've seen "oops, unexpected trouble" show charts where nothing is
burnt. That early visibility is supposed to help steer the project. I've seen
projects with no such visibility go through 2 years and find out very close to
the end that they're really a year late and the project will take 3 years.
It's not that something unexpected happened after a year and 11 months. It's
just that people weren't paying attention and were being optimistic they would
somehow magically catch up.

