Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Gauging the Impact

Written by Randy Wagner

Monday, 18 July 2005 16:00

The conduct of business occasionally causes us to alter our software development methodology. This requires some up front analyzing of the benefits and costs of various options and deciding which model is really appropriate for your organization. What factors need to be considered when choosing the best path? How does SCM process change based on the model? Who benefits? How can we assess the impact on existing process? What impact does it have on our tools?

Let's lay out one circumstance. Groovy Processing Company has a dozen sequential applications that allow it to process loans. Each application is dependent on data from its predecessor. In this way, changes to the code for Application 2 or 3 will affect other applications downstream. Changes are grouped by development effort across the applications and multiple development efforts may be editing common code concurrently. In other words, one development team may be nearing release as another development team, editing the same code, is just starting the dev phase. In this manner new loan products can be introduced in a market-responsive manner as soon as resources are available to begin work.

Enter the merger. Swell Loan Company also has a very structured environment. They run their releases per application, independent of the others. Development teams are dedicated to specific applications. Major efforts may be coordinated between applications but releases are quarterly, except for emergency bug fixes.

Both businesses have an IT group that supports how they like to do business. But both are looking down the barrel of trying to win the methodology battle. Making a change will impact how applications are developed, how teams are structured, how Change Requests are processed, who holds the power, what business can expect, and where the money flows.

Both lifecycles start out the same. Someone has a great idea and pitches it to the executive committee which is really just a senior Change Control Board. They decide it is a fabulous idea and approve the funding to move ahead. Then the road bifurcates.

Let's look at Groovy. In their mode, the project manager holds the power of the purse. He or she dictates the project schedule. Any change requests within the scope of the project are handled within the team. Requirements analysts, developers, testers, SQA, and SCM are all pulled from an available pool of resources. A project-level issue tracking system is set up. Change Control Board(s) (CCBs) are established with defined members and authority. The version control is set up to access the code appropriately without stomping on other projects’ work. Unique test environments are created to isolate project changes. An SCMP must be written for each project.

This methodology means the IT group can be very flexible to the business. Project managers have great leeway in controlling the factors influencing their projects. But it comes with cost. Individual development streams mean that as other projects and bug fixes go to production, those changes must be merged in before this project can be released. That requires a lot of development, test, and SCM work. In particular, team members must come up to speed on multiple applications which requires a longer ramp-up. Issue tracking repositories are shut down after production release, as are the CCBs. Standardization is more difficult because resource constraints may dictate that one project has separate system integration and user acceptance testing environments while another combines them.

Now look at Swell. Since each application is its own master, the decision from the executive committee is handed to a project manager who then must parse out the work to the application teams. He or she must go to the CCB within each application team and get on their release schedule in a manner that works for the effort as a whole. Application CCBs are static. Members know their application thoroughly and can coordinate changes from the various project efforts into the schedule. Issue tracking is done at the application level and is therefore a more or less permanent database. Developers, testers, SCM, and SQA are generally assigned permanently to specific applications. Test environments are unique to the application and stay reasonably stable. Version Control exists per application. SCMPs are written for each application and need only be updated for tool or organizational changes. Coding may require switches to turn functionality on if the other applications are not implementing at the same time.

This too has costs and benefits. It allows for much more stable production environments. Team members are isolated and understand their application. The version control tool isn’t generally subjected to cross-project merging, reducing potential leap-frogging in production. The downside is that if you miss this release cycle, you may have to wait 4, 5, or 6 months to hook the next one. And it’s harder to do full lifecycle testing for a project effort because each application has its own test environments. Project managers are much more at the mercy of the individual application teams. A project change request that impacts multiple applications means coordinating through multiple CCBs. Rather than utilizing a pool, teams are staffed for what is efficient for the application, not necessarily the organization.

In supporting each of these software development lifecycles, SCM needs to customize its approach. Process training is much more significant for Groovy than for Swell. Version control tools can be more generically configured for Swell. And while most of us want to avoid the subject, structuring by application may mean the creation of little fiefdoms that cause political battles. You really can’t gauge the cost of that effectively.

So how can you flesh out these changes before running down a path? Reading the literature on various methodologies is a good start but will never be enough. Meeting with the other functional areas and walking through it will allow the insights from each area to swirl through the process thinking of the group. And it will make it relevant to your organization. Some of the issues will be related. For example, merge issues for development are regression testing issues for the test group. That means merge coordination and release procedure adjustments for SCM. Time becomes a more vibrant player in the discussions as teams look at how they may be impacted by various processes. That may also mean we need to tweak service levels for SCM response times or frequency.

It is important that we recognize that we are not the only keepers of the process. The other functional areas are directly impacted. And each has personnel with knowledge and experience different from our own. Use the resources available. Get them involved in the changes early. Draw the sequences on white boards. We already know that people are generally resistant to change. Make sure we keep the process moving by not trying to solve the problems that only happen every two years. You plan for what can reasonably be expected but tweaking for every last possibility is simply unproductive. And include the business once you have the major ideas worked through. They are the ultimate customer and will need to be involved in the process. If you are moving toward an agile methodology, they’ll need to be much more involved than a more traditional approach.

Certainly there are many, many more choices of methodologies than those spelled out here. And, in the end, it’s rarely our decision which process will work for everyone. But it is our job to understand how different methodologies will impact SCM and what costs and benefits are incurred. It will impact our output, be it training, tool configuration, or just baseline reporting. And it will mean staffing impact for team members on the CCBs or the pooled resources waiting for the next project. We need to walk through the lifecycles and understand what is happening and why at each step. It also requires knowing your own organization so you can diffuse or avoid the battles before they happen. Whether the change comes from a merger, a tool being handed down, or just organizational growth, it’s important to be in front of it with answers. It’s part of providing value and good service.

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