A Business Technology Place

When being unpopular is part of your job description

A colleague told me a story this week about their involvement in a software development project. If you make software for a living you know there is always a desire to produce working software faster. Her story was a tale about requirements, servers, browsers, bugs, and other types of gremlins we find while making software. There was angst from the team, including me, to go faster to complete the working version. But she was entrenched with her position to get the software completely correct. Then she said something unexpected and paused for effect:

“It may make me unpopular. But that’s why I’m here; to make life easier for the customer.”

 

The statement stuck with me into the evening.

Is customer advocacy a distinct position and role on the team or does everyone share responsibility for thinking this way?

What is the distinction between quality focus and customer focus?

My team has been bitten multiple times in the past by rushing to produce “must have” and ”mission critical” software releases only to have the customer not use the software.  In each case there was a customer advocate. But in each case the customer didn’t connect with the software to produce the intended results. The software worked as requested but the business model for the trading of goods and services didn’t work.

Those projects left a bad taste in my mouth. But don’t blame the customer. Blame our ability to connect the potential customer with a solution they would use.

It’s the job of the solution designers to create a bridge between the customer’s desire and the customer’s use because the customer cannot. It’s the job of the testers to cross the bridge the solution Bridgedesigner creates because the designer should not. It’s the job of the customer advocate to cross the bridge like the customer would move across it. Maybe that’s skipping, running, or even sliding. That may make the customer advocate unpopular because the designers and testers tend to think about crossing with the design of the bridge in mind whereas the customer thinks about what’s on the other side.

Then I realized that the customer advocate may have to play an unpopular position to the customer as well. Sometimes the customer doesn’t know exactly what they want or how to describe it. Sometimes the customer has unrealistic expectations about delivery. The customer advocate may find themselves saying something like “We can’t do that….but what we can do is this…..” There’s a risk in throwing out a statement like that. The customer may walk away completely. But I believe in most cases it creates a deeper conversation. One in which the customer becomes more engaged. It’s a conversation that goes closer to defining the bridge between the customer’s desire and the customer’s use of a product or service.

So if you know a customer advocate on your team that is unpopular at times then they’re probably doing something right. Show them some love this week.

Onward and upward!

Photo Credit: Quapan – Creative Commons

The speed of software releases

How fast do you want software released?

I was part of a discussion this week week about the velocity of production software deployments. I didn’t use velocity in the context of estimating software but rather the benefits of a regular cadence to releases and the focus it brings to the testing effort. The velocity of the team affects the frequency of production changes and thus in a sense affects the overall risk to the organization for disruption to existing services.  If we release software too quickly, I believe we increase the risk of service disruption and create inefficiencies in system-level testing. If we release software too slowly then we increase the risk of losing competitively in the marketplace as well as losing customers.

Boris from GoldenEye knew what he liked.

Boris from GoldenEye knew what he liked.

This wasn’t a discussion about agile software development principles.

For my part, I was curious about the relationship of production software releases,production defects created by those releases, and the testing effort required for approval. Maybe velocity was the wrong term to use based on its agile methodology definition.  My focus was on the frequency of change events to the production environment. In the most basic form, software releases can arranged by individual unit (feature/bug).  Each time there is a production release it requires at a minimum unit testing for the bug or feature that is new or has changed. But when we don’t do some level of full system testing we may miss items that are broken as result of the code change. All production releases by nature have some element of risk to disrupt current services.

What’s the right software release frequency?

Obviously the answer to this question depends on a variety of factors. Software and business teams make choices and decision about how they answer the question.  I look for a balance to provide support in the following areas:

  • Quality Assurance – The testing effort should have time  focus on feature and system-level testing.  Full system testing should reduce the risk of introducing new bugs into production as result of the new code.
  • Maintenance window – Excluding full system outages, the maintenance windows provide an agreed-to time for production updates. So if the maintenance windows are every other week then the software release schedule should not exceed every other week.
  • Priority – Not all production defects require immediate resolution.  The balance is to fix priority defects in a timely manner but not so frequently that it increases the risk and pressure associated with quality assurance thoroughness.

Remember what it is all about.

The point of velocity is not to tick a check-list that we have a process. The velocity does have benefits with estimating. But the real value is to provide a regular cadence of features with the highest quality to the customer. Most of all, the customer should understand the flow and be part of the process.

Onward and upward.

Software open feedback loops

What is the secret sauce?

What really drives new software features? Do we live in a world where the marketing department rules the day with ROI driven and profit making capabilities from within the software? To an extent, I believe the answer is yes. Businesses exist to make money. Business software is written to facilitate the flow of money either through sales or automation of processes. If a piece of software doesn’t help the organization to make money it won’t last long.Simple_Feedback_02

But software that is not used, doesn’t make money. No matter how good the idea, if the software is not used, the business justification fails. This is why an open feedback loop with users is critical to the success of the software and could be tagged as the secret sauce for software development. User input drives usage. Usage accomplishes the goal for sales or productivity.

Creating the WOW.

