Similar Tickets – How Can This Feature Help You In Supporting Your Customers?

February 20, 2012 by Leave a Comment

“…it would be great if it were possible to merge tickets that were similar, instead of just resolving as a duplicate or creating links between them; especially if the comments from the source ticket could be added to the target ticket, and any future requests for the source ticket redirecting to the merged ticket containing all the comments…”

“…I often get users creating new tickets to tell me more information about already existing ones. I have to copy/paste info into the existing ticket, and then close the new one. Would be nice to have a merge and close button…”

Sounds similar? Yes, these are a few common statements that developers post in discussion forums or help desks of the SDLC management tools or ALM tools that they use. BootStrapToday, which is also an SDLC Management tool, now offers Similar Tickets feature, which can solve such issues of similar tickets and save your time. Similar Tickets can accelerate your customer support quite a bit by addressing customers’ queries faster.

Many organizations today use third party chat clients like SnapEngage or GetSatisfaction or any other email/chat support tool to engage the visitors on their websites. You or your organization might be using one to ensure high customer conversion ratio from the organic traffic. Now, if you are a BootStrapToday user, every project in your account gets a unique email id. If you want to treat any project as support project, then you can configure your support project’s email id with any of the chat/email support tools that you are using on your website with the BootStrapToday email interface. Doing this will create tickets in your support project for all the requests from your customers.

This advantage extends into Similar Tickets feature of BootStrapToday to resolve the issue of following up separately with the tickets that are similar in nature (queries). Here is a snapshot of how it works:

  1. Similar Tickets is an intelligent feature which checks for more than 30% similarity of new tickets with the tickets already in the system.
  2. If a new ticket is 30% similar, then it gets the component of the most similar ticket.
  3. If the component exists, then it assigns the same component to the new ticket created into the system.
  4. Based on the component, the system automatically assigns the ticket to the component owner.
  5. If the component does not exist, then the new ticket is assigned to the project admin.
  6. The project admin can assign proper component to the ticket, which automatically gets assigned to component owner, and a notification email is sent to the assignee.

So, you see, all the queries can be intelligently managed and tracked inside BootStrapToday itself. This process automates lot of repetitive work for support team and leaves no chance of missing on valuable customer queries.

Every new ticket that is created from a customer query will most likely have a similar ticket associated with it already in the system. The new ticket will have links to the similar tickets associated with it, which can be used as a reference point by the user for generating comments. The support team can view the responses given to the customers earlier. This makes it easy for them to respond to the customers quickly based on similar responses.

An important point to note here is that if you see many similar tickets being generated, then you get an idea of some issues/problems early on and you may want to fix those issues quickly based on the customer comments.

What do you guys think?

Filed under Uncategorized Tagged with ,

7 Deadly Sins of Software Estimation in SDLC

February 15, 2012 by Leave a Comment

Steve McConnell in his book “Software Estimation – Demystifying the Black Art” points out that 20 – 30% of the software estimation errors come in by not estimating certain activities. This leads the team to be off target by 20-30% throughout their SDLC even before the project starts! And that is limited to 30% only if the estimation techniques are proper!

Software estimation is a very important step in any SDLC. It may include various estimation data such as cost estimation, effort & staffing data and project management data to arrive at the project schedule and delivery date. The proper estimate of efforts required leads to correct estimation of the project duration and the man-power requirement to deliver the quality that your customer expects. Though the word ‘estimation’ itself means that it cannot be a precise measure, but when we say software estimation it obviously means striving to minimize the standard deviation from what the customer actually wants at the end of the SDLC when the shippable product is ready.

So, what are those deadly sins of software estimation which can take your project way off the track? I am listing here the 7 most sinful of the many that exist.

1. Inappropriate Software Estimation Techniques

There are many kinds of software estimation techniques. If you choose the wrong one then the estimation will not be optimal for your project. For example, Basic COCOMO is suggested for organic projects with small and experienced team, and also for embedded projects with rigid requirements.

2. Using Only One Estimation Technique

