The ESSENTIAL Qualities Of GREAT Development Teams
Вставка
- Опубліковано 25 кві 2023
- What makes a software development team great? Is it about software engineering roles, and the correct distribution of rockstar contributors, or is it about their ability to wield the latest and greatest technology? Is it all down to development team management and leadership? Actually it isn’t really any of these things, the data from DORA says that it is mostly about the ability of the team to self-direct. Teams that can make their own decisions without relying on external permission or instruction do best.
In this episode, software developer Dave Farley, author of “Continuous Delivery”, “CD Pipelines” and “Modern Software Engineering” describes the most important characteristics that predict success in software development teams - great teams take, and own the responsibility for their software and how to structure an organisation to activate that sense of ownership and responsibility.
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-
🎓 Learn how to work as a highly functional software development team using highly sought-after modern software engineering practices with my online courses. Particularly this one 'Better Software Faster' ➡️ courses.cd.training/courses/c...
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
BOOKS:
Team Topologies: Organizing Business and Technology Teams for Fast Flow - Matthew Skelton & Manuel Pais ➡️ amzn.to/2Y0NdSO
Accelerate, The Science of Lean Software and DevOps, by Nicole Fosgren, Jez Humble & Gene Kim ➡️ amzn.to/2YYf5Z8
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Sleuth is the #1 most accurate and actionable DORA metrics tracker for improving engineering efficiency. Sleuth models your entire development cycle by integrating with the tools you already invest in. You get a full and accurate view of your deployments, see where true bottlenecks lie, and keep your team’s unique processes and workflows. With accurate data, Sleuth surfaces insights that your engineers can act on to improve - with real impact. ➡️ www.sleuth.io/
Roost, An Ephemeral DevOps Platform, automates your DevOps pipeline. It creates ephemeral DevOps environments on-demand or based on pull requests. Roost reduces DevOps complexities and shortens release cycles with fewer engineers. ➡️ bit.ly/CD2Roost
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com - Наука та технологія
🎓 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
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.
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
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?
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.
I have a video that talks about how to take part in, including conduct, better interviews: ua-cam.com/video/osnOY5zgdMI/v-deo.html
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.
@@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.
@@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.
I've been programming for 30+ years. I've seen this over and over again the entire time.
Committing broken code sounds like a problem with a reasonable technical solution: automated presubmit checks.
Love the look of the new graphics.
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.
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.
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...
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.
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.
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.
Lucky you, I've seen over the last 20yrs a LOT of those folk that should be in that work field...
I don't know about you, but God sent me this video. It's exactly the feeling about my team. Thank you, sir!
I'm old enough to know Waterfall never existed and is a strawman excuse when "agile" doesn't work.
Then perhaps you aren't old enough.
www.projectmanager.com/guides/waterfall-methodology
www.diva-portal.org/smash/get/diva2:835760/FULLTEXT01.pdf