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.
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.
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?
I think you're reading too much into this article. To me, what this article says is the following premises:
* Don't plan 3 weeks of work in a 2 week timeframe. Curves that look like the second chart mean that you put too much work into the cycle. And the stuff that's done at the end is usually not the quality level that the stuff at the beginning because you're under pressure to get it done by the deadline.
* Leave time for a burn-in at the end of your cycle. This means not doing anything new, and focusing on quality even more. This means dotting the eyes and crossing the t's, and fixing defects for the work done in the cycle that wouldn't normally be done because you're working on the next feature instead.
I mean, an S-curve shaped cycle means sort of supports what you're saying about thinking about work a the beginning. The expectation is at the beginning, no issues are getting completed, because they are the "bigger" ones that are still in process.
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.
