As more teams in my part of the organization have embraced using feature flags, we’re clearly generating some significant technical debt based on the number of pages of flags in the Azure portal. One of the developers generated a report for me and we have an alarming number of enabled flags that are older than 90 days. I need to get a handle on this!

Here are some quick first steps I know I need to take.

Step 1: Retire Old Flags

I need to generate some tech debt tickets for the team to start extracting old flags that haven’t changed state in some length of time. I will start with flags that are 90 days older and work my way forward.

Step 2: Get Consensus on Naming Conventions

As more teams are taking advantage of the feature flags, it is clear that the teams are calling the flags whatever makes sense in the moment for them. I need to establish some best practices for names and descriptions before things get out of hand and somebody deletes a flag another team was using.

Step 3: Create a Process to Review Feature Flags

While the development teams will do most of the work of creating and deleting feature flags, we have had laid offs and reorganization events in the past. If we can establish some kind of feature flag governance process, we can successfully manage the flags even when teams get reshuffled or dissolved.

This could be a good use case for using some kind of AI agent. The agent could review the feature flags at some interval, generate a report for leadership, spawn tech debt tickets for associated teams, etc.

I’ll keep pushing forward on this and create a future post regarding my progress. Stay tuned!

I’ve occasionally given away Amazon gift cards, but I try to make the prize something tangible. Gift cards are nice, but an actual item is better. I’ve given out fidget toys, popcorn tins, desk pads, and more. Once, for the holidays, I filled shipping tubes with pens, candy canes, and other smaller items.

In my quest to provide compelling prizes to my team members, I discovered a new opportunity. In my hometown, the local library was moved to a new and modernized location. One of the new features of the library is a makerspace featuring 3D printers, laser cutters, and other equipment. I went in to tour the space and learned that, if you provide the plastic, you can 3D print for free!

Soon, I was digging into websites like Printables.com. I found a candy dispenser that accepts a standard Mason jar and has an auger to pull candy into a small tray. I scheduled time at the library and printed all the pieces, test-fitted them together, and then shipped it to one of my team members. They loved it!

So, my suggestion to you is this: if you want a special, unique prize to give away to a team member, consider locating a makerspace near you, download a free print file from a reputable website, buy the appropriate roll of filament online, and print something your team will love! If there isn’t a makerspace near you, you might be able to locate someone in your area that can help. There are also services that will print items for you and ship the item to you for a cost.

In fact, I bet you could use a site like Fiverr to find someone to edit a design to add someone’s name or a company logo for a truly unique gift!

Go forth and print!

switch (variable) {
    case 1:
        // Some code here
        break;
    case 2:
        // Some code here
        break;
    default:
        // Some code here
        break;
}

I’ve almost always used break statements between the cases. This is because I typically use a switch to replace multiple IF statements.

When building apps (like Android apps in the following example), there are some common use cases like:

1. First time install of version 1 (create only; no update)

2. Fresh install of version 2 or update version 1 to version 2

3. Update from some older version to the current version (more than one version behind)

The way Android handled this back when I made my first app was clever to me. It was the first time I used a switch without breaks that I could recall. Please see a short example below:

@Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {

        switch(oldVersion)
        {
            case 1:
                db.execSQL(ADD_NEW_RECORDS);
            case 2:
                db.execSQL(CREATE_NEW_TABLE);
                db.execSQL(CREATE_ANOTHER_NEW_TABLE);
            case 3:
                db.execSQL(ALTER_TABLE);
                break;
            default:
                //log no update applied
        }
    }

The way this code works is like so:

We know it is an upgrade because Android is calling the onUpgrade method. If the old database version is “1” (which corresponds to the first release), this app is behind a couple of versions. The switch matches on “1” and executes the SQL in the constant variable to add some values to a table. Since the first case doesn’t have a break statement, it drops through and creates some new tables, and then finally alters the schema of another table.

If the app was already on version 4 of the database during an update (which happened when the update was a code-only update), the switch skips the database changes.

While I found this use case with a switch interesting, I imagine there are better ways to apply conditional transformations to a system, but this way is straightforward and easy to understand as long as there aren’t too many to manage.

To be fair, I’m sure all the issues I’m going to list are due to poorly executed pipeline design and implementation. That’s the real point of this post; be intentional with your pipelines.

