

SCRUM is not our saviour - GarethX
http://www.higginsninja.net/Blog/scrum-is-not-our-saviour/

======
brettlangdon
Interesting post, there is however one main point about the agile process
missing from the post, and maybe this just goes to show how many organizations
are doing it wrong, but retrospectives are a large part that makes not just
agile work but helps make sure a team as a whole can work together.

It is great if you can adopt ideal agile/scrum practices, but as the article
alludes that doesn't always work for people. Retrospectives are a way for the
team to reflect on their current process, on what works and what doesn't and
to continually make the changes they need in order to be productive and
successful.

Also, another side note. I have worked for organizations that both allow
padding space in velocity for technical debt and those that constrict it. It
works much better when the organization (I am thinking mostly managers,
product, non-dev) know and agree up front to a set amount of time each sprint
being spent on technical debt.

~~~
HigginsNinja
Absolutely, if you have buy in from management to attack the technical aspects
it's a much better environment overall.

I mean to speak more to the situations where you have non technical
management, or at least those that don't understand the repercussions of bad
technical decisions.

In those situations, you need to take it on yourself to make sure you're
handling the technical balancing act yourself.

~~~
brettlangdon
Yeah, I agree. As developers most of us want to develop the best that we can
all the time, either new features or cleaning up technical debt, but the
pressure from the business to always push to get things done as quickly as
possible is very stressful to deal with.

------
HigginsNinja
This article is more of a narrative on when you have non technical management
who is flexible, but just doesn't know or care about the technical aspects of
your job. They just want it to work.

