Most organizations maintain separate departments for software development and IT operations – and not without reason.

Development teams are putting an increasing emphasis on speed and flexibility, thanks to organizations’ rapidly shifting needs for new technologies such as mobility. In contrast, IT operations departments have traditionally focused on delivering IT services with high levels of availability and stability.

Though it’s easy to see how these sometimes contradictory goals could create a wide gap between the two functions, some organizations are finding success by combining the two to create a combined function called devops.

As Cutter Consortium senior consultant Brian Dooley writes in a post on the CutterBlog: “Devops represents a convergence plateau in the state of the software development art, where development, operations, and the surrounding processes of QA are brought together in an efficient, converged process that provides important benefits.”

The Devops Agile Connection

In an interview with Global Delivery Report, Dooley said devops is more commonly found in organizations that utilize agile software development methodologies. That’s no surprise given the common goals shared by agile and devops.

These goals include: rapid availability and deployment of code, delivery of business value based on real need, efficient use of resources, the capability to make changes at any time during a project, constant testing, and an emphasis on collaboration.

“If you are interested in devops, you probably already have agile development processes in place,” Dooley said.

Dooley isn’t the only one who sees a close connection between devops and agile. The masthead of the Devops.com website reads, “Helping finish what agile development started.”

Devops is especially useful for small applications that need to be developed and deployed quickly, such as mobile apps, Dooley said. The devops approach won’t be as natural of a fit for large and complex deployments of business-critical systems like ERP or CRM.

“Linkages between development and operations can still be useful for those kinds of systems, but they aren’t as necessary,” he said.

While devops and agile development enjoy similar benefits, they also face similar challenges. The biggest challenges involve what Dooley calls “fleshware,” namely managers and/or developers who may not be comfortable with the enhanced levels of collaboration required for successful devops.

“The two groups often don’t really talk to each other. Coders develop the code and drop it off, and then they don’t want to hear about it,” he said. “The communications habit can be slow to develop.”

The good news is, said Dooley, “collaboration is implicit in supporting tools these days.” Vendors are increasingly connecting development tools and application management tools. For instance, IBM has linked its Rational software development environment with its Tivoli management environment.

Dooley suggests the best way to introduce devops is to begin with a small but high-profile project such as a mobile app deployment. Success on such a project is a good way to win executive support, which improves the odds of winning buy-in from both managers and rank-and-file workers.

There is a common misconception that Agile replaces the need for use cases with user stories. Questions on this topic have been posted on social network sites such as Skillsharks, blogs, Twitter, Facebook, etc. The question shouldn’t be “Do user stories replace use cases?” Rather, the question should be framed: “How do we leverage the power of use cases with user stories when developing effective Agile requirements?”

Many shy away from use cases within an Agile approach because they resemble the ways of elicitation and analysis from the Waterfall approach. However, regardless of how one approaches requirements analysis, the end goal is the same:  help business users/stakeholders identify their true needs and translate them into requirements. For Agile requirements to be successful, both must be leveraged to get to the heart of the most appropriate business solution that brings value to the customer.

According to Chapter 6 in the BABOK Guide, “…business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.” To be successful, a business analyst needs to have strong facilitation, information elicitation, and process design skills. These are the core elements to building effective use cases.

In Agile, requirements are progressively elaborated. Each iteration or sprint allows business users/stakeholders to better define their needs to ensure the most effective development of solutions. These iterations or sprints rely on the user stories that the business user/stakeholder “tells” to concentrate on features that users value and interact with directly. These short scenarios of user expectations are just part of the user story process.

User stories include two additional elements: 1) notes from further discussions about the story that help to clarify the expectations (Conversation) and 2) intent of the story and validation tests that will confirm to the user that the story, when delivered, does what it is expected to do (Confirmation).

Requirements Visioning in Agile Development

Before the Agile team begins to collect the detailed requirements that describe the features of the system, it is vital that the overall vision and purpose of the project is identified. This also includes the product vision. The product vision acts as the boundaries of the project in which the iterative, incremental work takes place. The product vision should answer the following three questions:
1. What describes the product?
2. Why is the product useful?
3. What features will attract customers to this product?

