markshead
Joined 15 years ago
Joined 15 years ago
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.
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.
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.
(https://blog.markshead.com/869/state-machines-computer-scien...)
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)
I think took the general ideas from the blog post, the paper, and the video and put it together in a book that I generally give away like business cards to potential clients. (https://www.amazon.com/Starting-Agile-Finding-Your-Path/dp/1...)
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.
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.
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.
On the flip side, many homeschoolers have encountered public school teachers with extreme views. Extreme views may be fairly well distributed throughout society.
The idea that there were parts of the US where you could buy a house for $60k was just as foreign as the idea of someone making $25k per year. They simply had no frame of reference for what wages and cost of living look like in places that weren't big cities.
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.