How Agile Teams Grow Toxic! Ep. 4 Commitments

[@HealthyDev]

How have you coped with unnecessary urgency and unrealistic expectations around commitments? Leave me your feedback and thoughts below!

[@jacekjacenty]

I have tried to reason with the dominant powers and got fired. They are willing to forgive a lot in terms of incompetence. But they are very fussy about obedience. Trying to reason with them without being considered disobedient or challenging their authority is an art that I do not have.

[@HealthyDev]

@@jacekjacenty sorry to hear that. It's happened to me too. Better for you to be somewhere that is willing to listen to their talent.

[@rozzerthat]

@@jacekjacenty sorry to hear that, what a shame. Well, such a place doesn't deserve you. Collectively, our team is currently in that exact spot your are describing. In the future, don't be such a well meaning caring good samaritan, don't attempt to reason or flirt with the dominant powers, you're now an intruder in their territory and you put a big target on your own back. Remember, these people have made a career out of not much tech skill, so power is the game they know so why go near and get burned? Look around outside your team- invariably you'll find lot of new, energetic go-getter types that are bright eyed, bushy tailed and ready to change and conquer the world. Use them as shields/buffers, work real hard on having a buffer between you at the powers that be. All it takes is stroking the ego of the shields a tiny bit (pro tip: fancy made up titles are free and infinite). This keeps you invisible in the eyes of the dominant powers. Retreat to the background and learn to become a nobody, find shade and eventually fade into the darkness. Then poof, one fine day you are gone. Hate to say this, but we have been playing that game this past year for our team's well being, finding those go getters and using them as buffers. Strangely, it works surprisingly well and in the meantime, we are in the process of fading into darkness, one person at a time. We know there is only one way and that's out and everybody needs an exit strategy. My 2 cents. :)

[@rozzerthat]

@@HealthyDev does such a place even exist? Bureaucrats vs Technologists is such a power battle everywhere.

[@HealthyDev]

@@rozzerthat if it doesn't, it's up to us to make it that way! No one's going to give us permission...

[@alejandrourizar3814]

How come this video has so few views? This is great content

[@CyReVolt]

I think it's growing because Corona gave many of us the extra time, space and means to exchange among software engineers/developers globally. And yes, I agree. My company is having many of the issues Jayme is addressing, and I have been trying to communicate them since I started 9 months ago. It's too much to fix and at the same time they started a huge project with a most unrealistic deadline. I wish I could at least explain to them why it doesn't work out.

[@veorEL]

I will do my part to make sure that some PMs get to see this :-)

[@thsu1]

i guess that there are mostly managers out there. the people who only go to those meetings without doing any actual coding. :D

[@joeldick6871]

Question for you Jayme: In my experience, there are two reasons why I wouldn't be able to fulfil my "commitment" to complete a specific task: 1. The task took me longer than I expected, most of the time due to scope creep, but it could be because I underestimated how big/difficult the task would be; 2. Because I never got around to that task because other things burned through my time. It's not so difficult to explain to a manager what went wrong in scenario #1. The most difficult thing is explaining to them #2. Can you talk about how to go about managing when problem #2 arises?

[@HealthyDev]

Great question. In this kind of an environment I use this as an opportunity to discuss the need to account for extra time needed for teamwork. In many companies then you’ll either be a) asked to add extra time to tasks to account for it, b) asked to create new “teamwork” tasks, or c) your capacity is lowered. I prefer c, then a, and if all else fails b. All of these are symptoms of the fact that assigning work to individuals doesn’t make sense in the context of complex teamwork like software development - but that’s another topic. I’m not sure if that helps, YMMV.

[@Astillleros]

“”Really free people up as much as possible to just love their job.” Yesss a million times over!!

[@wolfman5740]

This is very good stuff. I have been trying to share it with people in my circle already. Thanks!

[@HealthyDev]

You’re very welcome, thanks for the feedback wolfman 👍

[@seesharper8913]

I work for a small company, and I always used a good buffer and ended up finishing things early. I think this often left the impression of me just having really good performance and the company started encouraging more ambitious timelines. We now took on a veeery large project, that was estimated to take around 6 months for a minimal viable product, and I've had the guilt of needing to push the timeline further and further. In addition to discovering new requirements and features in an adhoc way. Luckily, my boss is extremely understanding, and has never seemed "mad" about pushing these timelines... But I can still always sense a degree of disappointment from him when we have to push it. My boss is always telling me "good work", "good job", and "The product is coming along nice, and I want to make sure we do it right". Even though he is very reassuring, I still catch myself being hard on myself wanting to exceed expectations. It's just really hard to look at a project you put hours in to, and think to yourself "Man, I really need to rewrite this". I'm on my 3rd rewrite, and already considering a 4th, but I really just want to get the product at least launched as we have a couple clients on standby (No commitments, just largely interested). I feel myself getting this habit of thinking, "If I could just give them something functional, I could buy myself enough time to accommodate them and myself" and I am not sure if that is a healthy way to think of things.