First, let me share how our pipeline was setup. I’m not an Azure DevOps engineer, so this will likely be awkwardly worded. Our pipelines were YAML-based and the environment destinations were arranged in a linear fashion: DEV to QA, QA to UAT, UAT to PROD. We had roles setup so only the QAs and Release Managers could move code to QA, UAT, and PROD. Our code was arranged in a microservice architecture of sorts, so we actually had several pipelines to run to deploy the entire service. Some of our pipelines were configured to detect if we’re trying to deploy code that is the same or older and block the deployment. This will matter later.

The first issue we had using Postman with our pipelines was when a Postman test glitched or failed for a transitive reason. We were organized enough that our tests were split into basically two large groups: smoke tests and functional tests. We set the pipeline to point to the appropriate smoke test collection in Postman, but some of the tests included response time checks. We dabbled in having performance tests that failed if the API took longer than 2 seconds to respond. For a variety of reasons, sometimes our service would spin up in QA or UAT, the pipeline would then run Postman smoke tests, and a response took 2.1 seconds to respond, the test would fail, the pipeline step would fail, and now our pipeline was in a bad state. We setup rolling deployments across six instances, so it was taking a good 20 minutes to deploy. Re-running the entire deployment step to clear a Postman error was absolutely silly.

Remember that version check? Sometimes we had to delete an app from Service Fabric so we could re-run a deployment step quickly or we had to start over and push a new version (because the developer didn’t have access to Service Fabric). It was not a great developer experience.

My Suggestions

I’m going to try to generalize my thoughts so that these aren’t just Postman related.

1. Separate Test Collections for Pipelines
   I want the QAs to be able to write tests with impunity. However, to avoid affecting pipeline execution, consider having a separate set of tests dedicated to pipelines. Changes or additions to those tests should be discussed with the development team as a whole and serve the deployment process.

2. Make Sure Smoke Tests Are Smoke Tests
   One of the issues I noticed often with our smoke tests is that they were looking more and more like functional or integration tests. Review your smoke test collection to make sure they’re not more than needed.

3. Pipeline Warnings
   It is possible to have integrated smoke tests or functional tests fail with a warning instead of an error. This will take some thought, though, and might cause more harm than help. You don’t want to condition the team to ignore warnings. If your tests generally pass, your team has good discipline, and/or there is value in not blocking a deployment step, this is an option.

4. Make Pipeline Steps Rerunnable
   In my experience so far, I’ve seen perfectly good code that needed to be redeployed and it was blocked by pipeline validation. Being able to re-run steps (especially non-PROD steps) is wise.

5. Consider Non-Linear Pipelines
   This suggestion likely depends on your branching strategy, number of environments, or other code handling practices. I prefer pipelines that allow code to be pushed to whichever environment is needed. We’ve had issues in the past where we had to hotfix a release during a release window and had to wait for the code to deploy to DEV, QA, UAT to finally get to PROD.

I’m not a CI/CD or QA expert, but I believe these are some reasonable suggestions. I’d loved to hear more suggestions. Feel free to comment.

Cheers!

The AI hype is so strong that a company called Nate got busted for lying to investors. The company had led investors to think that the company was using cutting-edge AI when, in fact, the company was using remote workers to do tasks. I suspect they were trying to cash in on the AI wave with remote workers with a “we’ll fix it later” attitude.

I read a crazy story a few months back regarding a brothel that was supposedly using AI. The article attempted to coin a new term: “analog AI”. As it turns out, this “analog AI” was just a person talking on a headset to interact with “clients” while the clients “interacted” with “equipment”. I found the term “analog AI” almost offensive!

The hype is so strong with AI and LLMs that I’ve intentionally stepped back to be a late adopter. I poke a stick at it every so often. My non-techie wife uses AI more than I do at this point. I’m going to let the dust settle a bit and see what comes out of all this.

In the book “Essential Scrum” by Kenneth Rubin, user stories are defined like this:

“User stories are a convenient format for expressing the desired business value for many types of product backlog items, especially features. User stories are crafted in a way that make them understandable to both business people and technical people. They are structurally simple and provide a great placeholder for a conversation. Additionally, they can be written at various levels of granularity and are easy to progressively refine.”

However, much to my surprise actually, the author doesn’t presume that user stories are the only way. He goes on to say, “If I find that user stories are a forced fit for a particular situation (such as representing certain defects), I’ll use another approach.” I’m glad to learn this because I’m in the very situation right now. Part of the current project I’m overseeing includes merging two applications into one user experience. Some of the changes are going to be back-end changes that provide the existing user experience with a new API. Having a story like, “As a user I want some button to work like it always has with a new API endpoint” kind of works but also seems a little silly.

