A Business Technology Place

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.

Using history to organize your teams

What does the history of man and the advancements of civilizations have to do with business?

I recently followed a recommendation to read Jared Diamond’s book Guns, Germs, and Steel: The Fates of Human Societies. The book was the winner of the 1998 Pulitzer Prize for general non-fiction and provides theories and supporting arguments for why some civilizations throughout history survived and conquered other civilizations. Diamond supports the idea that societies persist and spread based on geographical and environmental factors rather than racial genetics.

Do business organizations parallel human societies?

On page 457 of the book Diamond explores the questions he received from many business leaders after they read his work. He sets-up the question as:

“What is the best way to organize human groups, organizations, and businesses so as to maximize productivity, creativity, innovation, and wealth? …. Should your collection of people be organized into a single group, or broken down into a small or large number of groups?”

Ah yes, one of the classic modern business dilemmas. Businesses are in a constant see-saw between a centralized and decentralized organization. Centralization is pushed to provide more standardization, economies of scale, and reduction of expenses. Decentralization is pushed to provide more innovation and closer customer relationships.

In his book, Diamond suggests that some level of fragmentation (decentralization) helped European advances in history because it created competition which led to innovation. Contrary to this, the unification of China appears to be a factor why it fell behind Europe in innovation during the colonization period. But India, which had even more fragmentation than Europe, didn’t advance as rapidly as Europe with technological innovations and colonization. That’s a very simplified look at Diamond’s discourse on the subject, but it leads him to suggest that the most optimal organizations have some level of decentralization in them.

The trick is to determine the right level of balance.

I promote a balance in a number of areas in the IT organization that I manage. This includes the number of in-house developers vs contract and “off-shore” developers, centralized software tools vs solution specific tools, and centralized processes vs sub-department processes.

photo credit: Leo Cullum

photo credit: Leo Cullum

A few things are certain with any approach:

  • People will point out the faults of the current organizational design and suggest that a change to another model is needed (based on the other model’s merits and not faults).
  • There is usually some level of second guessing by team members as they experience organizational results and look for ways to tweak the team setup to perform better.
  • There is a natural pull (almost like gravity!) that says we should organize differently. It’s the “always a better way” and “continuous improvement” approach to organization and processes.

I believe the answer depends on what you need from each sub-group in the organization.

IT, like other business departments, is further divided into group based on the type of service provided to customers. I believe groups like desktop/voice services and networking are best setup with a more central approach. This allows them to set to standards for equipment, general office software, voice equipment, etc. I look for this group to provide a consistent and predictable service to the organization. Less variety in what they support allows them to scale better.

The software development groups are tasked with providing innovation and helping the company be more competitive in the marketplace. As such, I like to have the software develop teams setup in a more decentralized organization. This gives them freedom to innovate and compete.

The project management, business analyst, and quality assurance groups benefit from a centralized approach as it helps them to reduce their toolsets and simplify processes. But they also benefit from a bit of decentralization so they can better match their processes to the software development teams.

The problems of any organizational design are always in the forefront to discuss, break-down, and analyze. I’m OK with that. As I said above, I think that’s a natural activity as we constantly look for ways to perform better. It’s neat to see correlations between Diamond’s study of human organization through history and the modern business world.  If you haven’t read Diamond’s book, it’s worth your time at least to skim and take-in some of the main theories.

Onward and upward!

Let’s talk about #NoEstimates

Should we expect estimates for software development?

There’s a movement called “No Estimates” that suggests there is a better way to develop software without using estimates as part of the process. In an interview with InfoQ, Woody Zuill states, “Personally for me, what No Estimates is about, is alternative ways to make decisions, that don’t require that we use estimates.” As I read various articles on the idea, they suggest that the need for estimates is reduced (or eliminated?) by incrementally providing working software that can be shipped or delivered to the customer. The counter argument says that estimates are needed to provide input to scheduling, budgeting, and prioritization activities..