[@HealthyDev]

That balance between good enough and perfect is hard for me too. You’re already so far ahead of many people by even having the internal conflict to realize this. Keep going - you’re only going to get wiser!

[@richardhp77]

I also think that taking on a big deliverable is another potential problem. If you can strip that down to the bare, bare essentials and deliver those first, it might be a much smaller and easier to manage target initally. If you get push-back saying that all the features are necessary, then try to isolate one or two that are the most important, and try and deliver those and get feedback etc. I think that reduces the big pressure build-up that comes with "if we can just ship an MVP" type mentality. Just keep stripping it down until you can get something stable in production, then you have a baseline you can add to rather than always feeling behind and under pressure. People often think they need stuff that they don't actually need. When push comes to shove and you make them choose, they will tell you what they really want and find important. If they think they can have it all they will of course ask for everything and tell you that they have to have it. I'd be interested to hear how that project went in the end.

[@brandonpearman9218]

Love to hear you say "you might be doing scrum but that doesn't make you agile". This has been a huge pain point for me, when companies say they are agile because they do scrum. The team has to follow the scrum guide exactly and are not allowed to change any processes. Hard core scrummies often see commitment as a crucial part of the process, and if you are not meeting your commitments it is because you are bad estimating.

[@Meritumas]

Another form of micromanaging… so called “corporate agile “.

Man, your content is amazing. It's not often I am in agreement with a youtuber on agile :D

[@HealthyDev]

Thank you! I had to do agile wrong for a long time before even beginning to do it right...

[@Muuuzzzi]

All true and it all resonates ................

[@ian1352]

I'm not even sure what agile is supposed to mean anymore. I find there are interminable meetings with the stated aim of reducing uncertainty. Then there must be investigation tasks to the same end. And finally when the actual coding work starts that turns up all manner of pitfalls and things no-one realised we needed to take into consideration. Now everyone wants to know why we didn't do more to reduce the uncertainty. This is inevitably followed by spending time to try to figure how to prevent that happening again.

[@errrzarrr]

This is because there's too much Agile and no Architecture at all

[@richard975]

pppl always overestimate their plans

[@j_dv2008]

Corporate world adding too many layers of management is a big problem, but it's something a Developer can do nothing about.

[@fortheSavior]

This one is good, thank you! How do you deal with the "code monkey" mindset in a company? Our major project has ever increasing tasks that get added to existing milestones, so goals become increasingly impossible to hit. It feels very much like you said: I'll code exactly what the requirements are, and nothing more.

[@HealthyDev]

As always only my experience, but the primary problem in this type of situation usually ends up being an impatient owner or manager who doesn’t understand doing more at once is wasteful (the small batch vs large batch mindset). I actually saw a great tweet about some of the implications (which you and I probably know but impatient people resist) this morning: twitter.com/erik_gibson/status/1103821438425882624?s=21 I’ve tried for years to help people do smaller batches of work with various levels of success. It’s incredibly hard and slow when there is a lot of resistance due to past experiences until it’s fully supported by everyone. For me unless people really are open to letting go of so much attachment to deadlines, the only way to fix it is to either replace the manager with a behavioral mismatch with software development, accept it and try to laugh at the theatrics, or move on. That might sound a little dark, I’m just trying to be honest and realistic.

[@fortheSavior]

@@HealthyDev LOL! Dark, but appropriate! Thank you!

[@BlackHermit]

I have the exact same stone-lightbulb in my room!

[@kaboodlefish]

I feel like it's from something. At first it made me think of the stones from Temple of Doom.. but I'm wondering if it was a Star Trek thing.

[@TheEVEInspiration]

