
Your Software May Be Lousy but at Least It Is AGILE - jacksonoz
https://www.linkedin.com/pulse/your-software-may-lousy-least-agile-james-williams-2/?trackingId=6RQGNwaCzzhOnElgx7XSQQ%3D%3D
======
didibus
Project Managers are often the least useful people at my work. They mostly
take valuable time away from you, while their contributions almost never
impact the outcome of the software, appart for negatively, by either having it
take longer because of how often they distracted the devs, or by having it be
of ridiculous quality because of how little they understand characteristics of
software maintenance and long term costs.

I've only seen them be useful when other teams or part of the company are
waiting for things, and lots of cross team coordination is needed to align
work, and make sure things are ready for the next one to start.

A PM working on a project who's only person waiting for it is the client/user
of the software, is almost always a waste of everyone's time and the company's
money.

~~~
ozmbie
The only useful project managers I've ever seen are people who used to be
developers, but also have vision for long term strategy. Those people are rare
but they amplify the teams they work with.

All the other PMs I've worked with spend their time making schedules, release
plans and other "management porn" tasks, which are regularly being updated
because they're not based on reality.

------
doug1001
> "[t]here is absolutely NO long term planning, no long term defined
> deliverables, no schedules in place...."

[this remark does _not_ , as far as i can tell, reflect the OP's assertion
about what "Agile" is, but just the sum of their own empirical observations]
It fits my experience though, without any exceptions that i can think of.

Indeed, Agile consultants likely view these things as selling points (features
rather than bugs) to clients--the less work the client has to do themselves to
"get up and running" as an Agile shop, the more attractive it looks executives
and the more likely they are to buy the Consultant's services.

------
wakamoleguy
This rant has some seriously flawed assumptions. Agile is a generic set of
values for building software. There's nothing that says you should have no
manager, or no code review, tests, and maintenance.

No framework prevents people from using it to make bad decisions. It's a shame
that Agile has picked up that reputation.

If you're in a company with these problems, and you're in a position to deal
with them...please do some research before condemning it all.

~~~
humanrebar
I've experienced what the author describes a few times. Agile is mostly
orthogonal to the problems the author describes. The problem is that people
get used to that mindset and try to apply "agile principles" to all problems,
including ones that are better solved other ways (better architecture, better
management, better business plan, better strategic technical vision,
empowering technical leaders to say "no", etc.).

~~~
doseofreality
Exactly, SCRUM/agile can't fix any of the things you mentioned.

~~~
humanrebar
Right. But nobody told the project managers.

And nobody has a book for them describing the process for making sure those
things happen the right way. "Know the software business" and "hire good
people and empower them" is pretty vague and, frankly, not actionable for
managers who couldn't jump into code or design reviews and contribute
meaningfully.

------
Clubber
This is the first I've heard of no actual development manager (or equivilant).
Back in the olden days, there were instances of the project manager actually
being the manager of the developers though.

I could see the "no manager" aspect work in small, self disciplined teams
where each member has skin in the game (ownership), but not outsourced teams
with no accountability. If that is a trend, it is a Darwinian trend sure to
extinguish itself naturally.

~~~
doseofreality
Just search on "dev manager" and agile. You'll come across lots of articles
from scrum proponents that attempt to severely downplay the need and role of
dev managers and sometimes claim they aren't needed at all in an agile shop.

The one thing they usually don't mention is all the new agile servant leader
positions your company will have to hire instead of dev managers.

~~~
Clubber
I would guess it's because those scrum masters want the job of the dev manager
(and the pay).

Scrum is pretty horrible, but CIOs seem to eat it up.

------
goalieca
Agile frustrates me to no end because it takes the engineering out of software
engineering. If you need a product to be engineered then you need a proper
engineering process in place.

The only thing I’m convinced that agile might be useful for is ui development
and maybe some web consultant shop where requirements just can’t be done that
well.

------
TheCoelacanth
When people write articles like this I feel like I am living in a parallel
universe. Agile development is not without its problems, but the complaints in
this article are basically the exact things where agile improves over what is
often done.

> Marketing and/or Product Management and/or Sales and/or the CEO constantly
> throw new requirements and new feature/functionality or constantly change
> existing architecture or design or functionality at the whim of the
> customer, at the "agile" development team who are expected (they are 'agile
> ' after all) to be able to react on a moment's notice

If you are following SCRUM to the letter, only a team's Product Owner is
allowed to give them things to work on. Any other stakeholder who wants
something done has to convince the Product Owner to include it; they are never
allowed to give something directly to the team. XP doesn't require that new
work always goes through a single person, but it does require that everyone
coming up with requirements comes together in the Exploration, Commitment and
Steering phases to help the developers properly prioritize work from the
different sources.

> There is certainly no proper requirements review, certainly no design or
> functionality review

SCRUM includes an explicit place for this in sprint planning and backlog
refinement. XP includes an explicit place for this in the "planning game".

> certainly no code review or proper software test engineering.

If this is true, you should fire your developers. Following SCRUM, work on
something is not done until it meets the team's Definition of Done which is
created by the team itself. The people on the team have the authority to
require that proper code review and testing is done before work on an item is
complete and the team can move on to new work. If they are not doing so, they
have no one but themselves to blame. XP places an even higher emphasis on code
review and testing and explicitly requires it.

> This also makes recruitment very easy for companies - no need to have
> experienced software development managers who can judge and find good
> people.

Really, it's almost the exact opposite. The lack of day-to-day management of
the developers doing the work makes finding and hiring good people an even
bigger and more important part of the software development managers' jobs.

> The other popular alternative is to just outsource to a bunch of 'agile
> developers' you have absolutely no control over in some third world country
> where the developers can't even speak or write English - which of course
> isn’t their fault because they were never taught or expected to speak or
> write proper English anyway.

Essentially the exact opposite of Agile. The Agile manifesto explicitly says
"Business people and developers must work together daily throughout the
project" and "The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation". Both of those
are in direct opposition to using off-shore outsourced developers.

~~~
doseofreality
In Agile, as implemented at most non-consulting shop places, the Product Owner
really doesn't have the authority to block things coming into the sprint being
pushed from executive staff, important customers, or sales. The PO just acts
as a point of contact/funnel to push the stuff coming in from these places
into the sprint.

~~~
TheCoelacanth
You can't really blame the process if you aren't following it.

If your assertion is just that most companies suck at developing software,
then I agree with that. However, it isn't because they are following Agile. In
most cases, things would be somewhat improved if they followed Agile more
closely.

------
cjcenizal
_The other popular alternative is to just outsource to a bunch of 'agile
developers' you have absolutely no control over in some third world country
where the developers can't even speak or write English_

...and that's when I stopped reading. Software is used around the world.
Software is _written_ around the world. The author only limits himself by
adopting this kind of bigoted perspective.

~~~
SAI_Peregrinus
Read the next sentence. It's not bigoted. He's simply pointing out that if you
have a team working in English and replace part of it (or add on to it) with a
team that can't work in English you'll get crap results. Likewise if you have
a product written in English (comments and naming conventions) with English
documentation and hand it off to a non-English-speaking team you'll get crap
results. This can of course be reversed: if your company is in India writing
all its documentation in Hindi it would be silly to hire a Chinese or American
team who can't work consistently in Hindi. Etc.

You wouldn't hire a bunch of web developers to write an embedded system in C &
assembly. If someone did you'd say that it was idiotic. There's nothing wrong
with the web developers, they're great at Javascript, they just don't have the
skills needed to do the job.

