Agile ECommerce | The Merchant Stand

Interactions over Processes (user story template)

Posted on September 7, 2013 by Bob Williams Posted in Agile Organization, Business and IT Alignment, Business Process Management, eCommerce Leave a comment

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

Thinking about predictable software development

Posted on January 5, 2013 by Bob Williams Posted in Agile Organization, Business and IT Alignment, eCommerce, Ideas 1 Comment

I was talking with a mentor this week about software development and the challenges of aligning IT ideals with business expectations. From a high level we agreed that the purpose of the software development process should be to produce software that generates monetary value, by revenue increase or cost decrease, for the business. That’s really just stating alignment with the goal of the business and may seem obvious. Yet in reality, people tend to drift towards different goals for software development. That’s what creates misalignment between stakeholders and often results in inconsistent output.

One of the key principles that he wanted me to take-away was that the production of software should be predictable. A definition of predictable is “behaving or occurring in a way that is expected.” So what do business owners expect from software development? What do IT owners expect?

In my experience, an IT group tends to define predictable software through quality measures. There is a heavy emphasis on requirements to create a detailed specification with the goal that the software will do exactly what the business stakeholder requests. But business stakeholders tend to define predictability in terms of the cadence of the output. They want to have a comfort level of when something will be produced that solves a problem for a customer and ultimately generates revenue for the company.

Are the metrics of a predictable cadence and predictable quality incongruent? I don’t think so. But to achieve predictability with both of these attributes requires a different mindset from all the team members. It means that requirements may not be defined exactly according to a specification. It means software output may take multiple iterations or not be exactly right the first time. Are business leaders and IT leaders willing to live with that level of inexactness?

And does it seem counter intuitive that inexactness can provide predictability? It’s a mindset change. But I remind myself that satisfying predictability is also not the goal. It’s a means to achieve the goal to produce working software that sells and provides a monetary value for the company. That’s something everyone expects.

4 Steps for Organizational Agility

Posted on July 9, 2009 by Bob Williams Posted in Agile Organization, Customer Focus, Ideas 2 Comments

Last week I provided some thoughts about organizational agility and a few of the root causes for why organizations suffer issues related to non-productivity. Getting work done into today’s organizations often becomes a game of who can beat the system. Management wants you to get your tasks done quickly to deliver results, but they can’t condone actions that don’t follow the established procedures and approvals. That’s the rub. Often times, existing process and approval steps are burdened with layers of red tape, people, and committees. So we play games to jockey and position for priority of work and assignment of resources. Who pays for this at the end of the day? The customer does. Opportunity costs are high as value added products and services to customers are delayed while work is caught up in the system.

So how do we become more agile in our Internet marketing and eCommerce organizations? There are 4 steps to outfit your ship with more speed:

1.Focus on the intended outcome

We spend a lot of time focusing on existing processes and procedures. This is not a bad thing as processes should be refined for incremental improvements. The danger is that when we only look for ways to improve existing processes then we fail to think about new ways to solve the problem. In fact, we often forget what the original problem was and thus we forget the whole purpose of the process. By focusing on the intended outcome, we can more easily steer clear of obstacles that are unnecessary and impede progress.

Photo: Creative Commons from weesen

Often times people justify process steps because they are necessary for some governing compliance or audit check. In many cases, if you examine the intended outcome of an audit, you’ll find that the audit isn’t so much checking the details of what steps you follow, rather that you follow your published steps consistently. For example, is it necessary to get the 4 different sign-offs for a change or would it suffice to have a sign-off from a managerial position that was not directly involved with the implementation of the work? If your process and quality control is to have sign-off from an third party then you have an opportunity to shrink the approval process. Perhaps all those other people would do just as well with an informational notification with the ability to object if they had issues with the change.

2.Get management support

To gain widespread adoption of any changes, you have to get management in on the program. My experience has been that without management support, you’ll get at best pockets of adoption towards organizational agility. Those groups that try to use agile methods will be the ones with local managers who can influence work flow within their team. An example of this might be a team that controls content of a web site. The manager may enable his implementer to work directly with the requesting customer for approval of the change and not require additional approvals from himself. The manager may setup a system whereby the implementer does their work according to a set of guidelines. If the requested work falls outside the guidelines then further discussion is needed.

What are some ways to about getting widespread management support? One, is to provide examples of agile-like methods in use and how much more productive a team has been with the methods. Find examples of a development team that left behind a waterfall software development method and adopted a method by which they went to 6-8 week release cycles following one of the agile SDLC flavors. Can you prove more productivity? Did the software error rate decrease? Were the customers happier and more satisfied?

If management is interested after seeing some real-life examples, then ask for a pilot. This could be as simple as restructuring an approval process for documentation or more complex like adding an agile software development process. Measure the results of the pilot and use that as the basis for more support from management.

3.Train the organization on agile methods

