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
Which software development metrics should be improved to boost your team’s performance the most? Cycle Time is the top metric to improve, but it is a composite of all other software development metrics including Velocity, Efficiency, and Utilization. These, in turn, are driven by developer skill and task complexity. How teams are organized also factors heavily into efficiency. It’s very difficult to find where one “factor” doesn’t strongly influence other factors. It’s all interconnected. Aum. Ha.
Borg is coming.
Cycle Time is the ultimate software development metric to improve, but it’s essentially the product of most other metrics combined. Improving almost any other metric, while maintaining the same standard of quality, will register a decrease in cycle time. Cycle Time measures how long it takes to complete a unit of work – a story point. Improving cycle time improves Lead Time and Takt Time, so it’s the one to focus on. It is your “eye in the sky” metric for how your team is improving, and probably the one that C-levels understand the most.
In Project Visibility, the severity and scope of problems in software development helps diagnose whether the “problem” is a management or developer issue. There, we highlighted what software engineering managers need to do and steps to take to correct (most) management issues.
Three Software Development Metrics to Prevent Escaped Defects, showed that when management issues were not the root cause of a problem, developer skill often was. Absent ambiguous task requirements (and startup/rapid team expansion scenarios), developer skill is a major source for excessive code complexity, code churn, and a lack of test coverage.
Developer skill and software development metrics are closely associated. If not owing to ambiguous tasks and bad hair days, developer skill and experience is mostly responsible for code churn, code complexity, and test coverage. We’ve addressed ambiguous tasks. We can’t require all developers to shave their heads. So, that leaves us with improving developer skills.
Herein, we can’t just measure a new developer’s velocity or lines of code without also considering their code’s complexity and testability. And, we can’t fault code churn if it means they are reducing its complexity and increasing its testability.
A junior developer may take a full day to do what a senior developer can do in an hour. That’s normal, natural, and common across most professions. The question for software engineering managers is how do you accelerate a developer’s development?
We’ve covered most of these at some length on the blog, but two deserve more attention.
Warren Buffett mentored Bill Gates; Bill Campbell mentored Steve Jobs, Jeff Bezos, and Larry Page. Nothing is more educational than time spent with a master of the craft. Alas, that time also comes at a premium. Many companies may not be able to afford a high ratio of senior to mid-level and junior developers.
Senior developers almost always have a lot on their plate, so it’s important to balance their load.
Concurrently, all developers are not equally disposed to social engagement, even in a training context. Others… like to show off what they can do. Leastwise, it’s worth getting to know your most experienced team members, their style and preferences. Then, develop a mentoring program to maximize their impact on team development relative to workload.
Though mentoring is at its best on a one to one basis, there’d be very few high school or college graduates if not for teachers with classes of 20-30+.
Odds are that the code your developer’s need to write has already been written – as there are millions of open source projects on GitHub alone. This isn’t meant to encourage plagiarism or copy-paste coding, suffice that there are plenty of examples junior developers can reference to help inform their logic and coding structure.
A small upfront investment by experienced team members can have a huge return on improving your team’s software development metrics. Identify and reference Open Source projects similar to your project requirements to junior developers. Draw attention to the logic, sequence, use of comments, number of parameters, nesting of elements, and naming of variables it uses.
A lot of learning comes from seeing how the task is done, and then doing it yourself, over and over again. If nothing else, this should help reduce code complexity and code churn while increasing test coverage, velocity, and efficiency. Depending on the nature of your team’s projects, it may also promote code reusability. If so, keep that code top-center in your list of library links.
As utilization increases, a lot of other metrics degrade (more code churn, lower velocity). That’s especially the case when developers are dividing their attention across different projects. Excessive utilization can lead to burnout – and we want to avoid that for all developers. Burnout is most likely to impact mid-to-senior developers as more tasks fall to them.
So, this brings us back to story points and dividing tasks into small, meaningful, and logical tasks. Can high-story point tasks be logically divided into smaller, simpler tasks? In a lot of cases, yes. This warrants a look at the Story Splitting Flowchart. Yeah, it’s a little scary to look at, but if you can master story splitting – you’ve won half /“a big part” of every war you’ll ever fight in software development.
By splitting stories, you’re reducing task complexity making it easier to find examples, reducing code complexity and several other software development metrics. This, in turn, will impact your cycle time like… a six pack of Red Bull while you’re listening to Metallica’s “For Whom the Bell Tolls.” Cycle Time Marches On!
Sorry, I got a little carried away there…
At the same time, you’re reducing the load on your more experienced developers. But, as we’ve suggested previously, this may require senior developers to work more closely with Scrum Masters to breakdown and better define the tasks when adding them into Jira (or other PMS).
Velocity plays an important part in cycle time. Finishing tasks (story points) faster is the objective of velocity. Writing more code faster is not. Complex code often infers “more code.” Code is read more than it is written, so excessive code complexity suppresses all software development metrics.
Writing simpler code isn’t always faster than writing complex code. It takes some thought to create efficient code. Having less complex tasks coupled with your curated related OpenSource examples showing good structure, logic and sequence to follow makes it easier to write less complex code. Less complex code is easier and faster for everyone to read – and debug.
You already know at least part of what I’m going to say about improving efficiency. Yes, increasing coding skills with mentoring, providing useful examples, breaking complex tasks into smaller tasks will reduce code complexity and lead to an increase in efficiency. But, there’s a lot more to the picture in terms of improving efficiency than coding factors.
Team size has a direct impact on efficiency. The Ringelmann Effect and Metcalfe’s Law help to explain why. The impact of team size is so pronounced that even the military is organized around efficient team sizes.
Functionally speaking, the larger team the less productive each team member becomes. That’s the Ringelmann Effect. The drop in productivity comes from administrative overhead, complexity of communications, slack, and other effects. Here’s what the Ringelmann Effect looks like:
The average software development team has seven team members. For this, the Ringelmann Effect predicts a productivity rate that’s just 57.1% of its potential.
An often cited study by Stripe indicating software developer inefficiency averages ~ 31.6%. That’s good news, but it should be expected as conscientious software engineering managers actively engaged with DevOps are beating the norm by 11.3%. But, 31.6% is still a lot of waste.
Metcalfe’s Law uses the formula n(n-1) / 2 to measure the inherent complexity associated with the number of possible communications channels. This doesn’t assert that every team member will need to communicate with every other team member. But it does mean that self-organizing teams will spend a lot more time self-organizing the larger they get.. for starters.
| # of Team Members | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 11 | 13 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Team on project | 1 | 3 | 6 | 10 | 15 | 21 | 28 | 36 | 55 | 78 | 105 |
Team size introduces complexity that cascades into everything your team does, including the systems it designs and develops (see Conway’s Law).
If the Ringelmann Effect is so important, why should you increase the size of your teams?
This equates to DevOps for software development teams. It implies that each software development manager should be assisted by a DevOps specialist. Fortunately, the DevOps specialist doesn’t have a lot of gear to lug around and so can handle both tasks. DevOps can automate processes while targeting code and software performance issues for developers. Every team should be pushing toward Continuous Implementation → Continuous Delivery → Continuous Deployment.
Every project has many variables, there’s no one size-fits-all. For many companies, it may be budget. For others, availability of specific programming language expertise. Maximum effective team-size will always come down to software engineering manager skill and experience.
If we want to organize around efficient teams, we’re looking at something like:
This won’t work for every project, but it’s a good foundation that can be customized. Leastwise, if you’re involved in planning for a startup up, or scaling up a startup, this can be a very useful template for planning purposes. A Scrum Master is not included in this org chart, but only one should be needed for 3-4 feature teams. The more cross-functional your team members, the more efficient it will be, too.
This format is predicated upon the military’s Rule of Thirds. This advocated having one senior developer for every 3-4 mid-level developers and similarly, one mid-level developer for every 3-4 junior developers. This ratio ties nicely into mentoring and training programs and is also a key component of long-term retention planning.