One of the challenges I have with managing sprint work is having front-end and back-end engineers. When you use a user story, there usually isn’t a distinction between front-end work and back-end work. But for some tickets, the front-end work might be light and the back-end might be heavy. The systems I’ve worked with only allow one person to be assigned the user story. When you point it, do you point the front-end and the back-end and take the highest number? Add the story points together? If you don’t split the front-end user stories from the back-end user stories, how can you know your true capacity? If I have two back-end developers and two front-end developers and the highest value work happens to be back-end heavy, do I just have idle front-end developers? I’ve also had teams complain that the front-end can’t really finish their work until the back-end dev is done. Some of us suggested having the back-end done first in one sprint and then have the front-end work done in the next sprint (requiring split tickets), but that was shot down. When I run into situations like that, I feel like agile zealotry get in the way more than helps.

Regarding the front-end development versus back-end development, there is such as thing as a “full stack” developer, but don’t kid yourself. I’ve interviewed dozens of full stack developers. They are always stronger with some disciplines and weaker on others. Giving one dev both front-end and back-end works nicely from a ticket perspective, but there’s a natural fault line where two developers could work at the same time without stepping on each other that can be lost.

Stay tuned for more exciting adventures as I push through this reading. Cheers!

I’m in chapter 5 today which is titled “Requirements and User Stories”. This should be an interesting read. Everyone I’ve ever worked with has “done agile” at one point or another, but we have such a wide range of preferences and biases. Reading this book is a bit of a challenge because I feel like I know how to “do agile” already. But, I’m curious if my understanding aligns with the book. I’m sure there is still more for me to learn.

I’ll likely send more postcards about my agile adventures. For now, I want to share one of my favorite sayings. There’s an example in this book related to the futility of trying to gather requirements upfront in the form of a mock conversation. It goes like this (from page 80):

Customer: “Now that I see these built features, I realize I need this other feature that isn’t in the requirements document.”
Developers: “If you wanted that feature, why didn’t you specify it up front?”
Customer: “Well, I didn’t realize I needed that feature until I saw the product coming together.”
Developers: “Well, if you had thought longer and harder about the requirements up front, you would have found that feature then instead of now.”

I had to chuckle at this mock exchange because this is a conversation that can happen in many industries, not just software development. In my web development days, we provided graphical mock ups and test URLs as we built out websites so our customers could experience the product and provide feedback before we did too much work. This led me to one of my top 10 most repeated sayings. I often say, “Customers don’t know what they want, but they know what they don’t like.”

It is just part of the human experience. We can discuss the kitchen remodel, the website design, the paint color for the nursery, etc. for days. But, it is not until you get to experience some part of the decision with more of your senses that you can confirm if you actually like it. And, once you have a chance to sense the outcome, you find inspiration (or be disappointed).

It is a wise practice to give people a chance to experience their decision before too much work is done.

This reminded me of a former mentor that used the word “intentional” often. She would say, “Let’s be intentional about <insert effort here>.”

With a reorganization event going on at my company, some of the newly formed agile teams are going back to using sprint objectives in attempt to generate collective focus for the forming teams. (Previous teams often didn’t need a formal objective; they knew what they were working on and why.)

Around the same time, I happened to have a regular meeting with HR. We were discussing the company reorganization effort. We noticed a theme among the challenges and, half joking, we settled on a “word of the week”. (I don’t recall the word, sorry!)

A word (or phrase) of the week/month/quarter could be a useful tool to rally your team around. Some phrases or words could be:

• “Flexibility”

• “Focus”

• “Quality First”

As a leader, you can start and end your meetings with a reminder of your word or phrase of the week to guide the team on what they should be focusing on for the given time period.

I’m going to give this idea a shot this week. The re-org has been quite the challenge for my new team. Now, I just need to figure out what word or phrase to choose…

Cheers!

Link to Book (Amazon):

Transformed: Moving to the Product Operating Model https://a.co/d/0sAL8fn

Be Specific

I believe it is a much more meaningful performance review when you can document specific actions a team member took and the consequences of those actions. This can be done for both positive and negative actions. If the team member completed a major feature, fixed an urgent production issue, or similar, document that action along with how it helped the organization. Likewise, if the team member caused a production incident that caused non-trivial harm, document that, as well. The statements should be as objectively true as possible. Don’t oversell the impact (good or bad). Ideally, everything you include in the performance review is agreed upon by you and the team member.

Take Notes Over Time

