Staying abreast of the latest updates to tickets and code shouldn't be hard.
Yet, over my decades as a Software Manager, simply providing status updates that to depict the team's progress was the most value-adding chore I would undertake for the stakeholders on my team. I would go into meetings and talk about what we were doing to deliver code in the current sprint, leading up to the bigger release. I would pull up dashboards and spreadsheets pulling data from JIRA or Azure DevOps, offering commentary to create a shared awareness of our velocity and remaining to-dos.
This would bring a level of comfort to those around the table (primarily other Product Managers, Stakeholders, Sales, and Support team) because they could see their goals being manifested in the reports I produced. They wanted a visual to see how the work we had committed to was becoming the work that got done. Days when the charts were green it was great. When progress sagged, these progress reports created the perfect starting point for a conversation on how to adapt.
Always during these meetings, there were side glances between the other Software Managers who wanted to go deeper. The questions they posed often became follow-up action items for additional rounds of research:
“Where is that work being done?”
“Have they checked in with Jeff on that?”
“Why are they in there?”
Every Software Manager knows the code is the true metric of delivery. But translating from our high-level ticket roadmap down to these granular questions about "what code is being delivered?" was no simple feat.
GitClear's window into how much progress is happening across different types of tickets
linkFighting The Drift
If you're an Engineering Manager or a VP of Engineering, how many times have you been asked questions like...
“Are they working out of this branch?"
"Are they in this service?”
"Did they avoid use of that deprecated library?"
... only to give the wrong answer, because you aren't checking over your team’s shoulder every minute of every day? And so you check in with the developer (interrupting their flow state), only to discover they were indeed utilizing the wrong service, wrong implementation, or a changed design.
This is "The Drift." When ticket progress tells one story 🟢 but deeper inspection of the code being authored tells another 🔴. The Drift happens from both exotic and mundane causes:
Requirements change late in the process
Concepts missed by design are realized
Limitations are found in the libraries that need to be used
Performance roadblocks are encountered
Change of developer midway through the development
On projects without access to GitClear, The Drift continues to frustrate me. I need to ensure that I’m providing an accurate view about what we are delivering and where we are delivering it -- but the cost of interrupting developers is a steep price to pay when their typical response on Slack is about as informative as a 200 OK.
Instead of adding a distraction to the developer's day, these days I prefer to use the Commit Activity Browser:
Hovering on work in the GitClear demo repo shows the truth about progress, eliminating the potential for Drift
Apart from the spectacular visualizations to show who is carrying forward each of our active tickets, I can see changes to code as they happen -- either on GitClear, or from the customer's dashboards via GitClear's Chart Glimpses. This lets me instantly reconcile "the truth told by the code" with "the truth about what stakeholders currently need."
link“Why are they in there when we are now focused on this other story?”
This is information I often need to understand, but I want to understand it without pestering my team and disrupting developers progress unless it's absolutely necessary.
Thankfully, the Directory Browser can pinpoint the domain in which a particular Developer has been working over the past couple weeks:
No more guessing about which directories a developer has been working in, or how much time they have been spending in those directories
What I enjoy about GitClear is the value it provides me as a Software Manager by being able to speak with confidence as to where changes are being made and what work is tracking against deliverables. Also, it allows other managers to be able to have that view so as we work together to build code as multiple teams it reduces confusion and questions that might cause concern too late in the development process when “the code has to be released”.
Your tickets will always be trying to tell a story, but combining the tools shown above will tell you the truth about what's happening on your team.