Estimation is based on certain data points which are collected from various resources through various ways. Any estimation done using any statistical method has inherent biases which generally arise during the data collection stage and can influence the accuracy and reliability of the estimation. It is no different for software estimation. Different methods of data collection capture different types of biases. The best way to neutralise the biases in your data (and hence in the final inferences, which is estimation in your SDLC) is to use more than one estimation techniques. Some of the software cost estimation techniques suggested for the SDLCs are:

  • SLIM
  • COPMO
  • COCOMO II
  • Basic COCOMO

3. Choosing Wrong Data Collection Schemes

As I said earlier, reliability and accuracy of your software estimation will be a direct function of the quality of the data collected. Hence, depending upon the nature of your project and other factors such as product (project) objectives, organizational assets (people, development tools, etc.) and processes and policies, you should set-up your data collection procedure. For example, If you want to collect effort data, then you could collect the data from timesheets or the employee status reports. But you must sift that data to find out the actual hours spent on work.

4. Not Knowing the Software Requirements

Some projects may depend on fluid requirements and may require that the project SDLC incorporates scope to implement new requirements throughout the SDLC. In such cases, it is impossible to know all the software requirements at the beginning. So, if you come out with an estimation based on regular methods, you are definitely going to be doomed. This sin can be avoided if you consider using Agile SDLC. It is altogether a different matter, but do not provide estimation if you do not know what the actual software is.

5. Building Estimate on Past Projects

This sin is closely related to the sin #4. Sometimes you might not want to re-invent the wheel, and would want to base your estimation on past projects. This maybe a bad thing to do, simply because by doing this you are directly including the deviations and errors of the past projects, along with few inevitable variations which will anyhow occur in any software estimation due to human factor.

6. Overlooking Non-technical Reasons

While doing the effort estimation, it is highly sinful if you overlook certain non-technical reasons just out of oversight. Reasons such as paternity/maternity leave, employee attrition, lead-time to hire a new recruit etc., are easily overlooked whereas these are extremely important to consider during project effort estimation. A good approach would be to provide weightage based on probability of such patterns occurring in your industry.

7. Not Using Estimation Tools

A human is liable to err. The best thing to avoid errors in your software estimation is to use estimation tools.

Why don’t you point out more sins of software estimation, which you think are responsible for substantial deviations in SDLC?

Filed under Uncategorized Tagged with ,

9 Quick Steps to Evaluate a SaaS Vendor

February 13, 2012 by 2 Comments

SaaS way of delivering and consuming IT definitely has inherent advantages and therefore SaaS has seen a widespread adoption by the SMBs, start-ups and larger enterprises. But SaaS offers its own share of risks to its adopters, and this is because cloud computing itself is a relatively new way to offer IT services. It is going through a learning curve and is still evolving.

Often companies just look for the point solutions and its convenience through SaaS models, but forget to evaluate it for some very important aspects; companies fail to asses a SaaS vendor from many of its infrastructural aspects. The perception for SaaS – that it is convenient for procurement and instant to use, often prevents end-users from doing an in-depth analysis of the SaaS vendor.

Whereas SaaS is a very attractive proposition for many, but if there is a power outage or a server crash or a security breach at the point where the SaaS vendor’s application is hosted (the infrastructure that hosts SaaS application), then you may be shut away entirely from using the service and may yourself face a humiliating situation with your customers.

To mitigate the business risks that may arise, here are 9 quick steps for you to evaluate a SaaS vendor:

1. The Trial Version

It is said that with a SaaS vendor the relationship begins after you sign up for the SLA, unlike with a vendor for traditional on premise software where the future relationship depends on the maintenance and other terms and conditions of the SLA. Every SaaS vendor usually provides either a 30-day free trial version or a basic version which is free always with paid premium services – a model also known as freemium pricing model. Using a free version will give you a great idea about their features and customer support services.

2. Infrastructure

It is important to know where the SaaS solution is hosted – on-premise or at the third party hosting provider. It is also important to understand their server configuration and data center details.

3. Security

Another important aspect is to check the security processes that the vendor follows. Look for documented policies and processes for data security and ask for such detailed documentation to get it verified at your end too. It is important that your SaaS vendor provides 128-bit encrypted data security, which is the industry standard. Look for things like who manages their network connectivity, firewall, identity management system etc. The vendor’s data center must also have physical security arrangement system such as surveillance system and preparedness to deal with disasters such as fire and/or floods.

4. Back-up & Disaster Recovery

An ideal way to judge the disaster recovery management process at your SaaS vendor is to know if their hosting infrastructure is geographically separated – how well they are dispersed and how the back-up of the back-up data is managed between the dispersed infrastructure. It is also important to know how many network and firewall infrastructure providers your vendor has tied-up with. This back-up arrangement for security will help because if one crashes then there is always another for back-up.

5. Integration

It is not easy to uproot all the on-premise IT applications at once. Hence your SaaS vendor must ensure that integration of the SaaS application with the enterprise’s IT stack is supported.

6. Customization

This aspect is especially important for companies in the specialized verticals such as pharmaceutical industry and financial services industry. If you happen to be from such verticals, then you should look for the customization options that your SaaS vendor can provide you so that you can leverage your SaaS application to the maximum with the rest of the IT stack.

7. Cross Platform Compatibility

If you are going for SaaS, then you would want it to perform equally across all types of operating systems and browsers. You would want to leverage the mobile work culture while moving to SaaS and hence would want that your SaaS application must work well on any kind of OS and browser so as to have a cohesive collaboration among the distributed and mobile teams across your organization.

8. SLAs

The SLAs (Service Level Agreements) should clearly lay down the obligations and other terms and conditions for both the vendor and the customer. You must also assess if all the security, back-up, disaster recovery and other infrastructure details are supported by the vendor’s infrastructure hosting provider or not.

9. Customer Base and Support

A good customer base indicates that the SaaS vendor’s service is good and if there are customers for longer durations then it is a very good indication that the SaaS vendor is actually reliable. You should look for some references from existing customers as well as asses the quality of their customer support during the trial period.

What is your take?

Filed under Uncategorized Tagged with ,

API Management Tools As SaaS – Is There An Entrepreneurial Opportunity?

February 10, 2012 by Leave a Comment

Richard Branson’s quote – Business opportunities are like buses, there’s always another one coming – is quite famous in the entrepreneurial world and is so true. Innovations keep happening; it is an on-going process which can be described more appropriately as a kaleidoscope where there is a possibility of creating infinite number of designs through various combinations. Market opportunities are similar where they keep taking up concrete shapes based on many combinations of previous evolutions – whether it is a technological evolution or is an outcome of the technological evolution.

I am writing on entrepreneurship here after a long time. And this is because I could not resist writing about cloud computing (which I call as a disruptive innovation in the way IT is delivered and consumed) which seems to be generating a network of many new services and product opportunities. For example, the shift in consumer behaviour, mobile work policies and wider acceptance for SaaS products are all changing the requirements landscape for software development; it is pushing use of Agile and DevOps to enable businesses and is the cause for the rise of developer platforms – both these areas calling for more start-up activities.

With the current stage of adoption of cloud computing and SaaS, API Management is an upcoming area for entrepreneurial actions in the cloud computing industry. This article will focus on API Management tools in the cloud as the opportunity for more start-up activities.

Today, the enterprise world is buzzing with API activities. APIs not only define the B2B integration they also help in developing and integrating applications for mobile devices. The infrastructural API Management tools already exist in the market and they provide infrastructural solutions to support many aspects of API management. But if the API management tools could be available as SaaS it would carve a steep growth curve for itself. The simple reasons for this being:

  • Cloud computing is here to stay due to its inherent advantages
  • Being available as SaaS provides instant access to the tool, providing a fast turnaround solution to the end users
  • Low upfront cost and elasticity (to scale-up or scale-down) on-demand makes the end-user agile and competitive
  • SaaS helps in optimizing computing resources for the end-user

But, as with any other SaaS product, entrepreneurs should consider following areas carefully before deciding to launch an API management solution through SaaS delivery model:

  1. The cost of using the solution, if the APIs to be delivered increase, should not increase exponentially for the end-user
  2. The data going through the APIs, especially if the end-user data is sensitive, should be highly secured
  3. More customization options should be available to the end-user as seamless API management tool integration with the rest of the IT stack (whether on-premise, in cloud or as hybrid) is very important to provide better performance.

What do you think of API management tools in the cloud? What aspects should be addressed by entrepreneurs so that their solution can provide differentiation and hence add value in the network of cloud computing solutions? Please share your thoughts.

Filed under Uncategorized Tagged with , ,

10 Advantages Of Agile SDLC

February 9, 2012 by 1 Comment

Long since software development has come into mainstream it has primarily followed sequential development techniques through the development lifecycle. To be very specific, the SDLC (or software development life cycle) has followed waterfall approach most, where each phase of SDLC is completed before the next stage begins. For example, before any coding begins, the requirements gathering and the architecture design are completed. Though this ‘assembly line’ approach to software development was advantageous in early days of software industry it seems to be getting obsolete for the current generation of software development needs.

In today’s world, traditional SDLC models such as waterfall model, pose a lot of challenges and limitations. It limits the teams from revisiting the stages of SDLC as the traditional approach allows the teams to finish every stage before beginning the next stage. The teams do not revisit the previous stages. The fast paced technological changes in our markets, the increased use of embedded software in devices and the ever increasing uncertainty in the market place makes it impossible for the customers to provide all the requirements at the beginning of the SDLC. By the time the software is estimated to be ready, if developed via waterfall SDLC, it is quite likely that the feature/functional requirements of the software become irrelevant for the customer by the time the software is released.

Agile SDLC evolved out of these experiences in the real-time project development by some of the software development protagonists. Agile methodologies propose to develop software through iterative approach. The entire SDLC is followed in incremental way by dividing the SDLC into cadences of work. At the end of each cadence or iteration the teams deliver a shippable piece of incremental work to the customer. This process leaves enough scope to keep requirements gathering a continuous process and helps the stakeholders determine the course of the software being developed. Unlike the traditional software development approach, in Agile the teams revisit the complete SDLC as a result of providing iterative incremental work that is shippable at the end of every iterative piece.

Together the advantages of Agile SDLC can be listed as under:

  1. Agile helps to speed up the SDLC phases and bypasses process steps that add little value to the project.
  2. Usually Agile methodologies promote less formal culture and encourage collaborative team approach.
  3. Agile facilitates smooth flow of knowledge sharing.
  4. Engages the stakeholders continuously so that the new requirements are gathered faster and there is no scope for guess work by the teams.
  5. It incorporates frequent and rapid changes into the SDLC for product functionality and features.
  6. Saves cost, time and efforts by following iterative incremental work delivery and thereby identifying deviations early.
  7. Redistributes leadership at various levels within the teams.
  8. Increases cohesion between the teams to deliver on time.
  9. Follows crisp and flexible documentation policies which save time.
  10. Provides the end result of higher quality of the software delivered and a highly satisfied customer.

Looking at all the advantages and the limitations (of the traditional SDLCs) that Agile overcomes for today’s development landscape, it is understood that most of the Web 2.0 e-commerce and web applications are being developed using Agile SDLC. According to an article on PR Web, industry leaders such as Xerox and Microsoft have switched over to Agile methods simply because it saves them cost and also produces better products. If your company is still following traditional models such as Waterfall model, then the inefficiencies in your development processes will be obvious and you may not be able to meet the customers need precisely.

Please share us your thoughts on whether Agile SDLC should be followed by all type of organizations in the industry.

Filed under Uncategorized Tagged with , ,

SDLC for Cloud Computing – How Is It Different From The Traditional SDLC?

February 6, 2012 by 2 Comments

SDLC (Systems Development Life Cycle or Software Development Life Cycle) is a framework that defines tasks to be performed at each step in the software development process. It is a set of processes to be followed by developers for each step of the SDLC such as Planning, Development, Documentation, Testing, Deployment and Maintenance. That is the traditional SDLC as we know of. But will traditional SDLC frameworks be suitable completely for the cloud SDLC? Logically speaking – no. Next question that arises is – how is traditional SDLC different from Cloud SDLC?

To answer this question it is best to first understand the crux of the matter – the root cause of why SDLC methodologies have evolved, the fundamentals of cloud computing and why cloud computing has become the de-facto computing and application environment.

Cloud computing is a paradigm shift in the computing world and brings more scalable, flexible and yet robust environment for developing web applications. It provides almost instant access to the software and development environments, by providing multi-tenancy of the virtualized servers and other IT infrastructure. Specifically, PaaS (Platform-as-a-Service), the development platform environment in the cloud, encourages use of Agile methodologies. Agile and PaaS together add great value to the SDLC processes. They help to reduce costs for enterprises in the long run and help in increasing developer productivity at the same time.

SDLC is management of development stages while using different kinds of methodologies which best suit the needs of different projects. An article on Testdog.com explains SDLC wonderfully by calling it a management roadmap. (Also read 2 key differences between SDLC Management and ALM). According to the roadmap analogy, you can say that SDLC gives you route options that you can take to reach your destination and also provides options for the mode of travel. In software development scenario, SDLC frameworks (roadmap) present you with methodologies (route options) that you can choose depending upon the requirements of your project.

In today’s fast changing technological world, the need for faster development processes, higher developer productivity and adaptation to certain technological trends, makes it even more important for the development teams to have the flexibility and robustness of cloud as well as maturity in SDLC framework which can be accommodated in the cloud computing environments.

Keeping these crucial factors in mind, SDLC for Cloud Computing will be different than the traditional SDLC in following ways:

Inclination towards Agile Methodologies:

Cloud SDLC can utilize methodologies such as Agile SDLC (using SCRUM or IBM Rational Unified Process). These are designed for iterative approach to development and fast deployment lifecycles. To bring operations on the same table, use of DevOps should be specified in cloud SDLC frameworks.

Customizable SDLC framework for different stages:

Cloud computing SDLC must have the capabilities to be customized according to the requirements of the project due to change in the effort levels and implementation speeds. In other words the elasticity and robustness of cloud computing environment (to be able to scale-up and scale-down on-demand) can best be utilized if the SDLCs for cloud are customizable in the integrated IDEs and ALMs in the cloud.

Installation and configuration guidelines

SDLC for cloud must provide implementation approach and guidelines for installation and configuration of the cloud environment that is being erected, depending upon its size. The guidelines must ensure that installation and configuration of infrastructure and application environment is completed appropriately for different stages of SDLC including operations and maintenance. These guidelines are the key to differentiating SDLC for cloud from traditional SDLC. This is so because the infrastructure set-up for computing environments and other application environments in the cloud are very different from the traditional on-premise IT stacks, as cloud is based on distributed network and virtualized environment allowing multi-tenancy.

What is your take?

 

Filed under Uncategorized Tagged with , ,

2 Key Differences Between SDLC Management and ALM

February 2, 2012 by 3 Comments

People often get confused between the terms Software Development Life-cycle (SDLC) Management and Application Life-cycle Management (ALM). It is very common that the two are used interchangeably when they should not be. This is because the difference between the two acronyms (both associated closely with the life-cycle of software engineering projects) never gets highlighted well.

Wikipedia defines the two as follows:

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

The systems development life cycle (SDLC), or software development life cycle in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.

According to these definitions, ALM is a process which clubs business management with software engineering and hence manages the entire life-cycle, whereas, SDLC is a process that creates information systems and hence manages the development stage only. In SDLC the business aspect is not integrated in the process. SDLC itself needs management on case basis. The differences can be brought out more clearly in two ways.

Basic difference

At the outset, ALM is considered as a superset, one that should include one or more SDLCs for any system development or software application development. ALM is a process that starts from the very beginning – from definition of the application, till implementation, maintenance and application retirement. To elaborate this, let me draw an example from warehouse management for a company who provides digitalization service for all your important documents, accessible on-demand. At the back-end, this company will need a sophisticated physical warehouse storage system for safely keeping all the documents in files and folders.

In this case building a warehouse is the application and when this company decides to build the storage warehouse, the ALM process sets-in. Next, every type of document filing will need certain parameters for storage depending upon their utility and level of criticality. Each of these file storage systems can be seen as separate projects, requiring different models of SDLCs, depending on their specific deployment needs. These file storage systems together will form the complete functionality of the warehouse.

ALM engulfs all the smaller parts which come together to make the application work, and which need their own SDLC frameworks to be developed and deployed. Each SDLC (which by itself is a process and can be seen as components of the larger whole – the application) needs separate management. ALM oversees this entire process to deliver the end user value.

In short, the gamut of the ALM is the entirety of the application right from inception of its idea till its seamless functioning to deliver the end user value. SDLC Management is management of separate SDLCs. Hence ALM and SDLC Management can be defined more appropriately as follows:

ALM is a superset which wraps together the fragmented SDLC Management as processes, and integrates them ensuring delivery of end user value and maintaining the same.

SDLC Management is the management of the processes during the development stages only for different modules/components of the application.

Difference in phases

The second way of highlighting the difference can be by pointing out to the phases where ALM and SDLC Management play their roles. ALM is associated with the management of the entire life-cycle of an application which includes development phase (and therefore, SDLC Management also) along with other phases of application’s existence, such as maintenance and retirement. SDLC Management is associated with the management of the life-cycle of the development phase only of the application. Even if there is only single development project that has to be completed to develop any application, it will entail ALM as well as SDLC Management in its life-cycle.

Do you agree? Please share your opinions here and share.

Filed under Uncategorized Tagged with ,

The Secret To Implementing Effective Business Analytics (BA)

January 30, 2012 by 2 Comments

Business Intelligence (BI) and Data Analytics are surely gaining higher importance with the businesses worldwide. Importance of data mining and data enriching have never been felt more strongly before with zetabytes of data being created every day from various sources such as social media platforms and mobile devices. Considering BI and data analytics as pre-requisites for Business Analytics (BA), it is clear that the discipline of Business Analytics will catch more prominence as a practice in the corporates.

With the cloud computing as the next norm in IT, access to business analytics services will also be demanded in the cloud. The convergence of large data warehouses and business intelligence tools and processes is inevitable. But the question is, is Cloud Business Analytics already a mainstream? If not, then what do current trends say about its future?

Evolution of Business Analytics as a Practice

According to a research program conducted by Bloomberg Business Research Services in May 2011 (and as published by SAS in a whitepaper – The Current State of Business Analytics: Where Do We Go From Here?), some observations stand out and throw light on very important aspects of BA in organizations. One of the important insights is that BA remains in emerging state as far as using the technological tools effectively is concerned. Though as a discipline BA has gone mainstream, but many organizations still use traditional technology tools, Spreadsheets being the most common. Those organizations who do use more sophisticated tools do not know how to apply the results. Moreover, many organizations find it difficult to get proper talent for analytics.

Higher acceptance is seen by large enterprises. But the preference for BA is growing. According to a report by International Data Corporation (IDC), the world business intelligence (BI) tools market generated more than $4 billion in revenues in second half of 2010. For the same year, BI tools market grew by 12.7% year on year. Though the growth rate may seem modest, but it is the first time that the BI tools market has surpassed the $4 billion mark in six months itself. BI tools being the pre-requisite technology for enabling better and complete application of BA, the report by IDC indicates bright prospects for the BA market worldwide through the next five years. BA was reportedly one of the top IT priorities in 2011 for most organizations.

Why in the Cloud?

Biren Gandhi in an article – Cloud: A Catalyst for Commoditization of Business Analytics, has written that BA today is about creating value at the intersection of multiple business domains for business optimization and to derive sustained competitive advantages in the marketplace. Though organizations are sold on the importance of practicing BA for better business performance, but to move from just managing business domains to getting better business insight and planning for reducing costs has many roadblocks. Those who do use BA may not be getting ‘effective’ results out of it because of roadblocks such as lack of maturity of BA tools itself or high cost of owning them.

In the research program conducted by Bloomberg Business Research Services in May 2011, it was found that 51% of the respondents found the use of business analytics as somewhat effective. This can easily lead to the inference that either the tools are not mature (and hence not effective enough) or the the cost of adopting and provisioning new tools based on business needs are high. The BA tools vendors can plug the market gap by providing BA solutions in the cloud. Cloud can actually act as a catalyst for meeting the growing demand for BA as a discipline while keeping operating costs low for the customer organizations. Top BI tools vendors such as IBM, SAP and Oracle can add great value if they host their applications in the cloud. This will greatly facilitate better access to information across the organization and will not confine BA process and the resultant information within the functions or departments.

As always, we would love to hear your thoughts on this. Please share.

 

IMAGE SOURCE: http://www.computerweekly.com/blogs/open-source-insider/2010/10/open-source-business-intelligence-on-the-mobile-map.html

Filed under Uncategorized Tagged with , , ,

Key Practices for Agile ALM for Improving Productivity

January 27, 2012 by Leave a Comment

We have been talking about Agile ALM for quite some time now. Of course we believe that the Agile ALM will become a requisite for accelerated application delivery coupled with superior software development quality. In fact, the future of application development or software engineering holds a strong case for hosted Agile ALM.

The few crucial technology trends have changed the needs of the businesses. It is a pressing need for the businesses to be able to adapt to the market changes and deliver faster to stay ahead of competition. Hence they need to build a capacity to switch to new software and place processes at a faster pace. This creates a demand for developers of the vendors or in-house teams to be more productive. This increased developer productivity can be achieved only when it is supported by appropriate processes and tools.

All these reasons not only make it necessary to use ALM by all types of businesses, it requires vendors to integrate Agile methodologies in the ALM tools and adopt some key practices to implement Agile ALM which support people and processes for improving productivity.

Traditional ALM has always enforced pre-defined standardized processes through tools and people had to adopt software development based around the processes and tools. The end result of software delivery would never be what the customer has been looking for. Though the pre-defined processes would concentrate on maintaining certain levels of quality, often it would lead to delayed production and sub-optimal delivery of software to the end-user. But the traditional method of using ALM will not work in the wake of new trends. Organizations which focus on supporting people and processes through Agile ALM will improve productivity and therefore beat the competition.

“]