This is the first place we begin to see the power of integrating user stories that are being gathered with the elicitation technique of use case modeling.

Setting the product vision from a requirements perspective is the most important element when building a solution. This sets the parameters to ensure that we deliver what is needed as well as marks the end point when it comes to tracing requirements.

Use Cases In Agile Development

Use cases are diagrams that demonstrate the actors and their goals. Actors are typically people or systems, and the goals are what the actor is trying to achieve. Use cases in Agile help to define who needs to do what with the system and begin to identify the business value of that interaction.

On Agile projects, it is typically best to leverage the power of use cases not only from the project perspective, but also the product. From a project perspective, it is a great way to demonstrate, in a visual and easy to understand format, the scope of the “who needs what” for this project. From the product vision perspective, it is also great for starting to envision requirements of a system that is user driven as well as to identify Themes and Features.

In Agile, there are four levels of requirements. Themes are used to describe larger requirements that may include multiple features within it. Features are a collection of related stories. These two levels offer a great opportunity to utilize use cases because they can provide a simple visual representation of the product scope and allow for improved prioritization of the requirements.

The other two levels are a bit more detailed and are known as Epic and Story. Epic is used to describe a Story that is too big to get done within an iteration/sprint and needs to be broken down into smaller chunks. Finally, Story is the smallest valuable business requirement that follows the INVEST attributes.

The Six INVEST Attributes

Independent: Ensure the story can stand alone, thus avoiding the creation of complex dependencies with other stories.

Negotiable: Assume there will be ongoing negotiation about the priority, form and function that the story represents.

Valuable: Stay focused on features that are valuable to the user and not on the technical details meaningful only to developers.

Estimate: Keep the story discrete and clear enough to to develop and order-of-magnitude estimate for effort in resource requirements.

Small: For clarity, estimating and planning purposes, ensure the story does not become an epic.

Testable: Explicitly describe in the story the feature that is expected so it can pass a simple “yes” or “no” test.

Effective Agile requirements rely heavily on use cases and user stories. Remember that user stories focus on the features that users expect to be available when they use the finished product. They are meant to express short scenarios of user expectations that help business analysts on an Agile team dive deeper into connecting those expectations with delivering the appropriate solution value. Use cases are used to help with the value analysis for the user, thus enabling appropriate prioritization of the product backlog.

There is no set prescription on when exactly to use use cases and user stories. Both are required to help prioritize the product backlog, and both are used to better understand the customer need and where the customer places value on what needs to be delivered. Using use cases and user stories is needed on Agile projects; however the timing of when to leverage them is dependent upon the type of Agile project that the team is working on.

This information is drawn from a paper that can be downloaded in its entirety by visiting ESI’s website. The release of the paper coincides with the scheduling of ESI’s eight-course Agile Practitioner curriculum.

Nancy Nee, PMP, PMI-ACP, CSM, CBAP,  vice president, Global Product Strategy, ESI International, guides clients in the development and implementation of learning programs customized to their specific needs. Her solutions reflect the insight of almost two decades of PM and BA experience in healthcare, information technology, financial services and energy. For more insights from Nee, read Softer Side of Agile Development: Leading Collaborative Teams.

Application development is one of the most outsourced activities, according to recent surveys from Harvey Nash, Bluewolf and Computer Economics.

In an interview with Global Delivery Report, John Longwell, vice president of research for Computer Economics, cited a scarcity of in-demand dev skills and a need for speed as two big drivers for outsourcing application development.

Delivering applications faster was the top application development priority for attendees of Gartner’s Application Architecture, Development and Integration Summit, mentioned by 59 percent of respondents to a survey conducted by Serena Software at the event. Improved alignment with business objectives was the second top vote getter in the third annual survey, cited by 48 percent of respondents. The emphasis on alignment with business objectives marked a major shift, as it was the lowest-ranked priority for both 2011 and 2012.

