A Business Technology Place

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

Cast the bully out

We have a love-hate relationship with steering committees.

Do committees provide value that pays for the amount of overhead they create in workflows? If you are a committee member with voting privileges then the tendency is to support and agree with the both the decisions and procedural steps the committee follows. If you are a project requestor then your attitude about a steering committee is influenced by the amount of steps involved to get decisions as well as the amount of time it takes to reach a decision.

I have experience as both a committee member and a work requestor. I’ve observed both the value of a committee and the hindrance a committee can insert into workflow. A steering committee creates value when it buffers the amount of work that is given to a technology team to implement. The result of buffering work is protecting the downstream resources from becoming overburdened with too many concurrent tasks. Buffering work also prioritizes the backlog and technology team members want to work on what the business leaders designate as top priorities.

There is usually a bully, or two, that receives all of the attention of the committee.

But you’ve undoubtedly observed a myopic committee as well. There are usually one or two platforms/customers that usually receive top priority or seem get automatic approval. There is usually a direct correlation to the amount of revenue generated by the platform or customer and the committee decision.

Conflict arises when these projects take all available resources such that other projects or customers begin to starve for attention. A significant challenge exists for the employees who represent the smaller platforms and customers to be able to get work done. That’s not a good situation for the anyone. But the committee members feel justified because they have allocated resources to the work that tied to the most revenue.

Cast the bully out.

One way to remove the platform/customer that usually plays trump in the committee is to organize that work team around a hybrid technology model. In the hybrid model the business owner (product manager/customer manager) has day-to-day direction on setting priorities for the technology team. A centralized project management office can track the work backlog and work-in-progress (WIP). The business owner then reviews the WIP at the steering committee meeting to bring visibility and accountability to the direction and decisions of their group. So while the steering committee is not prioritizing work for the decentralized group, they do have visibility and the ability to influence work if needed.

This approach doesn’t work for all platforms and customers because that would mean that there are enough resources to have a dedicated technology team for each platform/customer. It does align the platform/customer work with the business line to promote a more agile approach to work. The business owners that used shared resources no longer get trumped by the bully projects. The bully projects are able to move more quickly because they don’t have the overhead of committee processing. It’s a win-win-win.

Steering Committee Bully

A Marketing Technologist does not fear change

What is an acceptable amount of time that a business process or model is in place before we can challenge the assumptions and basis for it?
Maybe this would be a good exam question in a MBA class. Answers are sure to vary and elicit a number of opinions. But  I would answer that as soon as a process is in place, it’s fair game for challenges. Every day I think about finding more efficient ways to accomplish tasks or even eliminating processes that don’t add value to the goal of the organization.

The most successful process challenges are sourced from measured results. If the results aren’t what we expect then the process is open for modification in an effort to change the results to be more favorable.  That concept seems so simple, but in reality it can be very difficult to execute.

I think the problem is that challenging an existing process or the assumptions that made the process is a bit like challenging the status quo. In many business environments challenging the status quo is akin to “rocking the boat”. It’s considered risky. It could impact baseline business metrics, people, and even the cash flow of the business. Big companies grow to be risk averse and create processes and procedures to minimize risk.

“Named must your fear be before banish it you can.”
Yoda was right. Before we can remove a fear in our life, we must call it by name. Marketing technologists (or really any person in position to challenge assumptions), must be ready to change assumptions, processes, and business model when they have data and results to support the challenge. An essential goal of the technologist is to understand how to deliver better business results for stakeholders by understanding how technology can provide solutions.

The technologist drives new work and solutions within an organization as a result of their everyday actions. The technologist sees patterns and variables in data that may not have previously existed. The technologist finds reasons that customers can’t complete the desired action and proposes ways to remove the barrier(s). The technologist identifies ways to make processes more efficient, regardless of the people involved with the existing process.

“Do or do not. There is no try.”

Three examples from my story.
I find myself with opportunities to challenge existing models each week at work. I’m not always successful in changing the model. Sometimes its because my idea was wrong. Sometimes it’s because others don’t agree with my opinion. Sometimes it’s because others are too busy to listen. But there are times when my challenge succeeds in making a better way. Here are three quick personal examples of challenging the status quo:

  1. In a B2B business model that does not sell direct to consumer the team thought they shouldn’t use sponsored search adwords because that would be considered “direct”. But what if we purchased ad space and sent the consumer to our existing site which honors the B2B contract with the client? It worked and the team found discovered a little about the click-through-rate of branded keywords in search results.
  2. Customer address changes are a touchy topic when you are selling a financial instrument because it can increase the likelihood of fraud. But address changes are part of life. So why not emulate the process followed at bank or credit union when their account holders need to update their address? It worked for my team and provided the single largest increase in customer conversion rates for any software release the team had ever released.
  3. In the early days of the internet I became the product manager for a web site where a customer order resulted in a notification to the call center. The call center would print the notification and then rekey the customer data into the order system. This print-to-key process was ripe for a more efficient method. So I suggested it and a few months later we integrated the web site to the ordering system. Bye-bye paper process.

