The ESSENTIAL Qualities Of GREAT Development Teams

[@ContinuousDelivery]

🎓 Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide

[@sasukesarutobi3862]

It seems like so many problems stem from mischaracterising the ideal software development practice as genius engineers with perfect technical knowledge predictably cranking out perfectly performing features from perfect specifications. In situations like this, people are then afraid to challenge things, or to admit that they don't know. Software development is hugely complex, so the only time you're likely to have no mistakes is in something trivial; you certainly won't get it in an distributed system with a lot of moving parts. Even Google's research in Project Aristotle confirms that psychological safety (the feeling that you can safely take risks and make mistakes) was by far the most important predictor of team performance. The best-performing teams aren't the ones who know everything, but the ones who can say "I don't know" together, and then work together to find out the answer.

[@jcollins519]

Around 13:20 and up through the sailing story you're discussing developers taking responsibility in context of a high degree of [perhaps necessary] hand-holding. As someone who's job it is to review code, I find it a difficult balance, given the complexity of new features, between writing up a page of feedback (we are remote) vs just refactoring the code in the way it's expected. Refactoring and having a discussion around the changes seems to be a far more efficient system than the back and forth of verbal guidance but there's also the psychological concern around taking away "ownership" from the team member(s) working on the feature. The hope is that, being familiar with the problems they're solving in their code, they'll be able to more clearly contrast "their way" vs "the better way", and be able to carry this knowledge on into future projects, while also not feeling as though the product of their labor is being gutted and taken away from them. I will generally take liberties to rename variables, types, and write comments from the perspective of someone unfamiliar, but what I'm mostly referring to is making actual structural and functional changes to the code. My question is: Do you have any advice about how to balance this verbal guidance vs. just taking the wheel at times? And how should team members feel about "owning" their work?

[@ArkhKGB]