Rounding out the top four priorities were expanding the use of Agile development methods and increasing innovation. These results would seem to bode well for nearshore application development. At delivery centers like the ones owned by TCS in Guadalajara Mexico, Montevideo Uruguay and Queretaro Mexico, Agile dev teams meet frequently with business stakeholders, establishing the kinds of connections that result in software that satisfies the stated business needs.

Not So Cost Conscious

In contrast, lowering application costs and moving apps to the cloud dropped significantly in importance when compared to Serena Software’s earlier surveys. Lowering costs, the No. 2 priority in 2011, fell three spots this year to land in the middle of the pack at No. 5.

“Squeezing out costs has taken a back seat to delivering what the business really needs – the delivery of quality applications. Speed and business alignment will take priority over development costs and efficiency—a first in the world of app dev,” said Miguel Tam, senior product marketing manager at Serena Software.

Other points of interest from the survey:

Release management is a key challenge for respondents. Nearly two-thirds of respondents said they are releasing more applications than before (with 11 percent noting they are releasing more than five times the number of apps over the prior year), while 47 percent reported they are actively working to improve their release management systems.

For the third year in a row, managing applications as a business process came in as the most important initiative for the coming year.

A big difference between Agile and other software development methodologies is Agile’s insistence on frequent communication between developers and the business constituents they serve. This results in software that better serves the business need.

Bringing business people and software developers together can be a challenge when they are located in the same office complex. So it’s easy to imagine the degree of difficulty that can result when they are located on different continents, a not-uncommon occurrence given companies’ frequent use of offshore resources.

The communication difficulty is lessened considerably if developers work from nearshore delivery centers – which is why the value proposition of a nearshore delivery model is especially strong when it comes to Agile development.

At a TCS delivery center in Latin America, development teams find that working in the same time zones as their clients makes it possible to meet with business stakeholders as often as desired. Many projects utilize daily “standup” calls in which developers and clients compare notes on progress. These short calls – a mainstay of Agile development — help avoid the kinds of misunderstandings that can result in time and budget overruns, or worse, software that doesn’t meet expectations.

One of our TCS development teams traveled to the offices of its client, a Fortune 100 health care company in the United States, at the outset of a project to meet their peers and create the all-important synergy that is required for any Agile team to succeed.

Their goal was clear and simple: build relationships with their counterparts and work on team integration.  After the team separated — physically but not mentally – they had established a good rapport with their U.S. peers. This scrum team has been working together for one-and-a-half years now.  Synergy has been always very strong, much as if they were all together in one place.

This kind of contact, coupled with the close cultural affinity that Latin American developers enjoy with their U.S. clients, yields an added benefit: a strong sense of teamwork that can be lacking in offshore delivery models and that helps boost satisfaction with outsourcing.

Few complaints about outsourcing involve cost or efficiency. When companies are asked to compare the abilities of external service providers with their internal staffs, external teams stack up well in categories involving work ethic, ability to follow established business processes and overall value. There is less satisfaction with external partners in areas like initiative and innovation.  In a recent survey from HfS Research, the biggest perceived gap between internal and external teams was “understands my business.”

This isn’t surprising, given that external providers often lack the broader context behind business requirements. That context is the “secret sauce” behind the success of nearshore Agile development projects.

Nearshore developers show a remarkable sense of ownership, strong commitment to their respective teams and a high degree of business understanding, given their close interaction with clients. Latin American developers are also often quick to suggest alternate solutions to business or technical issues, thanks to a culture that highly values innovation. They really enjoy researching and providing technical guidance, given their innovative nature.

When developers value the positive factors that agile methodologies provide — constant improvement, quick response to changes, recognition and collaboration — and stay in close touch with their clients via communication technologies like videoconferencing, instant messaging and desktop sharing software, the result is a solid and integrated team, no matter where the individuals are located.

As one member of a TCS development team based in Montevideo Uruguay said: “The more we can communicate and the closer our relationship becomes, the better I understand how my clients work.”

Rosina Marmion is a delivery manager for Tata Consultancy Services, based in Montevideo Uruguay. She has 13 years of experience in the IT field, including experience leading Agile software development teams.