At my company, we do performance reviews twice a year. At some companies, the annual review is supposed to be a review for the entire year, not just the last six months from the mid-year review. If your company operates like that, it is imperative that you keep notes over the course of the year so you can complete an accurate annual review. If a team member starts the year well and then struggles at the end, their annual review shouldn’t be completely focused on the last few weeks or months where they struggled. Likewise, if they struggled earlier in the year and are doing very well now, the annual review should reflect that reality.

Write Before Reading

Many companies have a practice that involves the manager and the team member writing reviews from their perspectives and then sharing. I prefer to write my review before I read the team member’s review. This gives me a chance to get my thoughts, perceptions, and biases down before I take in the team member’s thoughts, perceptions, and biases. I usually take it as a good sign when my review and my team member’s review hit the same topics. If the team member focused on something completely different than I did, I take time to reflect on that and what that could mean. I also discuss it with the team member during the review.

Do the Performance Review With Your Draft

This tip can be somewhat system dependent. I’ve used HR systems that encourage you to share your review with the team member, but once it is shared, it is hard to edit again. One system I worked with required HR to unlock the review for editing.

I prefer to share the draft of my performance review with the team member. If they disagree with something I wrote, we can discuss and I have the option to clarify my writing. During my last set of reviews, I ended up editing a review during the review meeting. I had written something about the team member making their teammates laugh with “snarky” comments. As soon as I shared this part of the review, I didn’t like how it sounded and was afraid it could be misunderstood. Sharing my draft allowed me to edit the content during the review.

After the review is discussed and up to date, I then lock it down, share it, and request their electronic acknowledgement.

No Surprises

When it comes to review time, the review shouldn’t contain any surprises for the team member. I have regular one-on-one meetings and ad hoc meetings with my team members all year. If someone is not meeting expectations, I notify them right away and set clear expectations with them. While “good” surprises might be nice, that’s not usually the issue. The issues I hear about are revolve around negative feedback being provided in a performance review that the team member didn’t know was coming. This can be incredibly damaging to the rapport you have with a team member and can destroy any trust and credibility you had. If your team members are close to each other, news of surprise negative feedback could spread around the team, eroding your rapport with your entire team.

Consider Accommodations For Delivery

Some people find performance reviews incredibly intimidating. This might be due to past experiences with other leaders, how they process information, or their mental health. For example, I had one team member ask me if they could read their review prior to meeting so they could digest it and work through some of their emotions before meeting with me face to face.

Even if you have nothing but nice things to say or you believe you’re a great, unthreatening communicator, remember that it is the process itself that is scary. It would be wise to ask your team members if they have any requests related to how the performance review is executed. Do your best to help them through the process in a way that preserves and builds your relationship with them.

Do you have any tips you’d like to share? I’d love to hear about them.

Cheers!

The parent told me that her company was unexpectedly invoiced by a staffing agency. When they reached out to the staffing agency about the invoice, they learned that the staffing agency had some kind of "AI-powered" solution running that noticed a person (that they had done staffing with before) took a job at a company (that they had done staffing with before) ON LINKEDIN and AUTOMATICALLY cut an invoice to said company.

It is utter insanity. To send an invoice to a company there should be a documented ask. There should be a documented delivery of goods or services rendered that isn't based on scraping LinkedIn or other 3rd-party platforms. In this case, the person found the job on their own; the staffing agency wasn't involved. Yet, they requested payment anyway.

Assuming the details of this story are correct, I am dying to know how many clients of this staffing agency paid these types of invoices without evening questioning it. Assuming this was a bug, when they learned that their "AI solution" was invoicing incorrectly, did they fix it? How much money did they make off this process? How much will they lose when they get caught?

The PrintExpert Server Fiasco

When I worked at WoodmenLife, we had a software product called PrintExpert deployed to a virtual machine running an older version of Windows server. The platform was fairly complex. There were the vendor's product and utilities. There were also applications that were custom built for our purposes. One of the side affects of this setup was leftover working files. The platform would run a batch of print jobs for insurance certificates and letters. Data would get merged into templates and written to disk. One set of temporary processing files had a specific naming convention. It was something like XXX0123.tmp (I don't recall exactly). The way the software worked is it looked at the filesystem, found the tmp files, parsed the name of the most recent one, and added 1 to it. That number was then used to create the next file (like XXX0124.tmp).

