
It’s not the methods that are Agile, it’s the people - kasiakrn
http://10clouds.com/blog/whats-agile-development/
======
GrumpyYoungMan
I'm a big advocate of Agile but at the same time I'm leery of joining teams
that say they do Agile. Why? Because they usually mean, "We do standups and
burndown charts and that's it." It's cargo-cult Agile, at best, and
micromanagement by story point, at worst.

Football teams don't do standups saying "I will run X yards". Each and every
player on the team

-knows precisely what the objective is

-knows precisely what his/her role is and is capable of fulfilling it

-knows what s/he needs to communicate to other teammates for them to fulfill their roles and does so promptly

-is capable of assessing what needs to be done next given the current situation on the field without having to be told and takes on that task on their own initiative

-doesn't have anyone breathing down their neck saying "A point must be scored by X:XX on the clock or else!" regardless of whether the tactical situation makes it possible

Together, such a team functions like a well-oiled machine. _That_ is what
Agile is trying to teach. But more often than not, few, if any of the
personnel or business conditions are met to make it possible and so it's a
painful, miserable charade for all involved.

I have seen Agile work exactly once in my career; it's absolutely beautiful
when it does.

~~~
Cacti
If teams can't consistently implement "Agile", then maybe it's not really that
great of a method. Or perhaps it's not much of a method at all, just a bunch
of pseudo-philosophical nonsense, measuring things that aren't relevant and
using methods whose correlation with actual results is near random.

