loader from loading.io
Lowering Developer Onboarding Costs- Episode 34 show art Lowering Developer Onboarding Costs- Episode 34

Programming with Palermo

You can find the code used in this video at  In this episode, Jeffrey shares how to lower developer onboarding costs Situation Custom software is inherently expensive but there are plenty of easy things that your team can do to reduce those costs. I'm going to talk about one of them that aids tremendously when it comes to adding or replacing a developer on your software team. That is the one click build. Mission Anyone overseeing a software team cares about quality, efficiency and productivity. These are important because they translate directly to labor costs. Software teams are already...

info_outline
How to Measure a Software Team- Episode 33 show art How to Measure a Software Team- Episode 33

Programming with Palermo

In this episode, Jeffrey shares how to measure a software team. Situation  Many software team lead architects don't implement management practices that are standard in other parts of the business. Whether it be OKRs (Objective, Key Results), EOS, Scaling Up's Scoreboard, or Kaplan's Balanced Scorecard, business measurement has long been a staple of ensuring that a part of a business was functioning well. But executives overseeing software teams often don't have a tool for measuring the effectiveness of a team or an entire software department. Mission Anyone overseeing a software group of...

info_outline
How an Executive Oversees a Software Team- Episode 32 show art How an Executive Oversees a Software Team- Episode 32

Programming with Palermo

In this episode, Jeffrey shared how an executive oversees a software team Situation Our industry struggles mightily with failed software projects. On average half of the projects still fail. Failure is defined as the executive who authorized the budget wishing he hadn't. The project is so over budget and so over schedule, that the company would be better off having never started it. Even in the middle of these projects, executives can feel powerless to abort it for fear of sunk costs. And without knowing the right questions to ask or the right reports to demand, the executive in charge doesn't...

info_outline
The Architecture of GPT-3 and How to Think About it in 2023- Episode 31 show art The Architecture of GPT-3 and How to Think About it in 2023- Episode 31

Programming with Palermo

In this episode, Jeffrey discusses the architecture of GPT-3, the technology behind ChatGPT, and how you should think about this technology in 2023. Situation- ChatGPT is getting a lot of press because it's the first freely available implementation of GPT-3 that has captured the imagination of the masses. Many are pointing out the awesome and surprising capabilities it has while others are quick to point out when it provides answers that are flat-out wrong, backward, or immoral. Mission- Today I want to raise up the conversation a bit. I want to go beyond the chatbot that has received so...

info_outline
Why is my software team moving so slow?- Episode 30 show art Why is my software team moving so slow?- Episode 30

Programming with Palermo

In this episode, Jeffrey discusses why so many teams are not happy with the pace of software delivery. Situation Most software teams we see are not moving at the pace their companies would like. One of the Clear Measure Way tools is a self-assessment. It's easy to find on the Clear Measure website. One of the subjective questions included is "are you happy with the pace of delivery of your software team?". Most respondents are not able to answer YES. We're going to talk about that. Mission- Many businesses have decided to have internal software development teams. Companies that are tech...

info_outline
Aligning a Software Team For High Performance- Episode 29 show art Aligning a Software Team For High Performance- Episode 29

Programming with Palermo

In this episode, Jeffrey discusses how to align a software team for high performance. Recognizing that the team's architect is the leader and has a big job to do, a tool called the Team Alignment Template facilitates the documenting and teaching of the team's purpose, values, and other strategic decisions so that all engineers can work and pull in the same direction. Situation At the beginning of a project, when a new team is formed, or when the staffing of an existing software team changes, all team members need to align and get going in the same direction. Without intentionally achieving...

info_outline
Designing New Applications for Automated DevOps- Episode 28 show art Designing New Applications for Automated DevOps- Episode 28

Programming with Palermo

In this episode, Jeffrey discusses how to design new applications for automated DevOps. Automating the DevOps process from Day 1 is part of the "Achieving Stability" pillar of the Clear Measure Way. Situation Once a software project or new application gets going, the focus tends to be on features. And once code is being written but not being deployed frequently, the team starts to slow down right from the get-go. It might be tempting to think that you don't need devops automation just yet. But choosing not to put in a particular process is implicitly deciding to put in a manual process. The...

info_outline
Empowering Software Teams Using the Clear Measure Way- Episode 27 show art Empowering Software Teams Using the Clear Measure Way- Episode 27