Service organizations like to create the wow factor with customers to drive brand loyalty. Good software has that effect also. I see people that are passionate about Evernote, OneNote, and Photoshop as examples. Evernote survives with paid subscriptions. With a free-version available, and many options for recording/capturing notes, they have to “wow” customers to keep the software in the market place. The Evernote blog is a good place to see user input and feedback. Users provide feedback in the comments section and are often cited in case-study like blog posts. New features sometimes don’t have a direct link to increased sales. But they do have a direct link to usage which has a direct link to sales.

I was pleased this week when I heard a product manager tell a steering committee that we have a good feedback loop in place with the user-base that is driving feature enhancements in a software tool. Some of the feature-adds were completely cosmetic. But they were added to drive additional usage on the site. For the site referenced by the comment, additional usage means increased cost reduction through productivity gains in the back-office. If we execute properly, we should position ourselves to deliver the wow factor for the users. That was exactly the point of the comment.

So I submit that the open feedback loop with customers is the secret sauce that helps software achieve it’s stated goals. Product managers and marketers have to find the balance between user input and needed features for ROI. Without usage, the software is just a heap of 1s and 0s.

Repeating software processes. To attract and repel.

Are we attracted to repetition?

Yes.  We all are. It touches every facet of our lives. As a few examples, we eat the same types of foods each week, we watch the same TV series, and we read books that belong to a series. A study and report from Alix Spiegel of NPR captures the power of repetition in music that attracts us. Spiegel reports that “90 percent of the music we listen to is music we’ve heard before. We return again and again to our favorite songs, listening over and over to the same musical riffs, which themselves repeat over and over inside the music..” She then gives the result of a study that shows how people preferred music with repetition over the same song without repetition.

Repetition in Software Development.

Software development has the same draw for repetition. Managers spend time and thought to create a software development lifecycle (SDLC) that fits their company culture and team skill sets. They want something repeatable to drive efficiencies of a process, consistency of work output, and reliability of estimates. These are the attractiven features of a SDLC.

There’s an entire business industry built on repetition in software development. Books, training, and consultants feed us new ideas and different ways to think. But the end game they seek is adoption to a standard method that works within the framework of our business culture. This is all for good reason. As a professional in the world of software development, I recognize that we must be disciplined. I recognize that we have to think and find more efficient ways to produce software so that we can stay competitive and drive results through the business.

But there is a repelling force to repetition as well.

There are two danger zones that software managers should consider with repetition in process. Both of these creep-in an organization silently. Ironically they destroy the very things that repetitive process can build.

  1. Repetition can stagnate creativity. When we follow a script, we don’t think much about the ‘why’. We don’t think about better ways to do things. We just follow the process because someone already did all that thinking. Worst of all is that we don’t see it. We think we are accomplishing our job because we followed the steps.
  2. Repetition can become the end goal. When checking the boxes on the process flow becomes more important than the final product then the process has become the master. If employees are consumed with following every detail of a process and only satisfied when they mark steps as complete then the process has become larger than the importance of the end result. You’ll recognize this in an organization when the meetings about the process outnumber the meetings about the solution, the who, and the why.

Watch for it!

Watch for it in your organization and life. It’s like two magnets with forces that attract and repel. We have to find a way to both pursue and guard against the powers of repetition in the workplace. This means constant examination. It means living with shades of gray within process. It means we need write with a pencil, allowing for a both a sharp and dull point. The eraser is nice to have also.  🙂

 

 

Play it again.

Repetition in youth.

That song was awesome! Play it again. Rewind-stop-play-rewind-stop-play-forward-play, call the radio station for a request, press repeat. These actions are all part of my memory as a youth. Back in the days when I spent a fair amount of my income on cassette tapes and CDs. It was that song. It was my favorite song. It was our special song.  It represented something of value in mood, a feeling, a lyric, or a sound. Whatever the case when I found it, I wanted to do it again. Play it again and again.

Repetition in business.

The year has changed. My daily routines have changed. My friends have changed. But one thing that is still there is an attraction to repeat what works in business. Play it again! When a project or implementation goes well we talk about “lessons learned”. Sure we record the bad, but we also record what went right. Then we try to do it again. We want to replicate the secret formula for the same good results.

But software projects are all different. The requirements change. The people may change. The customer may change. Repeating success is not as easy as hitting rewind-stop-play. We could different results holding all but one of those variables the same.

Magic in the interpretation.

Two musicians will play the same song differently. It’s their interpretation, their emphasis, and their feeling. Software programming can be the same way. Two different programmers will create distinctly different programs that accomplish the same goal. The results may be visible in the UI or noticed by different workflows and program speed. It’s all part of their interpretation and skill.

Programmers “play it again” when they establish repeatable processes and procedures. It’s the software development life cycle (SDLC). Strictness to process is encouraged, but the real magic happens when the programmer is allowed to interpret , feel, and create on the edges.

So yes, play it again in business and software development. But play with feeling. Play from the heart. Find that unique rhythm. Create a one of a kind. Stop-rewind-play.