One day, we ran into an issue with running the batch. Some part of the platform crashed and processing stopped. After some debugging, we figured out that the code that writes those *.tmp files had hit the top of the number (like XXX9999.tmp) and threw an exception when it could increment to a new number. Why didn't it rollover back to 1? Why didn't it use a longer number? No idea. The fix that was implemented was a simple batch script or VBS script that cleaned up the files. It was scheduled to run on an interval using the Windows Task Scheduler.

After many moons of the platform doing its job, it was time to upgrade the servers. Our technical services department had a policy that they didn't do in-place Windows upgrades. They created a generic Windows server image in VMWare and deployed new servers for us. The team didn't have perfect documentation, so it was a bit of a struggle to deploy all the tools, update all the configs, wire up the databases, etc.

After all the servers were setup and everything tested, we cut over to the new servers and everything was fine for many moons. Then, we had a batch failure. After relearning some of the lessons of the past, we rediscovered that we had filled the temp folder with *.tmp files and caused a crash. We found the old script file and rescheduled it.

This incident planted the seed that spouted in my next project.

My New Platform Cleans Up

One of my proudest accomplishments is a platform I built single-handedly called Document Conversion Service. The platform had a singular purpose. The workflow management solution we implemented was setup to show digital documents to users as single-page TIFF files. The DCS platform accepted PDF, Word, and other document types and converted them programmatically to single-page TIFF files. The TIFF files would then get picked up and inserted into the digital document storage solution.

I designed the system to only use the file system for managing state. It would receive a file through a web API and write the file to an inbox folder. The software that did the actual conversion was CPU-intensive and needed to be a long running process, so I created a Windows service to process the documents. The Windows service would write the converted pages to an outbox folder that was shared on the network. I used a trigger file to indicate to the client that conversion was done. I can't remember if the DCS clients couldn't delete files from the outbox or just didn't delete files from the outbox. Either way, those files would need to be cleaned up at some point.

Recalling the issue with the print platform and the scheduled script, I decided to add another .NET Task to the Windows service to check the outbox folder and remove files that were older than some number of days. The number of days was configurable. The great thing about this solution is that when the DCS platform gets deployed to a new server, there are no extra steps for clean up. Cleaning up the working folders is a primary feature of the platform.

Not Just for Files

I highly recommend adopting the practice of having your code clean up after itself. This can apply to files, folders, logs, database records, dead letters, and more. If your code receives or makes digital artifacts, take a moment to consider how the system may look after running for years. Having clean code that cleans up after itself can mean a more resilient and maintainable system that can run indefinitely.

Cheers!

One thing I noticed for the repositories at my organization, there was a loose relationship between how many people maintained the repo versus the quality of the git messages. That makes sense: if you're the only maintainer on a project, it can seem like you're talking to yourself. Why write an elaborate git message for yourself?

When maintaining a code repo by yourself, being disciplined about how you commit code is not only helpful for your future work with a team, it can help your future self not have to think so hard. Consider scenarios where you may need to look at your previous commit messages or pull requests and help yourself remember key details and make good decisions quickly.

So, how does one know if they're good at managing source code? I did a bit of searching online and one of the articles I looked at referenced how git is used with the Linux kernel. The post is very long, but it is full of interesting conventions for the people that maintain the Linux kernel. Surely, the person that created git has the best practices for using git all figured out!

The kernel.org post does have interesting conventions in it, but some of them likely won't make sense for a repo controlled privately by a single company. For example, the post indicates (at line 102) that when submitting a pull request to a maintainer, be sure to be clear about what problem you are solving, not just what you changed. Based on this direction, we can tell that git is used for much more than just managing code at kernel.org. A Linux subsystem maintainer may get pull requests from people they don't know for fixes or features they didn't ask for.

If you're working at a company and submitting a pull request to an internal repo, you've likely been told what the problem is by a product owner, scrum master, lead developer, or manager. You don't need to convince anyone that this pull request is needed; they're likely expecting it.

If your pull request is expected, there is likely a ticketing system of some kind being used. So, you could just reference a ticket number with your commits and/or pull request. Referencing a ticket number isn't a bad idea, but ONLY referencing a ticket number could be. Unless your source control and ticket system are well-integrated, you can end up with a list of commits that are just numbers. Not very useful when you're looking back through changes.

Is there a standard way to do source control? Yes, but only if YOU make one. Consider your team's size, your team's roles, your team's work methodology, the branching strategy used, the tooling your team has access to, etc. Based on all these variables, what makes sense for your team?