Programming with Palermo

In this episode, Jeffrey discusses how to empower software teams using the Clear Measure Way. Context For engineering teams serious about delivering software Achieving rare success Resolve to be in the rare 17% of projects that succeed The team rises and falls on leadership Work for clear understanding & wisdom Measure actuals & progress Establish quality Prioritize quality over speed Prevent defects (escaped defects -> process failure) Always working (first do no harm) Achieve stability Minimize undeployed software Prevent production issues Correct production issues quickly ...

info_outline
Engineering Practices for Achieving Stability- Episode 26 show art Engineering Practices for Achieving Stability- Episode 26

Programming with Palermo

In this episode, Jeffrey discusses the suggested engineering practices for achieving stability. After establishing quality, achieving stability is the next pillar in the Clear Measure Way along the path to increasing speed. Without stability, the software team will always be devoting some portion of its capacity to diagnosing and fixing stability issues with the software in production. Priorities Prevent production issues Correct production issues quickly Stability practices Automated deployments formal release candidates low-maintenance environments Runtime automated health checks...

info_outline
Design Patterns Help to Increase Speed- Episode 25 show art Design Patterns Help to Increase Speed- Episode 25

Programming with Palermo

In this episode, Jeffrey discusses using design patterns to increase speed. Speed is a pillar of the Clear Measure Way, just like establishing quality and achieving stability. Elements of a design pattern Problem: a tension or issue in the software. Some trait or condition that is desired to be improved Solution: the way of organizing some code elements to resolve the Problem Benefit: the concrete advantage that code applying the pattern demonstrates Language: higher-level name for code that creates a higher-order concept A design pattern is an idea. Code implementing it is merely an...

info_outline
 
More Episodes

In this episode, Jeffrey shares how to measure a software team.

Situation 

Many software team lead architects don't implement management practices that are standard in other parts of the business. Whether it be OKRs (Objective, Key Results), EOS, Scaling Up's Scoreboard, or Kaplan's Balanced Scorecard, business measurement has long been a staple of ensuring that a part of a business was functioning well. But executives overseeing software teams often don't have a tool for measuring the effectiveness of a team or an entire software department.

Mission

Anyone overseeing a software group of any kind needs a way to measure the effectiveness of that group. Let's zoom down to a single software team and look at what must be measured at a minimum for a single software team. Once the measures are identified, the team can then report them weekly to the appropriate layer of management. And just like every other department, if the measures are aligned with business objectives, then the reports can be relied on to know that the objectives are on track to be accomplished.

Execution

The tool you need in order to measure a software team is a good, old-fashioned scorecard. It's not high-tech. Every business methodology in the last 3 decades has employed some format of the scorecard for the purposes of measurements that are tracked over time and given thresholds of acceptable values. We'll go over the Clear Measure Way scorecard template and how to use it.

Mental Model

From cash flow forecasts to sales pipelines and order shipping, most businesses are used to tracking numbers weekly. Some numbers are tracked monthly, but in software, weekly is better aligned with the normal flow of a software team. You can obtain the Clear Measure Way scorecard template for free from the Clear Measure website. It's a Microsoft Excell worksheet. The first tab is the scorecard itself. The next tab is instructions for how to use the scorecard. It comes prepopulated with the minimum suggested measures for a software team. As you become more comfortable with it, you'll undoubtedly add more measures to it. The researched DORA metrics are part of our minimum, so you'll find those on the scorecard.

At the top of the scorecard template, you'll find a link to a tutorial article that explains how to use the scorecard and how the Excel template is put together.

Each week, you'll have the team populate the numbers in the column that represents the current week. Over time, you'll probably choose to hide the rows in the past so that you can glance at the current week and probably the trailing 12 weeks, thereby getting a good glance as a rolling quarter of performance.

Team Alignment

The measures on the scorecard are divided by the pillars of the Clear Measure Way but are preceded by a Team Alignment section. We suggest that the software team's scorecard include the top-level business measures that are managed by the executive overseeing the team. Without tracking the impact the software team is making in the business, it's easy to become misaligned with business objectives.

If you don't already have these quarterly targets, I'd invite you to use the free Team Alignment Template, also provided by the Clear Measure Way. We have plenty of information about how to align a software team to become effective. Once it's clear what the team is trying to accomplish, add those few measures to the scorecard. If the measures have an acceptable threshold, add that into column F. This will cause the auto highlighting to work, coloring green for numbers within the thresholds and red for numbers outside the threshold.

