What would you change regarding meetings? Do you think they are totally unnecessary or just a badly used instrument? I have my problems with choreographies like scrum, in which you create the need to meet artifically.
@@theSnackableCTO It really depends on your scenario. I'm in 3 projects, 2.5 scrums, 3 hours of "sprint planning," institutional "check-ins," etc. Any time in-between those meetings is essentially wasted if you consider it takes 15 minutes to get back into working. As a developer by title, I see this as mostly wastage. I've heard of 15 minute scrums that don't go over 30 minutes, maybe I'd like to see these. Encouraging an open door policy to chat or ask for help is also useful. When the content of meetings don't pertain to your task(s) at hand it's challenging for me to be engaged.
"managing programmers is like herding cats" - not impossible, but you can't handle them like you do sheep. Also, keep communication async - messages and email - over always having meetings. Teams (and Slack) is great to have communication between two people where the rest can just read the convo, improving time management for everyone involved.
Async communication is indeed good. Sometimes it's good to go sync as well. In our teams it's roughly, I would say, 80-20 (Async/Sync). We often rewivew in pairing sessions with great results and plan a feature as a group. But smaller things which don't need presence are all in Teams for us. Regarding the herding example: I don't prefer herding at all. Best results I see happen in fully responsible teams, even without a team lead or manager in place. But if a company does prefer herding, than don't treat them like sheeps =D
To some degree, yes. We need to have our time to work deeply focused, of course. And then, we need to have to time to communicate with others and help peers proceed if necessary. A good part of Software Engineering is communicating. Within teams, this is often not a problem since developers understand more about when to talk to other developers. It's different with "outside" people who often don't understand development in its core. A lesson learned for me was that the less we devs communicate intrinsically, the more non-developers try to define what we need to do. That isn't helpful, and it reduces the developer to a coder. I personally would rephrase "our work is to think and this requires silence" -> "our work is to communicate, think and iterate, which requires a mature working environment." What worked best for us was shaping this environment as developers. So, we had what we needed, but we needed to take more responsibility and ownership at the same time. The result was this mature environment. -- I appreciate your feedback :)
@@theSnackableCTO, I agree with you. I think this problem with the "outside" world could be resolved by having managers with technical backgrounds. Why do we hire people who never write a single line of code to manage software engineers?
@@cleitonluiz7136 many reasons. I mentor both devs and managers, some are technical some are from a non-tech background. The number one reason is being not aware of the need. The second reason often is control. We see this often in a manifestation like scrum. It's primarily designed to push business requirements to devs, but non-technical persons. I recommend to look into the original agile manifesto, which is a bottom-up approach based around the experience of the engineers. By not doing that we create a gap between business and development instead of bridging the gap. The result are non needed meetings for fixing the bad symptoms of this wrong approach. Those meetings are most often those which devs Label es useless. I would label them as totally avoidable, since development is excluded from the descion making around development and requirements. Personally I think that derived from industrial age thinking, ignoring the fast-paced nature of development and it's challenges.
Developers don't have to just be a cog in the machine. They can express what they want out of a project. Alternatively, they might be shy or introverted and therefore prefer to be told what to do.
Yes, we want to be left quiet and working in peace. Too much communication is distracting for a job where you need to think and most of the job related things can easily be solved with a short message on slack.
The product owner/project manager/SM ask stupid things, a provide 0 info and complaints to the developer, even developers needs to discuss with the client and capture the real requirements, stop hire PMs without ideas of how to get requirements
@@theSnackableCTO My impression is that the best scrum masters, are developers themselves as well. That's my experience so far. PMs without any coding experience often cause a lot of problems.
Yes, because scrum master can work amongst the team or imperativly. Many just enforce "business" ideas onto devs, instead of working with the devs to improve ideas and make the product even better. I mean the devs are the people who actually build the app. So it makes sense to work with them, instead of being disconnected.
A dev here... In my humble opinion ... We are very good understanding how a system work, we know when the communication in the company is open, flexible and efficient enough to rise our hand and propose something... Don't spend our time talking about things imposible to resolve in a weekly meeting with other 15 devs... Instead, make sure of having good documentation about the business logic, let us know how the company is making money, allow us to block 1 or 3 hours at week to learn something and present an improvement every quarter. We will found the information and reach out the people we need. Most of those ideas will be small improvements but some of them will be awesome.
@estephaniacalvocarvajal594 Great view! And this is why managers and leaders should create an open environment of trust and let the devs do it. Agree with meetings. Meetings are misused these days. What I experienced works very well is to include devs more into feedback from clients, when possible first hand, and then let the devs come up with an idea for a solution. That creates real ownership. And the clients will stop putting unrealistic deadlines upon the company which then get passed down to the devs.
The only answer to this is Adventure Driven Development, and it's not a top-down pop-in replacement for broken development processes I explain this on my channel
![PASULOL รามเกียรติ์ ตอนที่ 4 นนทกพบรัก [Ramakien Ep.4: Nonthok in love]](http://i.ytimg.com/vi/tMUQgmZzf_A/mqdefault.jpg)
Because we're trying to work through long meetings
What would you change regarding meetings? Do you think they are totally unnecessary or just a badly used instrument?
I have my problems with choreographies like scrum, in which you create the need to meet artifically.
@@theSnackableCTO It really depends on your scenario. I'm in 3 projects, 2.5 scrums, 3 hours of "sprint planning," institutional "check-ins," etc. Any time in-between those meetings is essentially wasted if you consider it takes 15 minutes to get back into working. As a developer by title, I see this as mostly wastage.
I've heard of 15 minute scrums that don't go over 30 minutes, maybe I'd like to see these. Encouraging an open door policy to chat or ask for help is also useful. When the content of meetings don't pertain to your task(s) at hand it's challenging for me to be engaged.
Thank you for sharing your experiences. This is really valuable and insightful.
Happy to! Stay subscribed, more will follow :)
"managing programmers is like herding cats" - not impossible, but you can't handle them like you do sheep.
Also, keep communication async - messages and email - over always having meetings. Teams (and Slack) is great to have communication between two people where the rest can just read the convo, improving time management for everyone involved.
Async communication is indeed good. Sometimes it's good to go sync as well. In our teams it's roughly, I would say, 80-20 (Async/Sync). We often rewivew in pairing sessions with great results and plan a feature as a group. But smaller things which don't need presence are all in Teams for us.
Regarding the herding example: I don't prefer herding at all. Best results I see happen in fully responsible teams, even without a team lead or manager in place.
But if a company does prefer herding, than don't treat them like sheeps =D
Maybe they don't speak too much because they are working? Because our work is to think and this requires silence?
To some degree, yes. We need to have our time to work deeply focused, of course. And then, we need to have to time to communicate with others and help peers proceed if necessary. A good part of Software Engineering is communicating.
Within teams, this is often not a problem since developers understand more about when to talk to other developers.
It's different with "outside" people who often don't understand development in its core.
A lesson learned for me was that the less we devs communicate intrinsically, the more non-developers try to define what we need to do. That isn't helpful, and it reduces the developer to a coder.
I personally would rephrase
"our work is to think and this requires silence"
->
"our work is to communicate, think and iterate, which requires a mature working environment."
What worked best for us was shaping this environment as developers. So, we had what we needed, but we needed to take more responsibility and ownership at the same time. The result was this mature environment.
--
I appreciate your feedback :)
@@theSnackableCTO, I agree with you. I think this problem with the "outside" world could be resolved by having managers with technical backgrounds. Why do we hire people who never write a single line of code to manage software engineers?
@@cleitonluiz7136 many reasons. I mentor both devs and managers, some are technical some are from a non-tech background.
The number one reason is being not aware of the need.
The second reason often is control. We see this often in a manifestation like scrum. It's primarily designed to push business requirements to devs, but non-technical persons.
I recommend to look into the original agile manifesto, which is a bottom-up approach based around the experience of the engineers.
By not doing that we create a gap between business and development instead of bridging the gap.
The result are non needed meetings for fixing the bad symptoms of this wrong approach.
Those meetings are most often those which devs Label es useless. I would label them as totally avoidable, since development is excluded from the descion making around development and requirements.
Personally I think that derived from industrial age thinking, ignoring the fast-paced nature of development and it's challenges.
Developers don't have to just be a cog in the machine. They can express what they want out of a project.
Alternatively, they might be shy or introverted and therefore prefer to be told what to do.
@@incarnateTheGreat I agree.
Either way it makes sense to involve developers.
The way which makes the least sense is clearly to push with deadlines :)
Yes, we want to be left quiet and working in peace. Too much communication is distracting for a job where you need to think and most of the job related things can easily be solved with a short message on slack.
The product owner/project manager/SM ask stupid things, a provide 0 info and complaints to the developer, even developers needs to discuss with the client and capture the real requirements, stop hire PMs without ideas of how to get requirements
Very honest words! I would add stop hire PMs who like to work "above" developers, not amongst them.
@@theSnackableCTO My impression is that the best scrum masters, are developers themselves as well. That's my experience so far. PMs without any coding experience often cause a lot of problems.
Yes, because scrum master can work amongst the team or imperativly. Many just enforce "business" ideas onto devs, instead of working with the devs to improve ideas and make the product even better. I mean the devs are the people who actually build the app. So it makes sense to work with them, instead of being disconnected.
A dev here... In my humble opinion ... We are very good understanding how a system work, we know when the communication in the company is open, flexible and efficient enough to rise our hand and propose something... Don't spend our time talking about things imposible to resolve in a weekly meeting with other 15 devs... Instead, make sure of having good documentation about the business logic, let us know how the company is making money, allow us to block 1 or 3 hours at week to learn something and present an improvement every quarter. We will found the information and reach out the people we need.
Most of those ideas will be small improvements but some of them will be awesome.
@estephaniacalvocarvajal594 Great view! And this is why managers and leaders should create an open environment of trust and let the devs do it.
Agree with meetings. Meetings are misused these days.
What I experienced works very well is to include devs more into feedback from clients, when possible first hand, and then let the devs come up with an idea for a solution. That creates real ownership.
And the clients will stop putting unrealistic deadlines upon the company which then get passed down to the devs.
The only answer to this is Adventure Driven Development, and it's not a top-down pop-in replacement for broken development processes
I explain this on my channel
I will take a look into it! Is it related to agile? Sounds like a story-driven approach of original agile. (Not scrum; don't like it)
"I used to believe the stereotype that developers are non-communicative," This wrong assumption makes many people not go into development!
Yes, that's true. There is already a public general (false) notion going on when it comes to the image of a dev.
My coworker dev. Stays quiet when he is about to fart.
Is that unique to developers?