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.
Seriously? The entire march of history is about economic specialization. If someone is great at software, why saddle them with product management, project management, or other things suggested in this article? Those roles should be filled by people who are also good at those roles, but they don't make someone a software team lead from a technical standpoint.
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.
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 -
I'm old. I know stuff - JSOP
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 -
I'm old. I know stuff - JSOP
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.
There were a lot more articles (in a half-year period); the gist is that they were outsourcing software-development to a cheaper country, that NASA wanted to re-evalaute the software they got from Boeing, and the news that a test-traject of 27 months had been reduced to 11 months.
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.
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?)
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).