A Business Technology Place

4 Steps for Organizational Agility

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.

Agile Building Block

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?

  • What are your thoughts on migrating a team to agile processes? I agree that people become comfortable with the tools they use. Personally, I think that becomes a very big issue when you try to change too much of the process. Ultimately one can be ‘more efficient’ doing it a particular way but the downtime of changing too much might not jive with business. Also, one might reject the ‘new way’ if there is too much change because they are not feeling productive. I’d like to hear thoughts on how much new process can be introduced to a team at a time. Or has there been success with just going cold turkey?

  • My experience with trying to incrementally change development teams towards an agile process has not been favorable. Of course I never achieved management support either, so it was doomed from the start. What happened in the end was they renamed the enhancement list to a backlog. Then they said they wanted to target 10 week release cycles. In the end, the release date was determined after going through requirements, analysis, and estimates.

    I think on a team-by-team or process-by-process basis it would be easier to change out the system wholesale. But it’ll only work if you get management on board and the team members trained and behind it. (Steps 2 and 3).