Are you changing the model?
In the spirit of continuous improvement we all need to look for ways to challenge the processes that govern us. Adjust, measure, and react. I’m not talking about creating change just because some process is old. I’m also not talking about using technology for the sake of technology. I’m talking about using the tools of a technologist to understand how the purpose of the business process and how technology can make it better.

What say you?

Urgency is a two-face

What’s the goal of your organization?
Do this. Ask executives in your business what the goal of the business is. Is it to make market leading products and services? Is it to make and serve customers? Or is it really to make money?

Eliyahu M. Goldratt writes in his book “The Goal” that the goal of the organization “is to increase net profit, while simultaneously increasing both ROI and cash flow, and that’s the equivalent of saying the goal is to make money.”

The business may be about making a particular product or service. But the root goal is to supply money to its stakeholders and employees.

Is there an urgency within the organization to make money?
The farther you go up in the organizational chart the more you’ll find an urgency for making money. It’s sensible, because the higher the position the more responsibility it has for delivering results. Delivering financial results is directly correlated to keeping a job.

Yet you won’t find this same urgency in the lowest ranking levels of the organization. Those at the bottom of the organization are tasked with following procedures, gaining approvals, and struggling against organizational entropy. The processes we make, though well intentioned, often become the focus and goal of the rank-and-file. Getting through the day is not about making money, but about getting an approval and checking a box.

Urgency and bloated processes clash.
Let’s face it. Processes, by nature, grow with the aim of filling something that is missing. When something goes wrong human nature is to insert a new step so it doesn’t happen again. The process grows to try to cover it’s own inadequacies. Before long processes become filled with redundant and unnecessary steps. The irony is the process grows to account for exceptions and errors, but not to achieve the original goal.

Workers are rewarded for following all the steps and they soon find comfort and protection in the process. So it makes sense that the focus of the workers is on the process, not making money for the organization.

There should be an urgency to streamlining processes.
I’m not saying to abandon process and created an unstructured environment of work output. All organizations need some type of process to help create consistent work output at regular time intervals. Process is necessary. But leaders all the way up to the C-suite need to develop an urgency in keeping processes lean and focused on the goal. Help workers deliver more consistent work by making sure they are empowered and enabled to do the work efficiently.

Urgency comes from the top.
If an organization is to change it’s mindset about processes, it needs to come from the top. Management expectations do cascade downward. But if upper management is only concerned about the urgency of making money and not looking at how the organization can make it through operations, then inevitably the organization won’t make the money fast enough.

So spend some time thinking about current processes. Remove steps that don’t directly move work towards output. Remove redundant steps. Identify system bottlenecks, whether people or process, and determine how to alleviate it.

Am I missing something here? I just see big business has a big appetite for making money. But it can’t move fast enough because it trips over itself. So where is the urgency in that?

Are you hiding behind the process?

Some people depend on the process for making results.
I was involved in a situation recently where a software defect was found after the production release. A team member was quick to analyze the situation and indicated that the team had not followed all the steps in the process. They stated that this resulted in increased risk and was the root cause of the defect.

Don’t be afraid to fail.
It appeared to me that their behavior was driven from a fear of failure which often results in blame. If we work in environments that place blame for failures then how do we expect people to learn and correct mistakes? How do we expect them to operate at peak efficiency if they are focused more on the consequences of failure than they are on the results of succeeding?

I talked to the team member and their manager and explained that risk of defects and failures was part of the business of software development.  The particular change that our team implemented was low risk to begin with and the defect discovered was not disruptive to the financial aspects of the site. The decision to by-pass the full process was made based on reduced risk for the change and the potential financial return.

I had a similar conversation with my son about hitting a baseball.
If a baseball hitter has a batting average of .333 (one hit in every three at bats) it’s considered great. Think about that, that means the hitter fails two times every three at bats. Now, I understand trying to compare software development to baseball is like comparing apples to oranges. But it’s not the failure rate that I’m comparing; rather it’s the mindset of failure. A baseball hitter must approach batting with mindset of hitting the ball, not a mindset of swinging to prevent missing the ball. The same holds true for the software developers and testers. They should approach their profession with a mindset solving problems, not a mindset of being afraid of creating problems (defects).

It’s really all about focus.
Focus on the goal, the prize, and solving a problem. Don’t focus on not failing. The processes that organizations define exist to establish a consistent discipline to create a product or service. Problems arise when team members place more weight on following the process than on solving the problem. Don’t let the process becomes the focus and checking-off the steps the objective. That’s hiding behind the process.

A better way is to use the process as a guide for discipline. It helps to promote communication, consistency of purpose, and above all solving the real problem.