A Business Technology Place

Technology Constipation

We all want to be regular.

Something we all have in common at work is the desire to have a regular and predictable cadence of work output. Doing so just makes life easier. It’s rewarding to our customers when they receive their goods and services within expected boundaries. It’s good for the well-being of our team dynamics and mental happiness because everyone achieves the goal together and feels the satisfaction of customer acceptance.

Work methodologies agree on this concept as well. Systems such as Agile software development and Lean aim to create flow and eliminate unevenness in a system.  Unevenness brings excess inventory within the system that is apparent when materials, supplies, and outputs start to collect in areas while waiting for the next step in the flow to process them.

Technology Constipation.

I had never really thought about excess inventory like constipation before this week. But while looking at the portfolio of technology work and the length of time some projects had been in the system, I started to see the pains and strains of organizational team members to keep up with the work. When technology projects don’t keep a regular cadence the tendency is to continue to start new work to meet stakeholder expectations for delivery. That’s a recipe for technology constipation.

Warehouse

Warehouse

Finding relief.

Pushing more work is analogous to painful straining. It gives the allusion that the team is working harder, but in the long run it will only make things worse.  Work system methodologies like Agile and Lean have a manual describing the steps for better workflow and reducing inventory. These steps require management support, team culture fit, a common approach, and persistence over time. But you we can’t let the symptoms of the problem overwhelm us and paralyze the team into inaction.

Here are some good initial steps for technology teams to find relief:

  • Communicate with internal customers about the build-up of inventory and future demand. It’s more than being transparent with your customers it’s also about involving them in the decision making of priorities.
  • Focus on current work in progress to finish what you’ve started while not taking on other work. This is like telling a person with large credit card debts to stop putting more purchases on the card until they are paid-off. Otherwise the cycle continues. Stakeholder support is required for this!
  • Start to analyze existing work streams with an eye for implementing agile and/or lean tactics. Iterate, review, reflect, and repeat.

One thing is certain; it’s good to be regular and painful to experience back-up of solution delivery. That’s reason enough to start or continue working towards better flow of work.

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.

 

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

 

 

Interactions over Processes (user story template)

The first value statement in the Agile Manifesto is “Individuals and interactions over processes and tools”. Mike McLaughlin, of Version One, questions the role and influence the growing agile tool set has on individuals and interactions. McLaughlin states that the capability of Agile based software tools adds scalability and efficiencies, but that this does not remove the need for team members to interact with each other. His point is that we need to stick to the original intent of the manifesto language. Focus on the interactions, not the process.

It pulls like gravity.
It is human nature to gravitate toward stricter process and away from individuals and interactions. Organizations want to be lean to contain costs. Organizations want processes to provide consistent and efficient deliverables. These forces pull organizations toward larger processes and push employees away from the importance of the human interaction.

In my experience, the downside of a process is that it tends to become the goal of many who follow it. I’ve seen employees feel like they have accomplished their goal simply because they followed the 10 step process and populated the fields on a form. Usually when people reach this point they stop thinking about the people and interactions on the other side of the process.

Recently, a co-worker shared with me that she went to an in-network doctor for a procedure. The doctor chose to use a second medical provider for a part of the medical services. When the insurance company received the claim, they said the second medical provider was out of network, so the insurance company charged a different amount for their services. They penalized the insured as if it was the choice of the insured as to what secondary service the primary doctor chose to use. The process in this case missed the mark of the original intent. But it took over one year of appeals to get a reversal of course from the insurance policy.

A user story.
I recently wrote a project charter to frame-up an upcoming project. I chose a traditional project charter template because the original request for the project work was vague enough that it included a large number of possible outcomes. So I wanted a document format that could aid me with getting clarification for the project goals and better define the boundaries of the project project. To compile the charter I had to interview several business stakeholders to learn about program rules, pricing rules, and system constraints.

I used the project charter as a basis to then move into agile user stories. Now, I’ll be honest. I have not used the agile user story approach previously for requirements gathering. I have created use-cases in the past and user story follows a similar type of approach. But true to the agile manifesto, the user stories put less emphasis on a grand template and more emphasis on a conversation. I like the user story approach because it is setup to get requirement information from a project stakeholder through the use of everyday language. “As a , I want , so that . This type of approach encourages user interaction. It encourages natural dialogue to document requirements.

The result of interactions.
At the end of the user stories, I had a document that showed how the people involved in the project would interact and use a system and what they expected to get from it. To get there I had to interview and interact. Dare I say that’s a good process to follow for software development? 😉

But seriously, I think it steers discussion towards the benefits of the project work and away from the fields in a form. There is a structure to the user story template. But the structure is almost invisible because it adheres to natural language. I wasn’t even aware of the form structure while I conversed with the business stakeholder to gather input. At the end of our discussion, I had a user story. I had an artifact that could be used to begin design and coding. I had experienced the value of the first value statement in the Agile Manifesto.

User Story and Acceptance Criteria

User Story and Acceptance Criteria

Is your backlog a graveyard?

If your backlog is not a graveyard then you may be short of ideas.
In my 20+ years of software, I’ve always had a backlog for software development. The list is full of ideas, customer requests, and defects. It fills faster than the team can implement and some items become aged and never resolved. I’ve come to realize that if I don’t have a list with aged items it’s probably because I don’t  have an open channel of incoming ideas and I’m no listening to my customers.

I used to stress over an overflowing backlog and it was a source of frustration. As I matured a bit with software development I realized it’s not realistic to completely solve the backlog queue. But it is realistic to improve processes to resolve the backlog items more efficiently. It’s not about an empty list but about what’s in the list and how the team is processing it.

After time, the priority of some backlog requests changes.
It’s like that shining new thing you want to buy. If you wait a week before making an impulse decision you often realize that you don’t really need that thing. Software is the same way. With the passing of time, some requests may no longer be relevant, or become less important as the business environment changes.

To keep the backlog manageable purge items periodically.
One inefficient process that I’ve found myself in over the years is continually prioritizing some backlog items that never get implemented. It’s the equivalent of re-work because the team rehashes the backlog item each time. Some backlog items are complicated and can take time to go over the relevant facts to determine a priority. At some point, the team needs to decide if the item should be returned to the backlog or purged.

Some possible purging methods:

  • Time based – After a certain time period in the backlog an item is removed.
  • No longer relevant – If the business purpose of the idea is no longer relevant.
  • Revenue expectations – If the backlog item does not meet a specified revenue threshold.
  • Non essential – If the backlog item is not required for contractual obligations or compliance of some external agent.

The backlog should be a primary input to your roadmap.
If I’m managing my backlog properly then I should see items removed and added regularly. A healthy backlog has both elimination of items and turnover. If I do this, then the items within the backlog list will be relevant to business needs and a primary input to the software roadmap.