
Making the Switch: The Reality of Moving from Windows to Mac for Your Software Engineering Team
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
A Jedi Master, an engineering manager, and five software developers enter a bar and… Oh, wait, you meant to ask about how to make daily standup meetings more useful, valuable, and engaging? Oh, c’mon – just tryin’ to be funny. Fine, fine.
To be clear, standups are important, and most developers like them. If they are set properly. But, having sat through many bad standups over the years, I know some of you share the pain. This is why this article tries to help you to enhance the experience for your team.
In a nutshell: standups are short 15-minute, daily all-hands meetings for sharing information to help your team stay informed, focused, and efficient with their current tasks. It’s advisable for standups to be held at the same time every day just so everyone can plan them into their day, every day.
While standups are not required by Agile, they provide an opportunity for your entire team to interact face-to-face or via video chat. These are the most effective modes of communicating for co-located and distributed office environments. There are two primary formats for conducting startups – the “Yesterday, Today, and Blockers” format and the “Walking the Board” format.
This is a typical format for a daily standup meeting. It’s is run by a Scrum Master asking each team member the same three questions every single day… or, if you’re lucky, just once a week.
This format depends upon self-reporting where answers may reflect more on the individual than the task. It’s also likely that team members are thinking more about what they should say than listening to what others are sharing. Not everyone is brave enough to volunteer that they need assistance with a task. This standup routine can be painfully monotonous. If you’re using this format, and you can see engagement could be better, you might just need to mix up the format.
This format accomplishes all of a standup’s objectives in a more direct, faster, and visible manner focusing on task status instead of the individual. Tasks in your project management software are likely defined by four main states. In this model, we read them from right to left. They correlate to Release, Test, Develop, and Backlog. A quick mockup is provided below, and it’s illustrated further down in the YouTube video by Development That Pays.
Task
Task
Task
Task
Task
Task - Luke
Task - Lea
Task - Hans
BLOCKED
Task - Darth
Task - R2D2
Task - C3PO
Task - Obi
Task - Yoda
Task - Yoda
The individual running the startup doesn’t need to be the Scrum Master. Any team member can be the meeting’s facilitator and it’s strongly encouraged to rotate the baton to promote team ownership of the process. Rotations can be daily, weekly, by Sprint, whatever works best for your team. Here’s how it works:
This inherently focuses more attention on the board and what others are saying than planning what to say. It also gives each team member some recognition and a little bit of a rush in being able to move the project forward. You can still get some more value from your daily standup meetings, though.
Scrum masters, software engineering managers, and development teams can and should have a part in making standups more useful, valuable, and engaging. Just as iterating can improve software, it can improve processes. So, feel free to experiment. In this regard, there’s a load of data that you can use to improve your standups.
This is best kept as a quick (15-30 second) mention and pinning on your Whiteboard, unless you find it too disruptive. This is a quick and easy way to share something useful, whether an inspirational quote, a short coding tip, reinforcing a coding standard, company news, recognizing birthdays, anniversary dates, graduations or certifications, links to short articles or videos related to the project, announcing pizza day or discounts on products of interested to your team.
Though this doesn’t serve the specific objectives of the standup meeting, it can be a small boost to team morale and reinforce a pleasant work environment.
Trust, but verify is a good practice. It’s easy to spot pull requests that are taking longer than they probably should. Most would also agree that a developer may be encountering difficulties if they’ve not made a recent commit. A standup standup meeting is a good place to simply ask the individual about any complications they may be encountering with specific tasks so other team members can offer assistance directly.
Specific metrics can be gamed, but not in front of everyone and not for long when an engineering manager has access to an automated and comprehensive range of development metrics. Likewise, single metrics, especially outside norms can indicate that there may be a problem and prompt additional research (examining additional metrics). Even with automated performance metrics, this can take time to do for an entire team and will eventually lead to verifying any challenges with each team member.
Our “Step 4” in How To Use Data To Make Retrospectives More Effective, advocated identifying 3-4 issues or metrics to improve each Sprint. After all of the tasks have been discussed, it’s worthwhile to spend a minute or two to reinforce this effort to focus on one of those metrics. You can ask the team if they’ve discovered any tips they’d like to share. On the same score, you might share metrics or ask about how they feel about progress made on items identified for improvement in previous retrospectives.
These can be good visuals to pull up for your daily standup meetings to get a sense of whether your team’s on track. As it’s likely that you prioritize your tasks, task status plus the Sprint burndown can help guide decisions. If one developer finishes their work faster than expected, should they help another member finish their task or start a new task from the backlog? Most of the time, it’s sensible to focus on finishing tasks, but that’s not always going to be possible.
To make it easier to find items of interest to you, we’ve created a Topical Index for our blog. Most articles focus on topics to improve the cost performance of software development. There’s a lot of ground there and older articles are just as relevant to the new ones.
All Gitential users are automatically enrolled in our Early Access Program as we upgrade our performance analytics with an AI-powered Digital Assistant. No extra steps or charges are involved. Full implementation, of course, will take some time.
In the interim, if you were interested in improving your daily standup meetings, you may find the following articles useful, too:
Article updated: April 27, 2022
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
Here’s what’s new in our December 2022 Release Notes:
* Developing Improvements for On-Prem Data Processing;
* Improving Jira Data Connection;
* Aligning Metrics throughout the Application.