The Merchant Stand - A Marketing Technology Place

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.  :-)



Software Release Management. It’s more than an IT thing.

This is about IT and Business alignment.
I’m fortunate enough to have worked in two different functional areas of a business: IT and Marketing. I can say with 100% confidence that business owners and stakeholders of software releases should be more concerned and involved in the IT release management process. The typical release process covers areas such as requirements specification, feature prioritization, business case modeling, and go-live deployment communication. It’s a set of tasks intended to oversee the requirements, development, testing, and deployment of software releases. Sounds very IT, but it should be a shared business process.

Release management is about adding value.
Release Management is also about how IT and business owners engage in communication that benefits the stakeholders and customers of the business. A business owner could be the CFO, CMO, product manager, finance manager, procurement agent, etc. It’s someone who champions and justifies the contents of a release. An engaged business owner has a chance to more positively influence the results of the release.

I’m not saying they need to know all the details of the software development cycle. I am saying they need to help with defining the process such that it maximizes the potential of the organization. One of the key traits of a successful leader is making success achievable by others. They can do this in the software development cycle by making sure that the process is free of unnecessary work and is efficient in how often work is output.

Mike Sutton and Tym Moore provide a great list of practical ways to improve software release management for One key point of Sutton and Moore is that establishing a regular release cycle is vital because:

  • It creates a predictable timetable for when stakeholders can expect to receive functionality. This creates confidence and allows the team to focus more on the content of the release.
  • It creates a routine for all functional teams to align their efforts.
  • It gives clients confidence that your business is regularly delivering new value to the marketplace.

Think features, not projects.
Here’s the rub. To get to regular release cycles (such as every six weeks), your software development process needs to focus on delivering features of work rather than projects of work. Projects by definition have a variable level of scope which means that delivery dates will also be variable. Content for regulatory requirements, compliance issues, new features, or defect fixes are easier to deliver when they split into several smaller units of work effort. It’s a similar the concept of memorizing larger lists by “chunking” the list into smaller groups.

That’s a paradigm shift for many traditional project organizations. But it’s a way to encourage lightweight processes and focus more on delivering value to the client quicker. discusses release cycles that were becoming longer and delivering less before they turned to a process focused on smaller and regular releases. They saw an immediate increase in the number of features delivered per team and a reduction in the days between releases., the largest online retailer, also uses regular release cycles.

At then end of the day it’s about efficiency and work output.
Automated machinery is installed on plant production floors for this very reason. The machines produce units of output at predefined intervals. This maximizes value to the business and clients. Our software release output should aim to be the same way. It’s definitely more than an IT thing. It’s just good business.

Process: friend and foe

In my reading this week I came across a blog post from Tom Peters entitled Strategy: War on Systems. Tom talks about “systems” within an organization and while they are developed with good intentions, they often become inhibitors to achieving the organizational mission. I talk about this very subject quite a bit on my blog also. In fact while reviewing my notes for blog post ideas I found this entry:

“Software Development lessons learned (process is both friend and foe) – Software development friend and foe”.

This thought matches exactly with Tom’s thought about war on systems. Your software development process has steps that exist to produce output and serve customers. Over time, the process becomes more elaborate. Steps are added to prevent faults that happened in the past, to satisfy regulatory requirements, to satisfy best practices, or even recommendations from a consultant. As Tom put it, this type of system or process can “strangle” the organization. It becomes a priority just to follow the process and team members lose site of the original mission. Team members become process engineers as they navigate the process from end-to-end and feel accomplished when they can check-off each step completed.

It’s a safe bet to say that end customer rarely has influence into the design of the process. Ultimately, the customer has to buy the output and no one else.  So make sure your people have the ability to call-out and question process steps that don’t provide value for the customer. This is a big step for an organization that wants to increase its customer focus.

When does process remove your passion?

I’ve heard it said of teachers before that they lose their ability to do what they are passionate about because of all the paper work required for their job.  As organizations or groups mature typically the processes within each group will tend to expand. So my question is, when does following the process remove people from their passions and what they love to do (i.e. serve a customer, teach a student, write software code, advise patients, etc.)? I see people making decisions because that’s what the process says or they are looking to check-off on a process step. At some point they lose site of the real need they are trying to solve as the following the process rules their thoughts and actions.

In my professional life, my passion zones are around being part of software development and helping to solve business needs through the use of technology.  I had a reflective moment this week that I spend most of my time navigating through process management requirements such that I’m losing the ability to work in my passion zones. But is that really true? Is process management really part of the journey to solving the business need or producing the piece of software? Can the two be separated? Should we consider all of the steps and flows of a process part of the act of solving a business need or teaching a student, or advising a patient?

Let me know your thoughts and experiences.

Stories needed of business process improvement

I was watching CNN this morning while doing time on the treadmill. A story came on about the warning from OSHA to Sea World that whales would eventually kill a person in the current environment unless they made some changes.  It made think about people within organizations that try to sound


Kai=Change, Zen=Good(for the better), Kaizen=Continuous Improvement

warnings and alerts about business process improvement topics. Everyone is quick to agree that business processes are always full of opportunity for improvement. Remember Kaizen and business process rengineering? I remember a time when the buzz word of ‘continuous improvement’ was common place in the industry. I’d see it at training sessions, webinars, and company culture and leadership training.  But I don’t hear it so much any more.

So I wonder, how much time do we spend making incremental improvements of processes? How does an organization come to support and embrace this? Does it take an event where the process output reaches virtually zero? Is it the result of a change in leadership where the new leader seeks to leave his/her mark? Tell me about business process management in your organization. Do employees continuously seek improvement and does management listen?