|
Thanks for the response. Lots of good points.
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
|
|
|
|
|
Quote: Since "software-engineering" isn't
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.
Quote: Definition of software engineering
: a branch of computer science that deals with the design, implementation, and maintenance of complex computer programs
[^]
|
|
|
|
|
Unless you can also "think" and "know" your problem domain, what you call "engineering" in software, is just repeating someone else's mistakes; and mostly copy and paste.
(The ever popular "Hospital Management System" keeps coming to mind. Codez plz.)
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
|
|
|
|
|
If one cannot "think" and "know" - and I add, "knowing why", that person will remain just a coder.
|
|
|
|
|
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.
|
|
|
|
|
Quote: 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).
|
|
|
|
|
I don't like it. My team has 1 dev, 1 BA, 1 PO and 1 QA, and our velocity greatly exceeds that of a team with 6 devs doing multidisciplinary work.
I rely on my team every day. ♥️
|
|
|
|
|
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.
|
|
|
|
|
Thanks for the international perspective.
|
|
|
|
|
Me: I'm not mad. I'm over the trauma. We're doing just fine.
Also me: Ends up injuring 10 people at squash court. 
"BRB crying" 
|
|
|
|
|
You could try to play squash, replacing the ball with a badminton shuttle; you will spend as much energy but it will be far less dangerous.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
What would it be called then...squashminton? 
|
|
|
|
|
I would think that after the first two, anyone else who got in the squash court with you was masochistic as best, suicidal at worst and they brought it upon themselves.
Be happy to provide the service they need.
|
|
|
|
|
There's league going on. They don't have any other choice. 
|
|
|
|
|
I knew an a***hole like that, after picking up a few bruises from him I left it to the competition players, they seemed to enjoy the pain.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
You are not mad, you are just lost and incoherent.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
MehreenTahir wrote: Ends up injuring 10 people at squash court.
You're supposed to hit the ball with that racket.
|
|
|
|
|
Whose balls are you talking about?
|
|
|
|
|
I think I now understand the problem...
|
|
|
|
|
Message Removed
modified 27-Feb-20 10:35am.
|
|
|
|
|
Message Removed
modified 27-Feb-20 10:35am.
|
|
|
|
|
Message Removed
modified 27-Feb-20 10:35am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