It would be an excellent idea to meet with your team, iron out the details, and then document the standard on a wiki or shared document. Then, when the next developer joins the team, they can learn the standard immediately and not disrupt the team's code handling processes. Your manager should thank you for it!

I am the proud owner of a Honda Odyssey. It's a good minivan for my large family. The van hit 100K miles, so I called my preferred Honda dealership for their 100K miles service package. The service manager informed me that they were impacted by the recent CDK issues. They could not schedule any service for my car and asked that I call back in a few weeks. WEEKS...

The Register has a write up on what happened here. Basically, CDK is a company that provides nearly 15,000 automobile dealerships in America with all the software needed to run their businesses. After some kind of "incident", CDK software has gone down and impacted dealerships have had to scramble.

The dealership I typically work with was obviously wholly unprepared for such an outage. They had no records of me or my vehicle in another format. They seemingly could not estimate repairs, prepare invoices, or take payments. They might have even had issues with paying their bills and ordering parts.

I called another Honda dealership in town. I asked them if they were impacted by the CDK issues and if they were able to do repairs. The woman on the phone acknowledged that they were also impacted by the outage, but it was fine. She took my name, number, and vehicle details. I even received a text message confirming my appointment. I imagine (whether it was by luck or design) they must have had some of their business process "eggs" in non-CDK baskets.

For any business that is all in on AWS, Azure, Microsoft Dynamics, Salesforce, or some other cloud offering or SaaS product, all these ransomware attacks, cyber "incidents", cloud outages in the news should give business leaders pause. Do you have a plan for when the unthinkable happens?

My impression is that the majority of business do not have a plan for serious business interruptions. It probably varies by sector and company size. Highly-regulated companies are perhaps required to have such a plan in place.

In my experience, I've only worked at one company that took business resumption seriously and that was WoodmenLife, a life insurance and annuity company. They had events every year to test their ability to restore systems and resume business when bad things happen.

If you're in any kind of position of leadership and your team, your department, and/or your organization doesn't have a TESTED plan for continuing business when systems go down... Well, good luck, I guess. It might only be a matter of time before you and your team are faced with an existential crisis.

The study seems to have been done by surveying 600 software engineers in the UK and the US. The blog post didn't mention how many companies were covered by the survey. The Register's post was quick to point out that the EngPrax post seemed a little bit like a marketing post to boost a new methodology called "Impact Engineering". I'll include the link anyway for completeness. Out of curiosity, I searched for "number of software engineers in the us" and a result from Wikipedia indicated there are over 4 million. The survey group is so small that I cannot believe any numbers coming out of this study are representative of the whole.

The interesting part about the survey is that there seems to be supposition that projects failing is a bad thing that needs to be avoided. I couldn't help but wonder if the agile methodology was actually working as designed.

I've worked at a number of larger organizations. I've been on projects that should have failed. Those projects were driven onward at a high cost of money and morale. A person (a VP or C-suite person) was usually attached to the project and their reputation was at stake. They authorized the project and just kept pushing no matter what changed or what new challenges came up. For them, project failure might equal a career setback.

On the idealized agile side, you're trying to deliver value to the business quickly. It is true that many people believe that agile means "start work with no plan". I believe more people (myself included) don't equate "agile" to "no planning". Agile, in my opinion, has room for as much documentation at the project dictates. An insurance application, for example, has many regulatory requirements and extensive documentation may be needed. Other applications may be more intuitive or conceptually simple.

I have also worked on projects that seemed like a great idea that never saw the light of day. The market was up, the company was growing, and it was time to create a new product only to have a merger, pandemic, or some other event take the wind out of our sails. On those projects, we spent a lot of money and had nothing to show for it. The business never received any benefit from our work. Development teams in that position are obvious choices for being laid off. Those teams cost money and aren't providing value yet.

My current team has already experienced building a very useful project over the course of weeks that was shelved due to a lay off event. Not only did they lose friends and co-workers in the lay off, they were frustrated and disappointed that all their hard work was for nothing. Now, we do our best to deliver value to the business every two weeks. If something changes, we can immediately pivot to more valuable work and deliver more value every two weeks.

It is also worth noting that if a company is not staffed correctly, no methodology in the world will save your projects. If a company lays off their project managers, agile practice leaders, scrum masters, quality analysts, and other roles, you can't really "agile" right or "waterfall" right.

When you're trying to do more with less, it is more important than ever to build relationships around your organization, build useful software quickly, collaborate with your users, and respond to the changing needs of the organization.

The Register Blog Post
EngPrax Blog Post