Published almost 50 years ago and the Mythical Man Month presents the concept of cross-purpose teams with the surgical team. - The Surgeon, or chief programmer - The Copilot (pair programming already?) - The Administrator to handle everything outside of developing software - The Editor to edit documentation - 2 secretaries for the administrator and the editor (that's where you feel how old this book is) - The program Clerk: would be any code versioning system nowadays - The Toolsmith: your OPS people. - The Tester - The language lawyer: A cross team expert in some language

[@vanivari359]

A really interesting video would be, how you select people for your team or company (maybe it already exists). Because while i agree with all the principles and how you enable teams, i have to say - your video is about fine tuning a team with potential like optimizing a car to get more HP out of it. But i see more and more people in my projects, which do not even have an engine, they will never be able to do a good job without absolute micromanagement, remote programming and heroes fixing and cleaning up stuff afterwards (basically someone else doing the job). Last year i had multiple (!) developers with 6-12 years of experience, which for months violated basic java naming conventions multiple times in every commit, pushed non-compiling code, create empty tests etc. Somehow they slip though the net of our softened hiring interviews and then get reached around form project to project where they contribute negative value and everyone is just glad when they leave and avoids the conflict of calling the person out.

[@ContinuousDelivery]

I have a video that talks about how to take part in, including conduct, better interviews: kzbin.info/www/bejne/paTRgIxrr8yXg6s But I disagree with you about the "without micromanagement". There are no "magic people", the people out there are just as good/bad/indifferent as the people in here. Your example of the Java conventions is easily fixed, asset adherence to the conventions on every commit and reject changes that don't meet your coding standards, or teach the conventions. Sure it is a problem if you can't trust the people that you work with, but you won't fix that by micro-managing them, and will only fix it, by helping them to learn from their mistakes.

[@Sjwnbszhbsjnbvvs]

@@ContinuousDelivery @Continuous Delivery Hi Dave, I really like your content and follow you for a long time. I agree with @vanivari and I disagree with your answer. My reason is that although your answer ist correct, it does not fit in hard realities. At some point it is an organisational problem, you can not solve in your project. One aspect ist that you are not allowed to spend ressources in things like that. It would be very interesting to hear from you how you would deal with auch scenarios. I always try the following: maximum escalation right from the start and do what is right, ignoring the management. This is hard and takes alot If self motivation but I got success.

[@vanivari359]

​@@ContinuousDelivery that's right, i don't do micromanagement anyways because i really can't. It annoys me to no end and it's painful for both sides and it does not help - it frustrates the micromanager and the managed person does not learn and feels like you on the boat. So work is painful for everyone. But some people do not learn from their mistakes and if they constantly risk your boats safety and the "happiness" of your crew with all the pair programming and help in the world, you have to act. Especially if after that decision, those people will remain on your boat for 1-2 more months because of company internal politics (and a very social "everybody adds value" company mantra). My company (6 figure employees) only grows with hiring more people or buying more companies. Therefore, hiring get's more and more lenient - especially offshore because people there are incentivised based on how many people they manage, not how good they deliver.

[@BryonLape]

I've been programming for 30+ years. I've seen this over and over again the entire time.

[@ewinslow822]

Committing broken code sounds like a problem with a reasonable technical solution: automated presubmit checks.

[@brintmontgomery8323]

Love the look of the new graphics.

[@randomgeocacher]

Enabled / empowered teams are important. So much pain, learned helplessness and wasted time if you bring in too many juniors, no time to take them on, and stuck on external problems that people outside the team should solve. Not software development but similar problems in related IT / Engineering fields. These videos are a bit therapeutic, “yea, any sane org would build enabled teams first” I’m sure people with less interest / work ethic is an issue, but learned helplessness, bad onboarding and inability to work on tasks is more of an issue usually.

[@familyshare3724]

Yes. I'm on a team of three senior developers and also lead hundreds of junior developers. The first produces 3x more code with 1/3 problems per developer and the later team produces the opposite per developer. In all, three senior developers are more effective and vastly cheaper than 100 apathetic junior developers.

[@louisturmel7199]

Ownership, is really simple word but the more complex concept to make it understand In my experience little shy 20yrs, simply because people wants responsibilities, but doesn't want to put the offort to own what they are doing which required the general understanding of what it surrounds. It's like a kid that want a car, without putting the effort to understand how to drive, putting gas and paying for repair, but he still want a car :P Sounds extreme, but it's the example that came in my mind...

[@2k10clarky]

I rarely see software developers that don’t really care. I see inexperienced developers sure but to me that’s potential and they generally improve with experience. To me what I see time and time again working at a variety of companies and roles is the problem developers are technically competent but extremely opinionated and argumentative to the point of being belligerent causing friction in the team or the other type that causes problems are what I call the ‘maniac’ type again technically competent but just doing all sorts all the time changing everything constantly causing confusion and delay as the fat controller would say.

[@ssssssstssssssss]

I see a lot that are low in conscientiousness which means they have low intrinsic motivation. So while they may be motivated to code they lack motivation in the 70% of other things that make a good software engineer. And don’t think about the enduser nearly enough, though that blame falls on organizations as well. And it means they require a lot of management.

[@ContinuousDelivery]

If the devs don't think about the end user, that is nearly always the fault of the requirements process. It is not communicating end-user need and is, instead, micro-managing development through a sequence of instructions on the solution to build. Change the requirements process so that it ONLY SPECIFIES USER NEED and see the user-focus in the teams increase.

[@louisturmel7199]

Lucky you, I've seen over the last 20yrs a LOT of those folk that should be in that work field...

[@ecblanco]

I don't know about you, but God sent me this video. It's exactly the feeling about my team. Thank you, sir!

[@BryonLape]

I'm old enough to know Waterfall never existed and is a strawman excuse when "agile" doesn't work.

[@ContinuousDelivery]

Then perhaps you aren't old enough. www.projectmanager.com/guides/waterfall-methodology www.diva-portal.org/smash/get/diva2:835760/FULLTEXT01.pdf