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.
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.
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.
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.).
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.
There is a touch of the No True Scotsman here. Many of the 'seriously flawed assumptions' are being stated by zealots claiming that this is precisely what being Agile truly means, and if Agile is not working for you, you must be doing it wrong. One might argue that Agile merely means 'don't waste time trying to look further ahead than you can', but it almost never means just that in practice.
I think it is reasonable to define a Scotsman as someone who is a citizen of Scotland and Agile as following the rules that are explicitly documented in Agile literature.
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.
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.
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.
Part if team not speaking your language is issue through. Also, dealing with cultural differences is harder, people get frustrated if they are not prepared for that.
> "[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.
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.
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.
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.
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.
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.
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.
19 comments
[ 5.2 ms ] story [ 53.6 ms ] threadI 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.
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.
...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.
[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.
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.
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.