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!

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.

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

How marketing technology, agile marketing, and Marissa Mayer are influencing the future org chart

An engineer turned CEO is a story that attracts attention.
The recent news that former Google engineer Marissa Mayer is filling the role of CEO at Yahoo! is a great example that traditional career paths in a functional silo are becoming a thing of the past. It should come as no surprise that company leaders today need to be well versed in both business and technical principles. It’s the result of the role of advancing technology and the digital world. Logically, it makes sense too. The most diverse leaders will be those with experience in multiple areas of the business.

But every career path doesn’t have to end with CEO.
The Real Story Group recognized the Rise of the Enterprise Marketing Technologist from recent research on the growing trend of digital marketing tool sets. A marketing technologist is a growing role in organizations even though they may have different titles the point is that the boundaries between marketing and technology continue to blur. Even my title is currently composed of “marketing technology”.

As I look back at the eCommerce organization mind map that I created, I can see the same concept there. Ecommerce management leaders have responsibility in software development, content management, merchandising, demand management, etc. Ecommerce is truly a melting pot of technology, sales, marketing, and operations.

Agile principles will further influence this trend.
Scott Brinker created a nifty diagram showing the Renaissance Career. The term may be a good description of the change that I believe will start to grow in the business world regarding career paths. That’s because the idea of agile development methodologies for software development is spreading to agile marketing methodologies.  Agile thinking values responsiveness over planning and focuses on interactions between functional areas more than passing large documents between them. Yeah, that means you might have the marketer and IT programmer at the same table. Lingos, language, and understanding will blend and blur.

This is good news for all of us. But what does it mean for “functional” departments in the company?
This means opportunity. It means rewards for those who seek to understand how technology solves business problems. For some it means advancing to an executive leadership role with more knowledge of how the enterprise operates. For others it means finding opportunities to serve in areas where they would not have ever imagined themselves.

Do you think this will lead to removal of functional groups in the enterprise such as marketing, IT, and sales? Will the future corporate department be organized around products and services more than the functional groups we know today? This means a more customer centric alignment rather than work type alignment. It allows the blending of our current functional roles into roles such as a marketing technologist.

Hmm. That would be a renaissance. What do you think?

Thought readings 3

Each week I capture, mark, and comment on blog posts and news articles around the internet. This is short list of three links that I think others will find valuable for their thought lives.

  1. No iPhone leads 700,000 customer to flee TMobile by David Goldman at CNN Money. I’m a TMobile customer and have been for years. It doesn’t bother me not to have an iPhone but for some people it’s Apple or nothing. The more interesting part of this news is why TMobile doesn’t offer the iPhone today.
  2. Can I make my team do agile? by Mike Cottmeyer at Leading Agile. This was Mike’s 400th blog post and I think it is also his elevator pitch for why your software development teams should be using an agile development method. He makes his case using goals.
  3. Hacker Monthly by Andrew Phelps at Nieman Journalism Lab. I love this look at how repurposing  existing internet content has made a business for Lim Cheng Soon.

Let me know what links you shared, tagged, or commented on this week.