Hacker News Reader

It sounds like you dont really know what the purpose of scrum is.

Unfortunately, every response to "we tried process/technique X and it failed" in this space is ultimately "you didn't understand it" or "you did it wrong".

So no true scrum would have...

No true Agile shop would have...

And where does that get us? It appears that the success rate of people understanding and implementing these things is very close to 0%. Maybe the problem is with the processes/techniques after all.

You only hear about the people struggling with agile because the people not struggling are busy working on stuff.

It appears that the success rate of people understanding and implementing these things is very close to 0%

I don't think this is the case. You're likely only hearing about the failures.

Here's a counterpoint – we implemented Scrum. It didn't cause any real issues, increased the speed with which we delivered features to customers, and increased the visibility of everything that was happening both within the development team and within the wider business.

Part of that was having a dedicated individual responsible for managing and implementing that process who made sure that it was actually achieving things we wanted to, rather than being a tick-box exercise, and who isn't afraid to make modifications such that the process better reflects the needs of the team.

In fact, I'd argue that the problem is completely the opposite to what you imply – it's not that people don't implement 'true' agile or 'true' scrum, but that they try to do so, rather than using these systems as a basis for building a development process that works for their team. No true agile team is slavishly adherent to rules that don't work.

well allow me to put a note here as someone who uses it successfully regularly.

Also I explain several times why he doesn't seem to understand it - having non-technical people running his scrums, working overtime and screwing up their velocity measurements, not being able to cope with changing requirements. These are things that scrum was built to _directly address_.

I say again, if you're criticising scrum as being too onerous, you are probably either using it wrong or using it where you shouldnt (where you dont need to track your progress.)

At the same time, many stories have been of people who have done it horribly wrong, to the point where you really cannot say anything but, "You did it wrong."

edit: I just noticed they said 'sprint commitment', and that they should adhere to it even if it runs overtime.

This is probably the most wrong part of the article - you get done what you can, and let it affect your velocity. It is this velocity that is the central indicator of how much you can realistically achieve

I read "adhere to the sprint commitment" as being an undesirable aspect of Scrum that the author was complaining about, not something that Scrum is lacking.

It's certainly one of the bad parts of Scrum as commonly interpreted; c.f. http://www.peterkretzman.com/wp-content/uploads/2014/10/Aski....

(That's why newer docs tend to substitute "commitment" with "forecast", to clarify the Manifesto author's intent).

interesting - I recently heard someone call it a forecast and thought 'man why don't they use that term in scrum?'

Nice to know that they actually do (I havent read up on it in some time, probably should)

I agree with you. "Scrum is the new waterfall" is true in this case in that both have been built as total strawmen.

Scrum says nothing about unit tests, nor does it require sticking to the commitment (although it used to)

> I dont think they had a very good explanatory service

The most recent documentation on "Core" scrum is very simple and easy to parse.

Yup, this guy sets up a total strawman which doesn't accurately describe how I've seen Scrum run at two major telecom software companies.

We change mid-sprint (when we need to), we don't have non-programmers running scrums or writing user stories and if you don't complete a story in a sprint then you roll it over to the next one.

If you have deadlines and contractual commitments to meet his suggestion of "use Kanban" strikes me as somewhat absurd. Running a team off of a Kanban board has its place (some of our support / platform teams use it) but I'm pretty sure your business owners want a better answer for when something is going to be delivered than 'when my Kanban board is empty'.

This isn't a straw man. This is exactly how Scrum gets implemented when management is running the process and not the development team.

+1

What it delivered soon? Put it in the top of the Kanban board and set a rule that the stuff in the top of the defined list gets worked first.

Having worked on a team using Scrum, I agree with this: it's pretty much the least process you can have while still fairly accurately predicting when work will get done and when any given feature will show up in the product.

But it can be done well or badly: the team I worked on rigorously adhered to the process, and only cautiously diverged from it after careful consideration. Scrum done badly will rapidly become micromanagement instead.

I feel like every time I complain about scrum and my frustrations with it to people who believe in it, the response is always "well you just don't understand scrum," or, "you're just not doing scrum correctly." If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly.

I have worked with great engineering teams that have hummed along in informal processes that were similar to Kanban (though not defined as such). As soon as we were forced to switch to scrum, out productivity absolutely tanked, and we couldn't get the things we needed done because we were either in planning meetings all the time or we had to spend longer deciding whether to change our priorities mid-sprint as things would come up or lessons were learned, because that meant a lot of time and energy spent communicating up the chain why things did not get finished or the priorities changed.

> If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly.

I'm quite skeptical of "agile coaches" and similar.

But in general, I'd suggest that it's easy to break by either swapping out or eliminating one of the defined roles, having someone unsuitable for those roles doing them (e.g. a manager or program manager serving as "scrum master", which instantly turns scrum into micromanagement), having an excessive number of mid-sprint changes (if changing a sprint's work mid-sprint happens every other sprint, something is very wrong), or not having any acceptance from the broader organization for getting work done at a regular cadence without constant "emergency interrupts".

You should not be spending any significant fraction of your time in planning meetings; those occur once a sprint at most, and the sprint-planning portion should mostly consist of quickly doublechecking priorities and grabbing the top stories by priority. The other significant effort lies in breaking down and "sizing" stories (which is the job of the development team, not the person providing requirements).

I do agree that Kanban can work as well; it just doesn't (in my opinion) have good predictive power for when work will get done. (On the other hand, some of our teams ended up switching to Kanban because Scrum doesn't work at all with a distributed team.)

> It sounds like you dont really know what the purpose of scrum is.

Agreed. People lose sight of this being a "framework" far too often. Make it fit your needs and run with it.

I think we can just summarize the entire thing now and forever as "Management leading developer meetings always leads to tears".