I read the debate with great interest since software delivery and estimates are part of my everyday life. I think proponents of both sides would agree to that the business of writing software is non-repetitive and could be classified as art. Estimates by definition are not completely accurate. In my mind, the dilemma between the programmer and stakeholder is not only how the estimates are delivered, but how they are interpreted by each. Project stakeholders look for estimates to provide working accountability for schedules and budgets. While the programmer is just trying to give a forecast of what he or she thinks based on what they know at the time.agile eightball

The answer isn’t whether we estimate or not, but why we estimate.

Zuill continues his thought, “But the problem isn’t with how easy they are to do, or how accurate they are. Is has more to do with, why do we need the estimates. What is our motivation for having these estimates?”

It’s a fair question and a good one. The value of getting the answer lies with discussing this line of questioning with project stakeholders to come to a mutually acceptable answer. Completely getting rid of estimates is hard because estimates are part of our life and culture. It spans all industries and services. We use estimates for our personal possessions as well as business processes at work to help us make decisions. Zuill asks if we need the estimate to make the decision.

Think about the first principle in the agile manifesto that says “Individuals and interactions over processes and tools.”

You see the value in the estimate is the interaction it creates with the customer and other project stakeholders. Estimating could be a nuisance to the programmer, but estimating creates an opportunity for an interaction with an individual. Customers like and expect estimates. But I think many customers and stakeholders would be open to the question of “What value does this estimate provide?” What we may find is that some estimating steps could be eliminated while others should remain. The answer may be in the middle-ground. Software development, after all, is a custom build each time through.

 

The Resource Constraint Conundrum

It’s the most over used term in the office.

“We have resource constraints.”

“We can’t do that project due to resource constraints.”

“We missed the time line due to resource constraints.”

The rationale behind this line of thinking is that there isn’t enough people. If we just had more people then we could do all the projects and hit all the time lines. We don’t have enough programmers. We don’t have enough architects. We don’t have enough testers. I think the excuse is just too convenient. In a way, it’s lazy.

Here’s why.

Organizations can’t employ an unlimited number of people. Even if the organization hired more programmers, it would only shift the bottleneck to another group. Think about that. If you hired three more programmers then the programmers would ultimately sit with no input because the existing business analysts couldn’t feed them work fast enough. Or the programmers output would increase so much that the QA testers would not be able to keep up with it. There has to be a slowest step. So this is an apparent conundrum. If only we could do more with less by working smarter.

A better way to think.

I find that this conversation parallels budget and financial processes. There is a finite amount of money in the budget, home or work. Is that a budget constraint? If we answer yes, then we have a mindset that there shouldn’t be limits. We should just be able to spend money whenever we want no matter the cost. The reality is that we have a set amount of money and we establish a budget as a guideline for how to spend it. The budget is what we choose to do with our money.

It's really about how we allocate what we have

It’s really about how we allocate what we have

I use that rationale for the home budget. We have X dollars each month. We choose how we will spend those X dollars. The budget isn’t a constraint. It’s a guide and a plan.

The same principle applies to people in the office. We have a set number of people on staff and a book of work to process. How we choose to allocate people to that work is our choice. It isn’t easy and requires tough decisions. But it’s a choice.

The conversation changer.

So the conversation changes from resource constraints to resource allocations. We should be talking in terms of customer retention, ROI, revenue, etc. The allocation of staff is a choice based on a plan. That’s a better conversation to have with everyone. Instead of complaints we talk about acknowledging current state and making choices.

Hiring more people or buying more equipment is always possible if the allocation of funds support it. Businesses are drawn to ROI. If the business case supports it and those in charge of managing the money believe the risk is worth taking, then the funds will be allocated. Businesses exist to make a return.

When it’s all said and done we work within the boundaries of what we have. That includes people, money, tools, equipment, and knowledge. Is that boundary a constraint? I sure hope not. I like to get stuff done!

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.  🙂