I mean, look. We _know_ there is no single project management method that
produces good results across the board. That is a fundamental result of
undecidability (and related no free lunch theorems). There is no single
method, there never has been, and there never will be. The teams that work
well do so because they are good at what they do, they have a specific
skillset for what they are working on at that time, they work well together
and adapt to the circumstances, and frankly, are a bit lucky. That is a moment
in time. Most, if not all, teams cannot reproduce that result consistently
year after year, nevermind among different teams. It is a fleeting attribute,
not a systemic byproduct of _process_, unless the field is so narrowed so far
that optimization is in fact possible (which is exceedingly rare, and
certainly doesn't manifest itself in general software development).

~~~
Retric
I think people look at Agile from the wrong angle.

Agile is old enough that many people don't know what pre-Agile development was
like. Often teams would pretend everything is fine until months after projects
should have shipped. Pretending things are great while looking for a job or
jumping projects was really common.

Even cargo cult Agile tends to make it clear things are going to fail ahead of
time. Which is huge.

Sure, that does not mean the project is good or profitable, because on it's
own it's a long way from enough. But, nobody cares about process when things
are great, it's when things are failing and you want to get horribly broken to
break even where even cargo cult Agile can help.

~~~
braveo
> Agile is old enough that many people don't know what pre-Agile development
> was like. Often teams would pretend everything is fine until months after
> projects should have shipped. Pretending things are great while looking for
> a job or jumping projects was really common.

That's not true, Agile didn't save the software industry, it's just a
different methodology with different ideas.

The "software crisis " still exists today the same as it did then, the only
thing that's changed is young people who don't have the necessary perspective
to understand that.

------
Yhippa
As another poster said here, I've seen Agile work well one time out of many
organizations. I think the worst is when individual teams don't choose to use
Agile and it instead comes from somewhere high up on the organization: "We are
now Agile".

I've not been a part of but I've heard of horrors like SAFe. I've seen the
diagrams [0] and I can't believe someone was sold on that.

I guess BigCorp needs to use something as a software delivery methodology. If
they don't use Agile what else would they use?

[0] [http://torak.com/wp-
content/uploads/2015/11/SAFe-3.jpg](http://torak.com/wp-
content/uploads/2015/11/SAFe-3.jpg)

~~~
trhway
>I've not been a part of but I've heard of horrors like SAFe. I've seen the
diagrams [0] and I can't believe someone was sold on that.

the diagram is an eye candy for a mid-level executive. Upon seeing it, they
start dripping saliva and become weak in the knees. The diagram has Lean,
Agile and while it is missing the word Scrum it obviously is depicted there
too. I've been through couple of years of the process looking extremely
similar to that diagram (though word "SAFe" wasn't there) implemented across
whole R&D (only super important projects got exception) of a pretty BigCo.
Well, it was beyond horror. The product development was basically stalled
completely. The gears were churning with lightning speed, people were
constantly overworked, rushing to meet multitude of deadlines, .... all that
while product just wasn't moving forward. No meaningful features could be
delivered. It is hard to believe until you see it with your own eyes.

Then, one nice morning, all the mentioning of it just disappeared, like it
never happened, and we're back to happily cranking out according to current
release plans with weekly team meetings.

------
mikegerwitz
> Agile teams find their ways within clear, yet very general rules.

And reiterate on those rules.

We implemented Scrum at the company I work for. It could have just as easily
been any other sort of development methodology---Kanban was under
consideration for less structure, for example. What we were looking for was
something that works for us, and that would get us out of the huge mess that
we were in. Scrum addressed many of the issues (especially management) we were
having, so we figured we'll give it a shot and slowly start implementing it.

We don't stick to the books. The core concepts of Scrum are implemented, but
are guiding. We constantly iterate on the process itself---every sprint we
review how we did, identify problems, and put something in each sprint to
improve upon them. We introduce concepts gently. If we find that something
doesn't work, it gets adjusted or replaced. If it works, we apply it even more
stringently. If making it more stringent introduces problems, relax it.

We do nothing because we "have" to under Scrum. Everything we do is analyzed,
rationalized, and adjusted. And it has been wonderful---it saved a department
that was falling apart. Are there problems? Sure. But we've identified them,
and they're being addressed.

Concepts like TDD and pair programming---those aren't things that can be
forced. The team needs to be on board, and if it's not working, then changes
need to be made to hear and address their concerns, or get them to understand
why we do things the way that we do.

At a higher management level, how projects were managed couldn't be forced. It
was a gradual change, and it took a couple years to completely change how the
entire company approached projects.

------
whoops1122
I think at the most organization, agile translate to tight dead lines.... and
thats about it.

~~~
trhway
as DevOps Borat says - "agile waterfall". Agile causes deadlines to be tighter
because agile causes huge inefficencies, especially when it comes to inter-
team/project/module interactions and dependencies, and pile of additional
unnecessary stuff to be done that takes additional energy/resources/time to
burn to deal with and which gets in the way of the stuff what is really need
to be done.

A snake oil - be it agile or communism - is easy to identify by the fervency
with which its peddlers preach no true Scotsman.

~~~
nradov
Agile doesn't cause more inter-team interactions and dependencies; that's an
orthogonal issue. In general dependencies can be minimized by organizing
around _feature_ teams instead of _component_ teams. But you can do the same
thing with a waterfall process.

~~~
trhway
>Agile doesn't cause more inter-team interactions and dependencies;

It doesn't cause more of them, it makes them fail.

> In general dependencies can be minimized by organizing around feature teams
> instead of component teams.

You can't include common core upstream components into downstream branching
features. Basic topology of a tree. Until of course you just have only one
team doing the whole project.

Even when components with a dependency between them are in the same team the
dependency still exists and agile makes it much more harder to handle. Until i
guess it is one person doing both components - that by transitive closure
would mean one person doing all the project himself (until the project
component graph contains disconnected islands)

~~~
nradov
You're missing the point. The agile manifesto — and the various agile
methodologies in common use today — don't mandate any particular practices
around reuse of common core upstream components.

If you want to divide the teams up by component rather than by feature you can
do that, but it's usually a bad idea. Most projects can achieve higher
velocity and quality by having teams take on vertical slices of functionality
through the full software stack; this minimizes misunderstandings and delays
when handing off work between teams. But either way it's essential to have
stable APIs and clear design contracts before building any dependencies on top
of common core upstream components. Again this is all orthogonal to agile
versus waterfall.

~~~
whoops1122
Also, a real agile development cycle started from OO design, you need to
design the code well enough that each object is relatively isolate from each
other before we can talk about Agile.

nowadays, every organization talk about agile development cycle, but few
business ppl really spend time to understand what it is, and how much it is
involved.

like one of the poster here said, "Agile waterfall"

~~~
nradov
Well that is one approach and it sometimes works. But usually it fails or
least forces excessive rework because much of what you thought you knew at the
beginning of the project later turns out to be incorrect. Another more agile
approach is to avoid big up front design. Treat design as an emergent property
and keep the internal OO design clean through constant refactoring.

[https://en.wikipedia.org/wiki/Big_Design_Up_Front#Arguments_...](https://en.wikipedia.org/wiki/Big_Design_Up_Front#Arguments_against)

------
sickbeard
Agile to me has always been the way for managers to get an almost daily status
of what developers are working on. All the metrics, tools, charts and meetings
have been for the benefit of management not devs.

~~~
skylan_q
This is what it's devolved into: process. Middle management can now provide
metrics to upper management.

------
lacampbell
The more jobs I have the more I think collective code ownership is the
problem. I've never worked at a place where that hasn't resulted in a
sprawling mess. No methodology will save it.

~~~
ZenoArrow
I know this is going against the grain here but, have you ever worked
somewhere that followed the Waterfall methodology?

For all its problems, the one thing I've found it works well for is cutting
down on technical debt. Developers get requirements up front, and
documentation can be planned out alongside development. You do need skilled
business analysts/project managers for it to work well, but it definitely cuts
down on the sprawling mess I've seen in Agile. I'm sure Agile can work well,
but from my limited experience too much emphasis is placed on moving fast,
resulting in considerable technical debt (not a problem if a codebase is small
enough that a team can entertain the idea of a rewrite, but it's disastrous
for large codebases).

~~~
lacampbell
> I know this is going against the grain here but, have you ever worked
> somewhere that followed the Waterfall methodology?

I haven't. I feel like the simple waterfall model is too rigid, but one of the
modified versions would work well.

I am trying to design more of my code upfront these days, and spend less time
coding directionlessly. Trying to become more prolific. Waterfall seems to
encourage that.

------
skylan_q
You don't _do_ agile. You are or aren't agile. Once you stick a process on it
and everyone starts gaming that process you have the opposite of agile.

------
cjung
Funny plot twist at the end, OP calls himself a Project Manager.

~~~
js8
That's actually a good thing. One thing I really hate about, say, Scrum, is
that they renamed everything. That way, decades of experience with project
management was lost to young people, who fail to see the connection. I think
it was entirely intentional, though, because how else could you sell snake-
oil?

~~~
UK-AL
It's not a rename. It's completely different. Similar responsibilities are
split between the Product owner(Planning what features to include, interacting
with users and some roadmapping), scrum master(Normally ex developer, coaching
developers on how to improve the process, TDD, Code review) and the team
itself(Estimates, final say about much goes in a sprint).

I think most people prefer kanban or scrum over traditional PM style
management.

However they have failed deliver on all promises.

When people complain about agile, they aren't harken back to traditional pms

~~~
js8
And the reason for this reorganization of responsibility is what, exactly?
See, that's the problem. If you rename it, people won't compare it. So it gets
easier to sell, because if people compare it, they might get a clue and find
some flaw in it.

I am not against some shuffling of responsibility. But ideally, you should
know why you do it and best if it's backed up by some studies. You can't do a
study if there is no way of comparison.

It's not just people though, it's also stories, sprints, iterations, epics,...
you name it. Also, everything that came before was retroactively (and
derogatorily) renamed "waterfall", despite the fact that many of the
advantages of agile were actively discussed since 1960s.

And, yes, I believe well managed project can be better than agile, at least in
some cases. We have Agile in our organization, ostensibly, but in effect it's
lot more paperwork than it ever was under so-called waterfall. At least that
is my experience, of course some other people can have different one. Maybe
you just didn't get in the contact with the right snake-oil salesmen - good
for you!

------
throwaway27234
I recently applied to a very well-known agile consulting shop and was rejected
because of certain issues with the take-home exercise. For example, in the
exercise I used a priority queue, which I had implemented as a single class
(just the queue, which is to say a heap - nothing else). But these guys
thought it should be broken into several classes, because a single class must
not have more than 150 lines of code and the implementation was slightly more.

After that, I checked implementations that are available online. Every single
one was implemented as a single class, including the ones implemented by
Microsoft, Oracle, etc. And why not? It does not make much sense to break down
this structure further.

But these best practises have taken on a life of their own.

~~~
nradov
That's a strawman argument. No widely-used agile methodology mandates a
maximum class size.

------
zonename
Scrum is the death of Agile

------
firewalkwithme
Methods do not work. Small groups of brilliant and inspired people work

~~~
st3v3r
But those are expensive.

------
davidgerard
Agile makes more sense if you remember it was _literally_ an attempt to port
the then-newly-hyped open source development method (Cathedral and the Bazaar
had just hit) to a corporate context.

So this is entirely correct: it's an attitude, not a tick box procedure.

Also, you can't Taylorise clue.
[http://reddragdiva.dreamwidth.org/594955.html](http://reddragdiva.dreamwidth.org/594955.html)

------
api
This is a special case of a general principle. Engineering and coding are
crafts, not assembly line work. A craft is a field where the individual human
being matters a lot. No "methodology" will make less skilled or experienced
craftspeople perform as well as better ones, though the inverse is true so
good management does matter.

------
quickben
To answer the question: management by stress. Some may disagree.

------
DrNuke
Culture fit, maybe? As an IT contractor / problem solver, I have often met
teams more trying to follow a protocol than actually working for value. From
their perspective, they were just complying with the rules set from their
employer, so all fine (apart of the fundamental reason they had to call an
outisder in, of course). Mileage may vary with country and industry, though.

------
devoply
You also need patience, understanding and forgiveness. Many rationalists don't
understand these three principles are necessary for the other principles.
Without them people are always guarded, because they are vulnerable. And many
business environment fire first and ask questions later. That sort of business
environment is antithetical to agile.

------
maxxxxx
People have to accept that a lot of software development is an art and not an
assembly line with predictable steps. The agile manifesto is great but Scrum
gives management the illusion that software development is a totally
predictable, quantifiable process.

In the end, it's still experience and judgement that counts.

------
debacle
1\. Don't capitalize agile, you just look like a fool.

2\. Everything you need to know about agile software development is on the c2
wiki.

3\. Navel gazing is not Agile.

------
Yokohiii
There is always someone who tries to be smart about agile, but there are yet
good solutions to be seen.

------
peterwwillis
Agile is (in part) based on small iterations of tasks to eventually accomplish
user stories, basically, right?

Can someone explain how this has anything to do with either administration
work or building a physical appliance to sell to a customer who will be using
it offline? Because while both have user stories, both are things that require
you to not use the agile methodology.

When you're doing system/network/database/etc administration, you have a
specific request or task to accomplish. But there is no iteration. There is
no, let's do a little work and see how it evolves. If you're practiced, you
know exactly what to do and how long it takes. So you just do it. Spending
time updating boards and stories and tasks is a complete waste. Yet I've seen
Agile shoved down the throats of teams who used to simply get shit done as
fast as they could, and now go through some mandatory red tape to justify what
they've been doing on short staff and no time for years.

When you have to sell someone a physical product, I just can't see Agile being
very useful, mainly because of the iteration aspect. Yes, you _could_ go
through all the motions and provide full features over time and watch them
grow with agile, but there's very few times I've seen a product designed from
the beginning reach its target goals with any sort of a redesign. In my
experience, what I have seen is the Agile method wasting everyone else's time,
eventually requiring a redesign.

Story time: A meniacal team lead who's trying to make a name for himself in
the company sees a way to save the company tens of millions by spending only
one or two million on a product. But first we need to customize the product to
work for our specific needs, which means writing middleware and customizing
the interfaces to give our teams what they need to use the product. Basically,
turn a kit car into an actual Ferrari with the 12 cylinder engine and
everything. We take six months and actually mostly accomplish it - and then
the maniac decides it's time for an upgrade, while teams are trying to learn
how to drive this thing. The upgrade requires massive changes, but of course
we're Agile, so we iterate and iterate until the Ferrari is now a Lamborghini.
It's now been a year, and we're back where we were six months ago, only with a
different looking car. Only one team managed to drive the Chimera in that
time.

The fallacy of iterating on user stories is that the user knows what they
want, the product lead knows how to get there without it becoming obsolete,
and the developers will magically replace whole systems by iterating over
features that they already know will not be changing before the product is
done.

Personally, I think _anyone_ could come up with _any_ methodology _at all_ and
they would have exactly the same success as with any other methodology. The
only thing that makes it all work are teams who get their shit done and have
the bigger picture in mind, and help each other. But you don't even need a
methodology at that point.

Agile just seems like so many pie charts for managers, and a buzzword to
repeat to gain relevance.

~~~
nradov
There are a variety of agile methodologies. Most product feature development
teams find that Scrum works pretty well. But for sysadmin or devops work
usually Kanban is a better fit.

------
sctb
We've changed the baity title to a representative sentence from the first
paragraph.

