The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I started my programming life long ago by programming computerized commercial environmental systems. That is where I "cut my teeth" on the "Soup to Nuts" concept. I had to quickly learn and be successful with the manufacturing, construction, sales, marketing, training, and personnel management (from electricians and pipefitters to programmers). I drew on the principles I learned then to apply to other projects over the years in more traditional software projects.
You make a good point when there are lots of small projects or a large project. In those cases, I found having a BA to handle the "scribe" duties, and delegating some or most of the project management duties to other senior-level and mid-level software engineers (as their gifts and talents apply) allows the overall approach to work. They key to success, in my experience, is that BAs and PMs do not have authority to manage the project. Their skills are there to assist and report to the team leader.
At some point, when the software development team is large enough to create multiple teams, the software engineer that manages all the teams can focus on looking at new features and technologies, and prototyping so he or she can choose what best fits the goals of the organization, and help teach and mentor the various team leads and team members.
The principles do scale, as long as the person leading has the skills to adapt them to what is needed, rather than follow a recipe.
Since "software-engineering" isn't, it takes skill to develop good software. Most of the time, that skill isn't there, regardless of how you structure things. If someone doesn't "own" it, it never gets done right.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
Actually, it is. "Engineering" as a noun means: "the branch of science and technology concerned with the design, building, and use of engines, machines, and structures." I have done software engineering for real engines, machines, and structures, and the definition equally applies to virtual equivalents.
Coders may not take an engineering approach, but I (and many others) do. That includes using value engineering.
There is a case to be made for specialist PMs and Scrum Masters, and an equally valid case to be made for keeping the whole project within the software team. It depends on the scale of the project and the familiarity of the knowledge domain to the developers. Different solutions will be optimal for projects of different sizes and complexity.
Your statement is 100% correct if what I wrote is applied as a plan for “one size fits all”.
However, the article discusses principles, not a plan, that is scalable from a single small team up through a large, multi-team software shop.
I mentioned in an earlier response that BAs could be used as scribes for larger projects. But the key is that when BAs and PMs can be justified, they report to a team lead or software development manager who is a practicing software engineer with the multidisciplinary knowledge, skills, and abilities mentioned in the article.
Non-software engineers should not be in the driver’s seat for software projects if one wants success and excellence.
There is a case to be made for specialist PMs and Scrum Masters, and an equally valid case to be made for keeping the whole project within the software team
I agree - that is exactly the assessment that a seasoned, multidisciplinary team lead or software manager needs to make in cooperation with the manager(s) of the PM(s), BA(s), and Scrum Master(s). Defining specific roles and duties of the ad hoc members of the team, when their presence is justified, takes the engineering and other multidisciplinary abilities of the team lead in conjunction with the PM(s), BA(s), and Scrum Master(s) - and the buy-in and cooperation of the development team (Developers and QA).
That is great that it works for you. Maybe you and your team don’t have the multidisciplinary knowledge, skills, and abilities (KSAs) to pull off a “Soup to Nuts” process. Many organizations don’t hire team leads with those KSAs.
As to your claim about velocity and 6 devs with interdisciplinary skills (which was not what the article described), how do you know? What can you compare your team’s productivity to?
I wrote the article from experience doing both and analyzing how both processes work. I found the productivity and quality of work to be higher with the kind of team I described.
Just a comment, in South Africa a lot of the development is done in the manner as described in the article, only the large dev houses etc have the resources to utilize so many additional members to a development team who do not produce code. Most SME's have small dev or customization teams that cover many roles amongst its members. I'd say its one of the attractions for international companies in attracting the local talent here as the depth of experience is a lot broader than a strictly segmented dev path.
Indeed, they are dropping a line to wish them Wels.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle