Advertisment

“A Good ALM Solution improves team productivity by providing only 'one version' of truth for everyone to work on” Shiv Sivaguru, HCL Technologies

author-image
PCQ Bureau
New Update


Advertisment

With tighter project deadlines and increased pricing pressures, how do you still deliver the same value or more to your customers while running a software project? We spoke to Shiv Sivaguru, who has a record of contributions to improvements in delivery practices on international software projects, to find out.



Q. What are some of the current development challenges organizations are facing?

Advertisment





The development challenges being faced by organizations are broadly based on changing customers expectations. There's increased pressure on pricing and shorter delivery lifecycles, which can no longer be one year or six months as it used to be. Customers also expect support for multiple platforms and multi-channel apps. Moreover, it's no longer about developing for a mainframe, or a desktop, etc. It's about extending existing customer apps with newer features on custom solutions or standard platforms they already have. The delivery team structure also has to change keeping this in mind. So there are more of feature-based teams or feature-based roadmaps delivering on a project. This is a direct result of the IT spending patterns of our customers. Most IT spending is about sustaining lights, and yet pressures of tech and industry that our customers operate in, means they have to come up with newer models for engagement, like Web 2.0, catching the Gen-Y, etc. This translates into leveraging what has already been invested on, by extending its functionality. At the back-end, you have to see how to structure the team to ensure fast delivery cycle. This requires inculcating multiple skills in the development team, providing a common development environment, which can integrate multiple processes seamlessly.



Q. What is your vision for providing an application development platform for developers to manage the shorter delivery cycles?



The biggest need is to bridge the organization's aspiration with that of the individual. An initiative like CMMI is driven more top-down, wherein the organization wants to mature the practices across the board. For team members, these are good initiatives that they can participate in and contribute, but they don't see any immediate benefit for themselves. So their needs have to also be taken into account--how can he/she be more productive, get feedback related to their own and their team's contribution and so on. Our vision is to have a common environment that can be used by all roles, contributing to a project. It is also necessary to have a common repository so that the intermediate work products are available to everyone at any point of time in same states. In other words a good ALM platform will provide these facilities at a low total cost of ownership.

Advertisment



Application development is no longer about one individual working on a project. Now, a typical software project could involve multiple teams located across the globe. Therefore, from an organizational practice perspective, we want to set up the right metrics/measurement based on activities that happen and not an estimate that people provide alone. The right measurements ensure that there's a balance and level of interest and creativity between individuals and the organization.



Q. What sort of a solution are you using at HCL to manage ALM? What sort of benefits does it bring to the table?



In mature software delivery environments when you commit to deliver you cannot say that “I'm almost 90% done”, etc, You need a connected vision of all phases of development to keep a track of things to be delivered as per the commitment. This is where the role of a repository, or a good configuration management practice becomes critical. As a result, almost all vendors are moving their offerings to a repository based ALM practice that handles development end-to-end, right from when the app is generated to its completion. The solution has to automate the whole chain.

Advertisment



Therefore, ALM is more of a platform, with individual tools that talk to each other. At HCL we cater to multiple customer needs that require multiple technologies and methodologies to be used. One of the key platforms we are standardizing on is Microsoft's Team Foundation Server (TFS) and Visual Studio along with its plugins.

Advertisment



Q. Building software is a team process where developers, testers and other roles needs collaboration. How does your solution help you out on this aspect?



The code in a software project is typically spread across multiple modules, with multiple teams working on it. Checking all modules of this code for various aspects, like requirements analysis, bugs, etc would be a task in itself if done manually. But if you have all your test cases, code, etc connected, it becomes easier to not only measure the impact of the change, but also manage it in a structured manner. For a globally distributed team, it also requires a protocol that teams use to communicate with each other. The designers and the architects might be using different tools to meet their job roles. So one of the challenges for any software developer is the need for collaboration. It goes beyond instant messaging, viz. I create a specification, and have the option of speaking to an expert on security to criticise it from a security point of view, whereas somebody else might look at it from a performance point of view, while another person might comment from a domain point of view, etc. This means that multiple people may need to look at the same document from different perspectives and record them. I as an author should be able to compile them into the same place. Moreover, it should all be traceable.



A good ALM would allow this sort of traceability and collaboration so that the transition from one role to another, particularly when say a tester says this is not working, and when it gets to the developer, the developer should also have environment snapshot of the tester to see his point of view, find the bugs quickly and fix them. In a traditional older setup, this back and forth between the tester and developer would waste a lot of time. If you're able to catch this early enough there are huge gains on time, and productivity also what you deliver and the cost of support required after delivery can be brought down. Productivity also improves at all phases as there's only 'one version' of truth. With TFS and Visual Studio we are able to achieve this and bring operational efficiencies in our development process.

Advertisment



Q. How important has Agile development been for you? What are you using for agile development? What sort of expectations do you have from the platform you're using for agile development?



We do projects in agile, and also have an agile center of excellence with agile practitioners who constantly keep advising customers on how to transition. The emphasis is first on how to bring agile engineering practices and second is cost/benefit that customers are looking at adopting from agile.



To be practical for a large organization, you need to have a right mix of agility with a certain amount of traditional process rigor. So agile is there on one side, and the traditional process oriented world on the other. A successful SI will marry the two, which is something we've done. Agile brings in a lot of good practices, but traditionally, people associate it with scrum, which is an iterative, incremental framework for product mgmt. Agile recommends good practices, test driven programming, test driven integration, etc. All of these are very relevant for configuration management system to support continuous integration of builds in a software project. So as and when changes are being made by different team members, the Configuration management system helps you have something that's compatible. So if one team member does something and submits the changes, it should not break something that someone else is working on. From the time you check-in the code, the quality metrics should be exact and should not break what has already been made. If it disturbs the equilibrium of whatever is being made, then it is not the right thing to check in. Your quality parameters therefore, should be designed in the repository such that it supports continuous integration without creating overload on the team.



Q. How critical is a configuration management system for maintaining your profit margins?



It's extremely critical for plugging the leakage of productivity which may happen in a team working environment. It is also very critical to have smooth handoff from different roles, get automated reports of work status, Management Dashboards etc. With TFS we are able to get different roles better connected horizontally and vertically and improve productivity which in turn improves the bottom lines. The roles are able to conclude smooth handoffs with proper traceability while the management is able to gets a good dashboard to take timely corrective action. If you look at the CMMI model, at the lowest level of maturity, one of the key practices expected to be matured is configuration mgmt. It therefore has a fairly crucial role to play in terms of profitability. Adopting a CM discipline would require projects budget for infrastructure and specialist for CM administrators. So it was here that we found an opportunity to offer something more like a shared service so that the good practices or benefits that accrued from the knowledge in one of the engagements could be used by others also. One way that our configuration mgmt discipline influences profitability is by reducing the cost of adopting some of these good practices. We reduced the number of tools we were using and brought uniformity in how groups were managing their configuration with TFS. So our TFS deployment is actually very sophisticated, with a nodal server at multiple locations connected together, and projects connecting to the closest servers. I'd like to look at our TFS deployment more from an ALM standardization and roll out perspective. Today we're probably at about 30-35% potential of what TFS can give us and we are getting great benefits at this stage.

Advertisment