The one small topic I wanted to focus on today is related to production support with an agile software development team. I've seen this come up many times. I don't know what the ratio is, but I suspect that most software products don't have a dedicated support team. This means that once a software product has been released to production and users are using it, the development team needs to balance support with enhancements.

I have witnessed sprint planning meetings and stand-up meetings where production support work has come up and people have fallen into the trap of trying to decide how many points of support should be allocated per sprint.

There are a few problems with this thought process in my opinion. First, all work does NOT need to be pointed. Pointing is an exercise where the team tries to apply a relative size to the planned development items of enhancement work or defect fixes. The key is that the team knows something about the work. Ideally, the solution is known and the scope is fixed. But, even if the solution isn't known or the scope is not fixed, it is arguably possible to point such a story or at least create a spike for that work. (I subscribe to the idea that spikes should NOT be pointed.)

Second, activities related to incident or user support that haven't even happened yet cannot be pointed by definition. The work is undefined. The team often knows how many hours they spent doing support last sprint, so there is a temptation to try and assign points to that time. I would suggest not even trying.

Finally, points are only to assist with planning as a trailing indicator, nothing more. The previous velocity can be invalidated easily. Scheduled vacations, company events, paternity/maternity leave, etc. can make the team's velocity value almost useless compared to the team's current and unusual capacity. But, that's ok. Story points aren't special. They're just a planning tool. Don't give them more power than they deserve.

These days, many loud voices are ringing the bell that "Agile" is dead or broken. I don't think you should throw out the idea of following an agile methodology. I believe you should take the best of what works for your team, your product, and your users, make adjustments to suit your purposes, and stay focused on the real indicator of success: delivering value to your users and the organization.

What I like about using the word "obligation" is that it came from a completely different perspective than I expected. It hones in on the organization's relationship with its users without mentioning competitors or profits. It is simply the right thing to do and we should feel compelled to do it.

This word and this topic will require more reflection and a longer post in the future. For now, it seems to me that a wise leader very carefully considers their words. Not just to avoid saying the wrong thing, but to also make sure they say the right thing. The right words can convey the correct intent and perspective to others and change the whole course of events for an organization.

More to come!

Cheers!

As a company grows, a flat and loose organic management structure gets unwieldy. People need to be split into teams and those teams need to report to someone. The people who lead the teams can have a dramatic impact on morale, retention, and engagement.

I've worked at organizations that used skip-level meetings between the manager's manager and the manager's direct reports to gather feedback. I've also seen "town hall" meetings with VPs, suggestion boxes, and HR-driven homegrown surveys via email or SurveyMonkey. Each attempt at information gathering likely did provide some value, but it would have been difficult to track results in a way that could be used to make changes or decisions, let alone monitor progress over time.

In this glorious era of the information age, vendors have specialized in "people data" gathering and reporting. The more clients these companies have, the more data they have access to. They can create effective surveys for evaluating the morale and engagement of teams, the effectiveness of leadership, and more. They can analyze the data for trends and provide scores, reports, and guidance for companies committed to making improvements. For companies that are "people-first", these survey solutions can be very powerful.

My current employer uses a company called Glint to survey employees. The surveys help us measure leadership effectiveness, ask for input from team members, and allow us to compare our company data with global data.

It was powerful to see a score measuring my performance as a leader calculated based on the input of my team members. I am pleased to say that I scored 95. Compared to Glint's global dataset, my score is 14 points above the average and 6 points above the company's average.

Those numbers look good, but you can drill down into the scores and get even more insights. I scored well in categories like trust, consideration, and support. It was validating to see that the efforts I have made to build relationships with my team members have been fruitful.