Once you have management on board and supporting a move to streamline the organizational processes, you need to train the masses. For development organizations, this could be extensive if the existing work force has never known anything other than the waterfall method. People find comfort in a process they know and resist change. Agile methods require a change in thought and perspective. As with management, the team members need to be on board with how agile processes will help them be more efficient at their jobs to deliver better quality products and services to their customers. The best way to sell this is to show how your methods will free team members to do more of what they were hired to do (create products/services) and less of what frustrates them (paper work, approvals, politics, etc.)

For something like an approval process, you may not need to introduce formal training. Here it might be sufficient to update documentation for the process and then have a review with everyone. In many cases work flow approvals are governed by software, so it could require an adjustment of that as well. So let’s say for example that you have a process in place that governs press releases. Maybe the document must be first be drafted by the subject matter expert and then passed to his or her manager for edits. After that it goes to two different vice presidents for approval and edits. Once this is done its passed to the legal department for review and edits. You might make this process more agile by having a single review time with everyone and do it in person rather than waiting for multiple approvals through an automated software system. Another idea is to shorten the list of approvers but increase the list of those who are notified. Anyone on the notification list can object, but they don’t stand in the way of approvals and introduce multiple rounds of edits.

4.Create a culture that thrives on customer focus

When you create a culture that is passionate about getting things done for the customer, then you’ll have a group of people that will not be happy with processes and procedures that create delays and unnecessary steps. People who are customer focused will thrive in an organization that gives them freedom to operate within a system. They should be free to innovate, create, and serve. The bottom line is to return the focus to the customer. If you can trust your subject matter experts and implementers to get the job done to satisfy organizational goals then you probably don’t have the right people on the ship.

How do you this? It needs to happen as a combination of actions including:

Have management talk about the importance of customer focus. This means that customer focus is as important as tangible short term financial results. The idea is that you don’t sacrifice customer focus for profits because that’s short term thinking that could lead to worse results in the long term.
Reward teams and individuals that exhibit customer focus. If your customers let you know about employees who go the extra mile to make things happen then broadcast this information. Create a culture of customer focus by putting customer focus at the forefront.
Hire people with proven track records of customer focus and innovation. Find people that have received positive comments from their customers. Look for examples of how they have innovated for the customers in the past.
Hire people that are willing to challenge the status quo. Does your organization embrace people that challenge the status quo and the way things have always been done? Do you encourage people to ask ‘why?’. These are your passion builders. These are members who want to serve. Get the right people on the team!

—

What are your thoughts? Do you have other ideas on how to better implement agile work flow practices in an organization? Do have you experiences with techniques that have or have not worked?

Organizational agility. Are you serious about it?

Posted on July 3, 2009 by Bob Williams Posted in Agile Organization, Customer Focus, Ideas 3 Comments

Adam Singer shared his thoughts about how organizational agility benefits social media and marketing efforts. As I read his thoughts I couldn’t help but think about how much I agreed with him and have struggled to promote this concept in the work place. Organizational agility is easier in new or small organizations that either don’t have the staffing to promote extra processes or have not yet had time to establish layers of processes. But how does an established organization find agility since human nature is to add processes and approvals as time passes?

Organizational Agility

To explore this question let’s first consider a few of the root causes of multiple layers of processes and approvals to get work done in an organization. One reason is to add a toll gate or checkpoint in a process after a failure. We want to ‘make sure that failure doesn’t happen again’ so we add a new checkpoint in the process.

Another reason for overly complex systems of approvals and reviews is it protects those in power through organizational reporting hierarchy. It maintains the status quo! When one has organizational power they typically don’t like being by-passed in decisions of the organizations voice and output.

Jim Collins in his book “Good to Great: Why Some Companies Make the Leap… and Others Don’t” states that “Bureaucratic cultures arise to compensate for incompetence and lack of discipline, which arise from having the wrong people on the bus. A culture of discipline involves a duality On the one hand, it requires people who adhere to a consistent system; yet, on the other hand, it gives people freedom and responsibility within the framework of the system.”

Collins’ idea about a culture of discipline and an ethic of entrepreneurship are exactly what is needed within an organization to make it agile and nimble. Think about it. If the organization is aligned and the contributing members are working towards a common goal with the freedom to make decisions, then how much more would the organization be able to accomplish? Call it agility, call it empowered employees, call it a culture of entrepreneurship. At the end of the day, it will accomplish more in less time. The great thing is that customers reward agile customer focus from informed and empowered employees. Employees are happier when they can do the work they were hired to do instead of spending half their time filling out forms or documents and waiting on approvals.

It’s the great business paradox of our day: We want to be nimble and get things done faster, but we must follow all the process and bureaucracy in place to make it happen.

I’d like to explore this topic further in future posts with some specific ideas about making an organization more agile to help promote eCommerce and Internet Marketing activities. Processes certainly have a place with the system of work output. But how can we make sure the process benefits us rather than owns us?