Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Finding the Balance

Written by Randy Wagner

Tuesday, 20 September 2005 16:00

How much automation is the right amount? How much is too much? Automating parts of the lifecycle, or just our CM work, can help steer our customers onto the right path, avoid pitfalls, or simply save time and effort. Many things can be done but we need to look at what should realistically be done and identify what shouldn't. It's good for our customers and good for us.

The number one thought to keep in mind is that automation will only ever be as good as the process it automates. Many of us have done some scripting, or a lot of scripting, in order to reduce our own work load, or our customers' workloads. It's easy to learn a scripting language and go merrily down the path of automation. Henry Ford's moving assembly line was precisely about doing this. But before we expend the automation effort, we should review our process to ensure that what we are automating is right for our customers.

The number two thought to keep in mind is that automation should be cost effective. Quite often we see a great scripting technique or "borrow" tool ideas from someone else to adapt to our own needs. But is it something worth automating? If it's something that takes an hour to do manually, but is only done quarterly, how long will it take to script or tweak the tool set? Certainly you won't know exactly how long it will take from the outset. But if you think it might take you 8 hours to get right, that's a full day to do something that will take you two years to make a "profit" on. How often you do something and how much time you save should be considered before you leap into it. Set a maximum for yourself. If you expect to complete the tool adjustments or scripting within 3 hours, and you reach that deadline but are really no where near your goal, reconsider your task. Effectively, you are project managing yourself or your team.

So how do you identify the right candidates? Return on investment. Looking through your lifecycle, identify the points where users have the most confusion, cause the most rework, and repeat actions on a daily basis. As my old boss loved to say, "Find the low hanging fruit." Can you integrate your toolset to import requirements into your testing tool? Can your testing tool integrate to your issue tracking too? Some things are more serious projects, others are as simple as push button deployments for test leads so you don't need to be at your desk when someone needs a new release.

Decide what it is you are aiming for. What is this automation going to buy you? Does it allow you to work on other things while it completes a task for you? Does it ensure completeness of activities? Is it intended to reduce errors? Be sure to take a serious look at what your payoff is really supposed to be. A friend of mine recently decided to trade in his full size vehicle on a more fuel efficent model. After breaking down the number of miles actually driven, the fuel usage difference, and increase in monthly payment, we identified that it would take about 56 months to break even. At which point he finally admitted the new one was just a really cool car. The point is that while it may be really cool to do something, it may not really be in our best interest. It might be an ego thing or just a pleasant diversion from dull work.

Part of automating tool sets within the lifecycle is the idea of making sure each step is done fully. But that can sometimes get you in trouble. Extra layers in an approval sequence may mean later, and necessary, activities cannot begin until the previous ones are completed. Is that viable for your organization? Perhaps you have post production activities that need to occur in order to filter certain code changes back to the development group. Would those activities be done expeditiously? If not, you may have developers starting from a false baseline. In that case, your automation could be decreasing group productivity. It's often hard to identify these weak points in advance. Be sure you have the means to address them after the automation is implemented.

Are there things that cannot be automated? Let's hope so! That would mean both an end to creativity and potentially our jobs! Does the automation need some flexibility built in? Perhaps you are automating a build and release process. Certainly there are differences between activities for a development release and a full customer release. Are there varying types of customer release? Maybe there should be and maybe not. Full customer releases usually require more things which means more space used. Perhaps all the variants don't need to be generated for every release. Can you tweak the make script to adjust for build type? What if you need to release subcomponents at different times or the full release at different times to different locations? Not only might that not be something to automate fully, it may not be possible at all.

Ultimately automation is just like any tool. It has its uses. And it has times when it shouldn't be applied. Get to the bottom of what you are trying to accomplish. Understand how it will benefit both you and the organization. Maybe you do some things because they are high visibility instead of truly productive. But give it some thought before diving in. The water may be deeper than expected.

Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.

Set as favorite

Bookmark

Email this