I haven't ever seen an organization focused on "doing Scrum" that gets good results. However, some teams trying to deliver working software iteratively for their customers do find Scrum lets them deliver better than what they were doing before. But when Scrum becomes the goal and takes precedence over delivering software, it becomes a liability.
Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable.
But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.
> Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable.
But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)
That is an excellent point. If everyone knows exactly what the next most important thing is for the customer, and they are already working collaboratively to deliver it, maybe the meeting only takes 5 minutes. Or maybe the coordination happens informally just in the way they are working.
If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver.
Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.
It is not only that, but I have known a lot of developers who simply hate the daily stand-ups, either because they were lead in the wrong way or because it did not match with their introvert personality, and that this added a lot of anxiety that it had a negative effect on their performance. Anxiety is an important factor in procrastination.
Too often a daily standup is really just a way to try to make sure everyone is busy. Asking everyone what they did yesterday, what they are going to today, and if they have any blockers, doesn't usually help the team coordinate their work. As you point out, it just puts people on the spot to try to say something that makes them sound important.
But if you ask the team, "What can we do today to make the most progress delivering this next tiny slice of functionality for the customer?" the discussion is centered around the work. Usually introverted people can participate in that conversation without being uncomfortable.
> Video was supposed to be the future. Instead, it’s just another way to pick up the phone.
If you are using it to replace a phone call, then yes. It is just another way to pickup a phone.
On the other hand, I've worked with teams that use video as a virtual team room where a small team (3 to 5 developers) hangs out most of the time just like they would in a physical team room. They tend to mob or pair program most of the time. Sub groups break out occasionally if they need to work on something in parallel. Business owners just "drop in" to ask questions or provide feedback. Other teams that need to coordinate just jump into the room instead of trying to setup meetings.
Not every one wants to work like that, but video can provide a way of enabling highly collaborative environments that typically would only happen by giving the team their own room and requiring everyone to come into the office.
There are few better ways to increase your learning on a technical topic than to write a post about it and get lucky getting traction on HN. I wrote a post on State Machines a few years ago and the feedback I got from the HN community was incredible in helping me refine the post and deepen my understanding of the topic.
Back in the early 2000s I had a blog where I would try to post multiple times each week. While I wasn't a poor writer before, it was amazing how much I learned about overcoming writers block and being able to quickly get ideas from my head into a text file. (https://www.productivity501.com)
Later I had a blog post answering some key questions about Agile on a different site. That post didn't get much attention, but it was a good exercise in articulating part of what I'm trying to convey when coaching software engineering teams. (https://blogs.harvard.edu/markshead/what-is-agile/)
After reworking the post into a concise PDF, I sent it to a few people at a potential client. Later, after I had been awarded a contract, I found that the PDF had gotten emailed around within the organization and many people knew me as the "guy who wrote that PDF about Agile."
I then took the contents of the PDF and reworked it as a script for an animation that I posted to YouTube. That video now has 2.7 million views and has given me quite a bit of recognition in the industry...or at least recognition of the cartoon version of me. I hear he is much better looking anyway. (https://www.youtube.com/watch?v=Z9QbYZh1YXY)
The practice of writing on a blog has been key to my career, even though a lot of the benefits are a bit indirect and not something people would recognize from the outside.
The Goal - Eli Goldratt - It is a novel about optimizing a factory, but it is immensely valuable in thinking through what are the actual constraints on your team's ability to deliver software and how do you fix it without making other things worse. The Phoenix Project is kind of a modern retelling, but I'd start with The Goal.
The Principles of Product Development Flow - Reinersten - Great for thinking deeply about how you deliver value through your system and the tradeoffs you are making in what you choose to focus on next. Once again it isn't specific to software, but very relevant.
The 5 Dysfunctions of Teams - Lencioni - Common team problems and what to do instead.
Influence: Science and Practice - Cialdini - How to get people into agreement so you can move forward--a skill that can be used for both good and evil.
The Little Schemer - Friedman and Felleisen - It is kind of hard to describe why this would be useful, but I felt it made me think more deeply about what it means to program a computer in ways that indirectly supported the topics you mentioned. Or maybe I just happened to work through it at a point in my life when I was growing in those other areas too.
The audiobook version of The Goal is the best audiobook I have listened to! Each character is voiced by someone else, which sometimes doesn’t work well for audiobooks, but in this case I think they knocked it out of the park. The main voice actor in particular is phenomenal. I have tried to figure out who voiced Alex, but all credits for the audiobook simply say “ensemble cast” or “unknown”.
A decade ago Harvard Extension School's ALM in Software Engineering was a good match for what I was looking for as a self taught programmer with a Bachelor's and Master's degree in another field. There was a good blend of computer science fundamentals along with classes in modern (but not necessarily trendy) technologies. At the time it was also fairly inexpensive relative to other comparable options.
Programs vary widely, but if you can find one with a degree plan that aligns well with your goals it can be valuable. While there are definitely ways to learn everything on your own, I've found the credential helpful as a foot note to a track record demonstrating skills.
My biggest recommendation would be to work on a Master's degree part time in order to be able to do "real" work while studying. A Master's degree with 4 years of real world software engineering experience is going to be so much more valuable than a Master's degree from two years of just focusing on school.
> "Jira is the worst project management tool, except for all the others"
This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.
I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.
I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.
I was once looking for a solution to some technical problem, clicked on a promising web result, and found myself at my blog. I had posted a solution several years earlier but had forgotten about it.
> I was once looking for a solution to some technical problem, clicked on a promising web result, and found myself at my blog. I had posted a solution several years earlier but had forgotten about it.
That is funny.
Once I recognized that I have been researching the same topics I have researched before, it motivated me to change my blog from a "Hack the Box" showcase blog, to adding my technical journal on topics that were hard to find online and sharing my experience with certifications.
I have been thinking of adding more personal entries, but I don't want to make the blog a social media.
Once I have a weird curl bug that the software was using and I went to GitHub to report the issue. Turn out I did report the issues 4 years ago and there is no one to look into this. For some reason the software was having curl errors due to Windows' version of curl. The only way I can fix this is to
'remove-item alias:curl" since the alias is set to Invoke-WebRequest in PowerShell when software want to use curl command. Yes there is curl.exe but the software didn't know that.
I occasionally (yesterday in fact) experience this on StackOverflow. I'll be looking for an answer and come across one of my own answers or comments that I have no recollection of writing.
>"You've got to be willing to read other people's code, and then write your own, then have other people review your code. You've got to want to be in this incredible feedback loop where you get the world-class people to tell you what you're doing wrong." -Bill Gates
>"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. Code for readability." -John Woods
To summarize: Some day you might discover that you need to maintain your own code you wrote a long time ago, and you've turned into a violent psychopath who can remember your own address.
Circular reference? Joking aside, you write for yourself first when you write a blog. You learn better when writing about something and you see the gaps in your understanding when you try to explain something to others.
Felix Mendelssohn wrote a collection of pieces called Songs without Words for the piano. This might suggest that the term "song" can be more nuanced than simply whether or not there are vocals.
The original German title is "Lieder ohne Worte" (https://en.wikipedia.org/wiki/Songs_Without_Words), and there is AFAIK no strict requirement for lyrics to count as a "Lied" (or at least "Lied" is not connected to "singen" the way "song" is connected to "sing").
> Those with extreme views certainly do exist but they tend to be pushed to the front by those who have vested interests against homeschooling.
On the flip side, many homeschoolers have encountered public school teachers with extreme views. Extreme views may be fairly well distributed throughout society.
Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable.
But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.