The weakest score that I received was related to role clarity. At my current employer that is a systemic issue. As each leader reviews their results with their director or vice president, those higher leaders can see trends and (if they're wise) take steps to address the concerns raised by the employees. Before the Glint results came out, I was already working with my team to clarify roles, so the survey results affirmed that I was following the right path.

For any employee, providing them with metrics that go beyond dollars and cents can be more personal, more affirming, and more powerful. A survey like the one I described can help leaders grow, help employees feel heard, and drive better outcomes for the organization. A company is a hollow thing without the people who get things done. Is your company investing in ways to gather input from its people?

Cheers!

We had trouble with getting this function updated previously due to changes with .NET and the Azure Function Runtime that we didn't fully understand. After our most recent fixes, it had been running in QA for over a week with no additional issues. When we deployed it to production, however, the Azure resource seemed to having a problem, like the environment was constrained somehow. The Azure portal even had difficulty loading information and seemed to be lagging.

Most mature dev shops have a plan for this kind of thing. Code is released to production and then the changes are verified. If it isn't working, gather information (like error logs, screenshots, etc.), and then initiate a rollback, restoring the previous code to the production environment. There are variations, of course, depending on what capabilities are available.

In this case, my team had already rolled this code back once and then invested a substantial amount of time with the upgrade changes. During the deployment, my team wanted to merge the feature changes into the older .NET Core 3 version of the function and release that because they knew that would work. So, we did. I knew how much effort they had put in and I trusted my team.

We deviated from the normal process, made a code change, pushed it through the pipeline to production, and delivered the functionality our customers expected. I keep track of how clean our deployments are. I marked this deployment as "unclean" and reported the issues on the change tickets in ServiceNow. I also published written accolades for two of my developers who got the job done on an internal board. The release wasn't clean, but I didn't hold that against the team. There was an opportunity for a bit of heroics and I let them take it. In this case, I felt like the opportunity was more valuable than strictly following the process.

I hope you get a chance to feel heroic today. Cheers!

First, I use a loose agenda. I always start with a greeting and then ask how the person is doing, what they did over the weekend, etc. I like to demonstrate a sincere interest in their lives. This can be overdone, so make sure to watch for signs that you're asking for too much information. You want to build rapport, not interrogate them.

Next, I have a few general topics to cover. I like to check in on their progress regarding their goals, ask them how work is going, ask if they have any suggestions for process improvement, and ask if there is anything I can do to serve them better. You don't have to ask all these questions each time, but you should touch on them regularly.

The meeting length can be crucial to a successful one-on-one. I cannot stand it when I'm only given 25 minutes with my leader. By the time you get through the greetings and "how was your weekend?", half the meeting is over. I recommend starting with 50 to 60 minutes. If your team member consistently doesn't need that much time, you can ask them about shortening the meeting.

Finally, here's my new tip that I just organically started doing without thinking about it that hard. If appropriate, end with sincere, specific praise. When a recent one-on-one meeting I was hosting was coming to an end, I felt moved to tell a team member about how well they were doing by citing a few recent examples of behaviors I appreciated and the work they had accomplished. I could tell that this had a very positive impact on them. Since then, I have made a point to occasionally end one-on-one meetings by praising specific accomplishments or behaviors. I try not to overdo it. Forcing a "praise trailer" on each meeting would dilute the meaning of it.

People like to know they are doing well. All too often we spend time talking about what needs to be done and how to improve. We should all take time with others and ourselves to recall what we have accomplished and what we are doing well. A little sincere praise can go a long way in improving morale, building rapport, and retaining talent.

For more of my thoughts on one-on-one meetings, see my other post here: https://blog.dougdawson.info/tips-for-effective-one-on-one-meetings

Cheers!

I shared in the comments on that post that, as a leader, I try to always tell people that report to me why I need to speak to them, so they don't stress about it. In my experience, even high-performing people who should have nothing to worry about still panic a bit when "the boss" wants to talk.

It makes sense when you consider the range of experiences a person may have had. Perhaps they were laid off in a similar manner. Maybe they were summoned to a conversation that went poorly. I typically do something like, "Hello, so-and-so! Can you call me when you get a moment? I have a few questions about the upcoming release." Or, "Hey, so-and-so! I have a task for you. Can you ping me when you get a moment?"

Thankfully, I haven't had to call on people for a negative situation very often. But, I try to follow the same pattern there, too. "Good morning. I noticed your timesheet has not been submitted again. Can you get that submitted and give me a call?"

I was successful with these practices for a while, but I ran into a situation where I missed a chance to state my intentions. I scheduled a meeting with the director over the technical services department. The director was a well-respected leader, but did not have a technical background. I scheduled time to meet with the director, but I didn't state my intentions. The director requested an agenda. I must have made a joke about it or something because I recall that the director shared that providing her with an agenda was useful so they she could pre-consult with her experts or invite one of her experts to make sure the meeting was fruitful for both of us. I expected to come into the meeting with an ask that she would take away, but when I shared my agenda in advance, she was able to shorten the response cycle.

Here are two pro tips for effective communication:

1. When requesting a chat or call with someone, make sure to let them know the topic.

2. When scheduling a meeting, be sure to include an agenda or at least the reason why you want to meet.

Do you have any favorite pro tips for professional communication?

Cheers!