A Business Technology Place

The Merchant Stand

Tag Archives: SDLC

Mapping software development to Lean IT.

Posted on by Posted in Business Process Management, Lean Principles Leave a comment

The right process will produce the right results.

A core concept of the Toyota Production System is the right process will produce the right results. The “right process”. What exactly is that? Software development practitioners spend entire careers in search of it. Everyone has ideas and rationale to support various methods including Waterfall, Agile, and Hybrids.

But there is more here than a methodology match. As I consider how to adopt and grow Lean business principles in IT, I face a classic dilemma; how do I influence standardized tasks and visual controls into a software development process? Software developers are a different breed of office worker. Many of them have personality traits which make consistent processes quite a challenge.

Are software developers rule followers?

Here’s what I know about guys and gals that write code for a living:

  1. They are puzzle solvers
  2. They are inspired by writing code not documenting progress
  3. They don’t enjoy estimating because they don’t want to time box their craft
  4. They are artists who care more about how code is written than the process used to govern the project

So here’s my dilemma. A software developer is a person who is a creative problem solver that needs space to be an artist and really just wants to write code. How I put that person in a system that seeks to define standard processes and visual controls as a means to provide customer value?

Software developers are rule followers. They write code against a predefined language syntax. They crave requirements up-front before they start writing code. But software developers are also artists. They want freedom to express their talents through what they create, not a set rules defined by someone else.

Lean IT. Finding common ground.

When faced with opposing viewpoints, I believe the best approach is to focus on common ground. What do Lean IT and the attributes of a software developer have in common? Everyone wants these things:

  • Eliminate waste – Businesses like the effect on the bottom line. Developers don’t like spending their time on busy work.
  • Increase customer value  – Businesses like the effect on sales and repeat sales. Developers like having jobs and customers giving them new problems to solve.
  • Standardized work – Businesses like repeatable tasks that can be improved. Developers like a clear definition of what is expected of them.

Starting with these concepts, I think it’s possible to get developers on board with Lean IT.  With a little flexibility, compromise, and focus on the core business principles of Lean, a team can move down the path of increasing customer value. Let’s start there.
Onward and upward!

Photo credit: https://flic.kr/p/6U71RM – Jeff Sandquist via Creative Commons

Repeating software processes. To attract and repel.

Posted on by Posted in Agile Organization, Business Process Management, eCommerce Leave a comment

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.

Posted on by Posted in Agile Organization, Business Process Management, Business Technology, Career, eCommerce, Ideas Leave a comment

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.

 

Attacking process waste

Posted on by Posted in Agile Organization, Business Process Management, eCommerce Leave a comment

I don’t like process waste.

Who does? But how many of us really try to change processes to eliminate or reduce waste? In my experience this is a tough topic, and I dare say an unwelcome one, most of the time. The problem is that in an organization processes are tied to job existence and security. So the people in charge of setting the processes and administering them really don’t see the incentive to make adjustments.

I’m nearing my 20th year of software development experience, so I’ve observed and talked to many practitioners about software development process philosophies and techniques. Process waste starts to build when the people within the organizations place more importance on the process steps (requirements, estimates, and schedules) instead of the process output. The ultimate goal of software development is to make money by producing output. Waste takes away from the output.

Business case modeling and estimates are a common area for waste.

Let me start by saying that business case modeling and estimates are a necessary part of software development. The problem arises when the business case and estimates begin to consume a large percentage of the organizations time and a large percentage of the work is rejected. All of the work becomes throw-away because it has not created a return. Ironically the entire point of the business case is to prevent waste. We don’t want our organizations to produce product that does not yield a financial return.

Think about it. If the software development team is constantly estimating and scoping projects that are not approved then it reduces the amount of usable output created for the business.

The theory of constraints is a critical teaching to understand.

The Wikipedia entry for the Theory of constraints quotes Eliyahu Goldratt.

The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput.

In a perfect world, everything the software development team touches is processed into work output that generates money. We don’t live in a perfect world, but we do want the throughput of the system to be optimized. So it should produce money making output as quickly as possible. Work that is started and later thrown out is like throwing away inventory and only increases the overall operational expense of what it takes to get good output.

You have to work the constraint.

I’m a strong advocate that software development needs to focus on features, not projects. Projects are by definition unequal in size and length. Features are smaller in size, easier to understand, quicker to estimate and assist with providing more consistent system output. Bloated projects tend to have large price tags, take weeks to estimate, and are more likely to be rejected by management.

Think about the project approach. A team may spend two weeks creating a business case to review with management. Then the development team spends another two weeks estimating umpteen features. If the project is rejected then there is four weeks of effort that creates $0 of sellable output. The exercise devolves into a discussion about a single cost to build and the the time required to do so. It’s all or nothing and the focus on the goal of making sellable output is lost.

So if we want to work this particular constraint in the system then we need to evaluate each feature on its ability to achieve the end goal. Everything else is really just noise waste.  I hate waste.