|
Greg Utas wrote: If someone is great at software, why saddle them with product management, project management, or other things suggested in this article?
Because it's a small team.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Sure, but I saw nothing in the article about team size. It seemed to be a general prescription.
|
|
|
|
|
Greg Utas wrote: I saw nothing in the article about team size. I
I didn't read the article and was not limiting my comments to whatever it said. Just a general observation.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Not a general prescription. General principles that can be applied to teams of various sizes. If teams grow large, then other considerations have to be applied. Should a team of twenty be broken into four teams of five? If so, how is leadership delegated effectively? Those are topics for another day.
I have successfully applied the principles I wrote about to teams from three to twelve. I think that covers the size of most functional teams.
|
|
|
|
|
ZurdoDev wrote: and they should be paid less
Rubbish - you want to take 30% of the time of a highly productive developer and devote it to other duties, bloody silly idea. I don't know about others but as a senior developer I was paid dramatically more than a PM or BA.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: I was paid dramatically more than a PM or BA.
Precisely. So imagine being a good developer and doing project management stuff.
Or, just a developer only. Clearly you should get paid more the more that you do.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
You seem to assume that a developer can have the same quality of skill as a PM/BA, that is highly unlikely if he is highly skilled in one. You have heard of the saying "jack of all trades is a master of none". Seems appropriate.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Your experiences and mine are different. Nothing wrong with that.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
There has been some discussion around this, and it is clear that different people have seen different things work well. There is no single solution. It is up to whoever assembles a team to know (or observe) the strengths and weaknesses of its members. In some cases, combining roles works well. In others, letting people specialize is preferable.
All team members should be compensated for their contribution. No role--product management, project management, senior developer--is inherently more valuable than another. My own experience has been that some outfits value managers more than developers, so they end up with developers going into management when it would have been better, for everyone concerned, if they had remained pure developers.
|
|
|
|
|
Excellent points. A good leader knows how to take solid principles and adapt them to what makes the team work best.
On your point about developers going into management, I have seen that happen, also. That is why I don’t take a leadership or management position unless it also involves coding. I find that being a programmer is essential to really understanding how to lead a team of developers to be greater than the sum of their parts.
Thanks for your post.
|
|
|
|
|
Typical "modern" Boeing style.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Would you be willing to expand on that, for those of us who never worked for Boeing? I am a bot familiar with Lockheed's SkunkWorks, though.
|
|
|
|
|
|
Thanks for adding those links.
No, what I wrote has nothing in common with Boeing or its outsourcing. I do not believe that outsourcing, especially to cheap foreign labor overseas or domestically via H1-B, is a good idea. In almost all cases, the work product is flawed and requires substantial fixing by in-house staff, and put intellectual property (IP) in jeopardy.
|
|
|
|
|
This is where my lack of other development processes (building construction, sales, marketing .ect) gets muddy.
The "traditional" way does work, followed by a sentence of the requirements that fits in.
The improved solution, does work, for certain situations.
Keep in mind, there are people that have worked 20+ years in solely one or the other ways, and might not easily see another way of doing it.
The improved solution looks to tackle some of these BUSINESS issues.
- time, cost, innovation
If you have lots of small projects and some longer projects, a BA can be a big help to shift low cost work out of the time of a programmer.
Also having a programmer at the early stage can help cut through a day or 2 of delay getting a 3 day project finished because they can answer the quick questions, at the expense of them working on some other work
In short, if you have a single long focused project, some middle people might not be needed.
If you are doing lots of short projects, middle people might help.
(a lot of "might" words - people are people and not all people are created the same, but are equal so I don't know how this maths is supposed to work?)
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