A Scrum in Rugby union [Image Courtesy: www.en.wikipedia.org

More agility and impromptu strategies to evolve project specific processes is required in software development lifecycle. It is almost similar to the experiences originating from field sports.  The word Scrum (part of Agile methodologies) has actually been derived from Rugby.

Agile methodologies focus on developing processes and supporting people through tools. They focus on continuous delivery of the software so that the end-user feedback is received at early stages and the changes can be incorporated faster. It is important that Agile is combined with ALM to achieve increased developer productivity. A successful roll-out of Agile ALM requires its vendors to equip organizations by incorporating scope for following suggested vital practices. These practices are based on few of our observations and are congregated from the whitepaper – Redefining ALM with five key practices – published by ThoughtWorks Studios:

Evolve Processes

Agile ALM recognizes that the processes for two different software engineering projects cannot be same. Hence Agile ALM tools must be such that they enable the teams to discover and build their processes progressively. The Agile ALM tools must enable the teams to construct possible roll-ups for reviewing and governance which gives them a chance to reflect and improve upon their processes and also incorporate changes at short intervals that may be suggested by the stakeholders. This flexibility for continuous improvement is essential in Agile ALM tools so that the true benefits of Agile ALM are derived by the organizations implementing it.

Incorporate Heterogeneity

The second good thing about Agile ALM is that it appreciates presence of heterogeneity in different projects. For example, if an organization from Life-sciences industry wants to launch a new SaaS CRM product, then development work may happen based on loosely defined requirements. In this case, the team will need to come out with a prototype, only to improve it based on continuous feedback from a focus-group. On the other hand, if the same organization wants a feature enhancement in an existing product, then the team will have to work on very strict defined processes. Therefore, heterogeneity of situations makes it necessary that the Agile ALM tools also embrace heterogeneity so as to let different teams evaluate and build their own processes.

Collaborative Approach to Management

Flexibility to evolve processes under heterogeneous projects also facilitates collaboration among the team members and stakeholders at every stage of the software lifecycle. The collaborative approach of Agile ALM ensures continuous delivery of features weekly or even daily. It makes sure that the end product does not deviate from the requirements laid down by the end-users. Agile ALM tools should facilitate orchestrating of the entire development lifecycle, instead of stiffening the teams with pre-defined processes that come with traditional ALM tools.

What do you think should be a part of best practices for rolling-out Agile ALM in organizations? Please share your thoughts.

Filed under Uncategorized Tagged with , ,

Enabling Business With Agile and DevOps

January 23, 2012 by 6 Comments

Innovations create new ancillary needs and if it is a disruptive innovation it creates entirely new markets. According to Wikipedia, disruptive innovation is defined as,

“A disruptive technology or disruptive innovation is an innovation that helps create a new market and value network, and eventually goes on to disrupt an existing market and value network (over a few years or decades), displacing an earlier technology. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect, typically first by designing for a different set of consumers in the new market and later by lowering prices in the existing market.”

Disruptive innovations create products which perform badly in the near term but ultimately change the industry and create a new value network of products and services around itself. The best example of a disruptive innovation is iPad by Apple, which created an entire new market.

In the same vein it is completely reasonable to say that Agile methodologies are also a part of disruptive innovation in the field of software development, creating new value network and improving the service. It takes the traditional waterfall approach to software development to a different level. Agile defines new set of methodologies through iterative approach to software development and brings in improved developer productivity and better software quality. It is even said to bring hyper-productivity in some teams.

Agile methodologies are said to fix the problems that arise out of software development life-cycle (SDLC) between the customer and the developers. For instance, it is next to impossible to collect all the information regarding the application to be developed right at the beginning. There is a big element of uncertainty at the customer’s end too because of which the customers (or stakeholders) need their vendors (or in-house developers) to be ready to incorporate changes rapidly into the software design. It is therefore imperative that there is a continuous customer engagement and at the same time it is important that the developers adopt changes rapidly. For this developers need to have flexibility incorporated in the SDLC and Agile methodologies bridge this gap.

The whole concept of Agile is based on the fundamentals of collaborative self-organizing and cross-functional teams throughout the organization. If there is any disconnect between the teams involved, then Agile’s vision of accelerated delivery gets defeated. When you talk about operations side of the software development life-cycle, then this disconnect is often felt and this leads to the slowdown of agile processes, as the operations team is unable to cope up with the continuous deployment cycles required out of sprint-approach to software engineering. (A better explanation is given in 5 Steps on How to Achieve Hyper-productivity in a Team).

Image Courtesy: www.en.Wikipedia.org

Here comes the growing need for DevOps. DevOps can be understood as a bridge between the developer teams and the operations team of the SDLC. Under the traditional approach, the development team writes the best of code and hands it over to the operations team to deploy. Often the code does not perform as per the expectations either because of infrastructure issues, lack of version support or architecture mismatch or simply because of lack of continuous collaboration between the development and operations teams, which leads to issues in reporting, security, back-up and provisioning.

DevOps try to solve this problem and avoid failure of the codes at the deployment stage. It aims to provide framework for fostering cooperation, learning and co-ordination between development and operations group in order to bring in more efficiency. DevOps environment helps system administrators and developers to build relationships, processes and tools that help them to collaborate better. DevOps models especially benefit processes like automation, capacity planning, back-up & recovery, security and provisioning as it improves the quality of interactions between the development and operations teams.

Due to some crucial technology trends and a foreseeable paradigm shift towards developer platforms, adopting Agile ALMs will become a necessity with many organizations. It will be easier for the SMEs and other micro organizations to adopt the Agile ALMs in the cloud. But the ‘disconnect’ between the development and operations will still be felt and they too will need the DevOps to run Agile effectively. In fact the SMEs will create a demand for DevOp tools which are integrated with other Hosted Agile ALM tools or at least be interoperable so that they do not increase the cost factor significantly.

Large enterprises who have their own customized IT stack, may find a stronger need for scalable and robust DevOps with the option to choose from cloud model or on-premise traditional model.

What is your opinion on demand growth for DevOps?

Filed under Uncategorized

← Older posts

Follow

Get every new post delivered to your Inbox.

Join 41 other followers