Comments by "" (@retagainez) on "Where Agile Gets It Wrong" video.

@TheEvertw What a nightmare! Congratulations on getting out of there in one piece! That team sounds like they're real good at engineering, engineering their own problems that is.
3
@azena. Well I appreciate the general observations you've made more than specific scenarios. Certainly a good read, thanks. It makes sense what you have to say about mob programming. I think it makes perfect sense that mob programming would be great for getting some people who struggle with people to add value in a cooperative setting. I haven't yet experienced any mob programming and the amount of pair programming I have has been limited even if it has been my favorite form of collaboration yet. On a side note, I envy you. I would definitely enjoy contracting, but I've yet to break into even the entry level market. Not that inexperience would be a barrier to contracting, but perhaps I just want a bit of reputation before I get into that.
2
@awmy3109 So how would people start a new project while pair programming then? You don't have to program 100% of the time when you are "pair programming," there's a lot of conversation and discussion involved, too.
1
@awmy3109 Well pair programming isn't just about programming, so yes, it is about discussion. You're discussing with the one other person who probably is the best match for the project. So, you would be seeking a second opinion more than blind confidence in their guidance. Pair programming is more of a tool to help alleviate burnout after typing a significant chunk of code (this is why people take pomodoro breaks). When you get mentally exhausted by physically typing on the keyboard and following syntax, it can affect your design choices (I wonder if there is a conclusive study on this, it would be interesting.) and having a second person to take over while you recuperate is great! There are common misconceptions of what pair programming means, for example you can pair program remotely, it doesn't have to be in-person.
1
@awmy3109 Well-- you could make the convincing argument that pair programming is just a real-time PR without any delays. Its analogous to trunk based development.
1
@Immudzen Sounds like mob programming.
1
@Immudzen Mob programming should be done sparingly only because it is expensive, it's a good way to "see what sticks" as somebody put it. I think pair programming is far less expensive but just as viable as mob programming. The times that people program alone, it's just using it as a form of debt for delaying code review to a later date due to people being far too split apart in responsibilities. Alternatively, it could also mean that the company is hiring employees that don't actually match well personality-wise (and are somewhat antisocial or dont work together naturally) or they don't know how to interview people. Rhetorically, how many times a day do you speak to somebody that's not directly involved in your code? Whether you are gathering requirements, getting clarification, or pushing back on a feature you're going to be talking to somebody. Nobody can be completely insulated from the real word, that requires communication skills.
1
@errrzarrr Continuous Delivery and Continuous Integration is a healthy practice, his statement on DORA follows. Of course, it all depends on whether its actually 2x, but it certainly is more valuable being that iterative by "having the ability to deliver daily" rather than being stuck in a monthly waterfall process. As a disclaimer, DORA is just a DevOps metric and should only be taken as such, not as a fact. Metrics show a very limited scope of the story and often require much more context to judge whether or not it is meaningful.
1
Do you consult for groups of developers? Wondering if there are any good studies on applying correct agile models to groups. I was reading a single study on the effect of pair programming for short amounts of time where in pairs that were either made up of heterogenous or homogenous (things like personalities matched, previous existing knowledge) people. There is no silver bullet to getting people to work well together, but perhaps there is a common pattern for finding groups that mesh well together. Do you have any anecdotes that suggest something like that? I feel like personality matches and social skills are overlooked. I personally thought (in University) that it would be odd to be co-workers with some of my peers because of a general lack of social skills. I admit that it was immature of me at the time to think this way though.
1
That reminds me exactly of some of his earlier videos from years ago how he took somebody's (Java? I think) code and re-factored it into unit tests. Although, it was a retrospective, we don't ever see what the previous person who wrote the code was thinking, but pretty similar. One of my favorite video series.
1
@AlexGnok CI (and CD by extension) is going to be hard for your company if its difficult for a lot of your developers to work together in a single branch AND implement automated "QA" into more facets of the software development. Trust is a big factor. Trust in that the tests are correct, that whoever wrote them wrote a useful test. Trusting your "neighbors" is also important, such that they don't break your code when they add a commit. Some of your testing may be manual, but the point is to reduce how much of it is manual. Testing accessibility can be hard when there aren't any tools, you might probably have to write your own tooling to assess the level of accessibility of your app, and it can be useful to do that on some low-hanging fruit to get a small sneak-peek into how a more dedicated solution would help. I am sure there are objective ways to measure how accessible something is. For browsers at least, there is a plethora of automated tools. There's a whole idea of "Web Content Accessibility Guidelines" and automated tools that flag errors on those guidelines. Now, I will risk some controversy here by saying maybe the problem is not that many people are junior level, but rather something much simpler but viewed at a layer higher than simply evaluating individual developers. Maybe that company isn't a shining example on how to write software. Or maybe accessibility isn't very important yet. Up to you if think its worth it. Somehow, somebody thinks it's all worth some $ amount.
1
You might be shocked to hear that a better salary doesn't fix any of the frustration you feel as a result of "red tape." This is my belief as part of my anecdote from working a period of time in which my employer offered to double my pay. I hope that the only thing stopping you from leaving is preservation of your professional reputation with the company, and even that is expendable if you believe you can help others in a better environment. Once the company can, they will treat you as expendable. Current job market is not very good if you are lacking YOE so most people recommend to not abandon your current job until it improves.
1
Continuous values is a unique test case I haven't really seen it around much. You could do it up to a certain precision I guess, but if losing some of the precision is inexcusable, you definitely are going to have to write a more thoughtful test. Although, if you are comparing data in a graphical way aren't you tolerating some loss in precision one way or another? How precise are we talking when it comes to people analyzing data? It's like comparing where a web page's form element is in the correct spot to the exact pixel (and somebody missing if it shifted one pixel left or right), that's pretty precise.
1
@ЛукашевичАнатолий Right, it sounds like this depends more on generalized mathematical formulas or certain properties or axioms, which can be difficult to put into code let alone understand them.
1