Your Software May Be Lousy but at Least It Is AGILE
linkedin.com
linkedin.com
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.
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.
[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.
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.
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.
Many of the complaints in this article indicate that they are acting in direct opposition to what is published in Agile literature.
> 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.
XP explicitly requires code review and testing. SCRUM doesn't require it, but it does empower developers to make that requirement. 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.
> 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.
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.
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.
Scrum is pretty horrible, but CIOs seem to eat it up.
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.
> 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.
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.
...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.
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.