The worst thing is business changing priorities every day and every phone call. While still expecting all existing commitments be done and the new commitments to be done as well. Then communicating in a tone that is finger pointing, that it is developer incompetence that causes any delays and frustration. I hate agile with a passion, there is nothing agile about it, it is all smoke and mirrors. The ideas of failing early and acquiring frequent feedback are good, but that does NOT require agile as a way of structuring work at all. In fact actual complicated tasks are often not even suited for even frequent feedback and failing early. Overall, it is way too suffocating and it introduces chaos and bad practices to the workflow. I rather start a project with just a few people that identify the overall architecture and the technical hurdles. Then follow up with proving in concept that those hurdles can be taken and have a solution, before continuing. This does much more adhere to the idea of failing early and correcting a design to suit needs. As there does not need to be a working product at this stage, a lot of overhead can be cut and proof of a design can be given really early. And this also makes it superior in the feedback sense. Of course, identifying what customers want and why is still the first step...especially the why as that gives insight and not just a goal. Overall, waterfall seems still to be the superior approach, but it has to be done in controlled chunks. 1. What and why (iterate a few times to establish solid ground). 2. Design and prove it will work. 3. Build it in stages and with the idea in mind of early feedback. Scrum/agile in general is just an excuse of making things up as the project continues...at least this is how it seems to work most of the time. If there are good people that are creative geniuses and can glue the things together along the way, fine, but credit them...not the process.

[@TheEVEInspiration]

I like to add that spending time acquiring good input early on is way more important than impulsive feedback later on. Otherwise it is just the "this is new and unfamiliar" that dominates feedback and the development process. This leads to feature/code bloat...very bad. Real valuable feedback only comes after a period of actual us. Then real use cases for improvement will become clear above the noise!

[@HealthyDev]

As with all my videos I can only share my perspective. I’ve done waterfall, agile, and fake agile projects. My current ranking is truly agile > waterfall > fake agile. When we first started doing truly agile projects in the early 00s it was understood you needed a stellar team and flexible management. These days waterfall is indeed better if you’re dealing with a micromanaging, no-commitment to quality fake agile project - which unfortunately are the majority.

[@aidenz4937]

Great Content! 1. Buffer for an estimate. 2. Communication for expectation reset. 3. Refuse the estimate when you have the instinct you can't. 4. Outcome over output. 5. buffer for multiple drafts. 6. Shorten the commitment chain.

[@frankschreiber458]

I am glad I found these videos. They help me a lot. I also found some unhealthy habits I have. Thanks.

[@SteversIO]

I've been doing scrum and kanban for years and have been team lead for the second half of my tenure. Sometimes I struggle to articulate what I intuitively know to be true. Thank you for arming me with the right analogies and context to help explain thoroughly. The point about looking at software as a rough draft seems so obvious yet has escaped me this entire time. I just always explain that there's a lot of refactoring when approaching using TDD etc.

[@tingxyu]

Is there any plans to make the next episode of this so far? I'm waiting for it and wanting to share more to my colleagues!

[@HealthyDev]

I’m on the fence. I’ll be covering what I planned to after this, but I may reboot it further back to offer more context.

[@eric-seastrand]

This is all such incredible advice! I wish somebody had told me all this when I started consulting a decade ago. 💯

[@jethrolarson]

I guess you shouldn't have committed to doing #5? :P

[@PaulSebastianM]

Managers listening to this will just think "They basically want to finish their job when they feel like it. Not on my watch! 🧐".

[@zhujik]

If you display text on the video, make sure it is there for long enough for people to read without rewinding thanks:)

[@HealthyDev]

+zhujik thanks I’m still trying to dial that in :)

[@dinoscheidt]

6:35 Fun fact -> 45% of the top 500 CEOs have an engineering background.

[@ketanpurohit9086]

The segment between 21:00 and 22:30 is just beautiful, a pure distillation of why things go toxic. Great channel BTW, I am enjoying working my way thru these nuggets of thoughtful analysis.

[@HealthyDev]

Welcome to the channel! Glad you’re getting some insight from my ramblings. 😉

[@j_dv2008]

If your job this morning is to give an estimate for feature x, then not giving one due to lack of info is seen as not doing your job.

[@HealthyDev]

Well I’d argue your job is to deliver, not to prematurely commit when you can’t.

[@errrzarrr]

This is my Scrum culture

[@ChrisAthanas]

Great talk, thank you!

[@manishm9478]

Woohoo you're nearly at 100k subs! 😀

[@MrJohn360]

Thanks for sharing

[@HealthyDev]

You’re very welcome. Thanks Jaime!

[@RobGravelle]

I have a deep-seated fear of commitment. At least that's what my ex said.

[@HealthyDev]

Ha! 🤣

[@mathemitnullplan]

you never talk about money, i can only guess that after 10 years you are done and set.

[@HealthyDev]

After being the sole earner in a 5 person family I am definitely not set financially. I just choose not to focus on that topic I feel my value is more around doing the work etc.

[@redhotbits]

your palm looks very red?

[@HealthyDev]

I’ve always had bad circulation on the opposite side of my thumb of my palms. I’m not sure if it’s from using the keyboard or playing guitar all these years or what!