Establishing quality

The first pillar we suggest you measure is quality. This should be the first priority of any software team. Without it, a team cannot be effective. Without consistently high quality, the team will constantly be circling back to diagnose, analyze, and fix defects. This tends to accumulate, and teams without quality end up having little time left over to actually work on new features or valuable changes.

We recommend a few essentials when it comes to measuring quality. - Defects Caught - Defects Escaped - Defects Repaired - Mean Time to Resolve

Ultimately, you want zero defects to escape into production. But you also want to track the defects caught before production. Think about it, every time to move a card to the left on your work tracking board, that signifies a problem that has to go backward in your process to be corrected. That's a defect. Track it.

Achieving stability

The stability pillar looks at what is happening with software running in a production environment, serving customers. Two of the DORA metrics live here as well as a couple of others. Our goal is to empower our team to deploy changes frequently to production and at any time during the week, all without business disruptions. Additionally, we want to know that the software runs in a way that supports the users, again, without business disruption. Software spends most of its useful life in a state of slow changes but running day to day yielding its return on the investment made in it. The slow changes are mostly changes required so that they can be properly maintained. The measures we recommend for this pillar at a minimum are: - Number of deployments - Major production issues - Minor production issues - MTTR, mean time to recovery

Regardless of the service desk system you use to track production issues, there are always more statuses than you need, so choose which statuses represent a business disruption and which ones do not. There will always be production issues from time to time. The key is to never have a business disruption due to it.

Increasing speed (productivity)

Our last category on the scorecard is for the Speed pillar of the Clear Measure Way. This is where we track the productivity of the team. The throughput of new features and valuable software changes. It is appropriately last because quality and stability must take priority over it if we have any hope of speed that is acceptable to the business.

These measures are very simple and follow the DORA model as well. - Items Delivered - Work in Process (WIP)

Because we are tracking a new value every week, we know the cycle time by comparing the number of items in process and the items delivered. Kanban research has some good findings for thresholds of WIP that tend to work. My favorite is to start with a value equal to the number of members of the software team. This allows each team member to be working on one item at a time. Then, as you are confident, you can increase this threshold as you verify that the items delivered each week are increasing and not decreasing.

When it comes to measuring the throughput or speed of your software team, those two are typically sufficient. But as you go along, your team may want to measure additional items if you find them valuable.

Mechanics of measurement

One often cited reason for software teams not reporting up to executives with a scorecard is the administrative time it takes to compile the numbers, put together the report and answer questions that invariably come back down. But any department in any business could give those same reasons.

Forty years ago, Fred Brooks wrote an essay in his Mythical Man-Month book called "The Surgical Team". In this essay, he lays out a framework for the ideal software team structure. Effective large teams end up with a network made up of many of these team units. Large teams typically aren't effective without subdivision into a structure similar to Mr. Brooks's structure. This is probably where the notion of "Feature Teams" came from, but I digress. In this essay, Mr. Brooks discusses a team secretary. This role is responsible for all the recordkeeping, logistics, and outside communication for the team, much like what is necessary for a surgical team in an operating room. Surgeons need to stay focused on the patient, so there is a need for someone to enable them to do just that.

Each team should have a non-engineer responsible for administrative excellence for the team. Without this role, we frequently see teams that underperform not because of a lack of engineering prowess, but because of completely non-technical administrative misses. In short, managing a scorecard is an administrative task, so it should be done by someone strong in that area, even if an engineer is asked for a particular number.

Conclusion

To conclude, every effective software team needs a scorecard. The scorecard is the basis for a periodic report to a company's executive team. It answers so many questions, such as "how much can my team deliver". Without a scorecard, all we know is how many hours the team works. It doesn't do a company much good to have a team that works 100-hour weeks if the production system is brittle and new changes take months to implement. A scorecard tells us how our team is doing now, and it tracks our progress as we implement the principles and practices in the Clear Measure Way on our journey to a fully effective and high-performing software team.

Thanks to Clear Measure for sponsoring this sample and episode of Programming with Palermo.

This program is syndicated on many channels. To send a question or comment to the show, email [email protected]. We’d love to hear from you.

To use the private and confidential Chaplain service, use the following
Gentleman: 512-619-6950
Lady: 512-923-8178