Let’s have a look at some major considerations that any enterprise making an Agile shift must tackle:

• Empowering self-managing teams in a distributed environment
• Measuring the benefits
• Applying Agile in a heterogeneous tooling environment
• Planning in an Agile world
• Quality in Agile – A new paradigm for QA
• Managing a successful transition

Empowering Self-Managing Teams in a Distributed Environment

As an organization begins scale its Agile efforts, teams needed a better way to collaborate, share information and manage their work. The whiteboards, corkboards, post-its and index cards used by many Agile teams are fine for those that are co-located, but they can't scale as more teams make the transition. Self-managing teams make several decisions and changes in their “plans” each day, and keeping everyone on the same page and providing cross-project visibility is becoming increasingly difficult.

An enterprise project management and execution application that supports both Agile and traditional models of development is required. As waterfall, iterative and agile projects will co-exist, they all need to be managed at the same time using the same metrics. A lightweight, easy-to-use project management tool that sits on top of traditional ALM tools can help to plan releases and sprints, manage the backlog and user stories, and collaborate with burn down charts and corkboards. It is important to support the way Agile teams work, empowering them to be more effective at their jobs while automatically giving management and executives visibility into their progress. Agile teams need a daily “workbench” where they can chart progress against the daily plan, keep updated on changes, and stay on the same page throughout the execution of the sprint, so the teams can be more efficient.

Empowering teams in such a way will also significantly reduce the time and effort teams spend communicating with customers and business stakeholders. Rather than having several conversations with a customer to update them on sprint progress, teams can involve their customers in their processes, including them in the sprint reviews which are conducted using the team boards, backlogs and burn down charts.

Measuring the Benefits

The biggest fear in going Agile is that you will lose control. But, the reality is that you never really had control in the first place. Project managers build schedules, but there is really no connection between these dates and windows and what is going on underneath. To achieve the ultimate goal of its Agile transformation – to get better at predictably delivering high-quality software – it is necessary to get visibility into processes, establish a baseline for performance and be able to measure progress.

Plenty of data is already collected from the tools the teams use. However, only by putting an infrastructure in place can teams constantly analyze current and historical data across all of the organization’s projects, and present actionable information that delivers true value. (This data can include key ALM metrics, including quality trends such as defects, code coverage, and test automation, as well as performance trends such as team velocity and schedule variance.) Capturing and exposing metadata from test automation tools and including it in meaningful ways will add another quality dimension to the metrics. Automatically collected data from the tools teams can be used to manage their work, and can help managers and executives avoid unpleasant surprises, prioritize and make quick decisions. Instead of spending two weeks working with their reports to gather status information and create PPT decks for monthly operations reviews, executives can get the relevant information at their fingertips – all the time.

Applying Agile within a Heterogeneous Tooling Environment

Most enterprises use a mix of tools and processes to complete, manage and store their work. Different teams manage code and changes in multiple, separate instances of repositories. Through release planning and tracking changes constantly, and the relevant data is housed in several different places.

In an Agile environment you need to have sound engineering practices and tooling because almost immediately, Agile exposes those areas that need greater attention. And how you deploy and structure your data will determine the accuracy and scale of your project. Because the process of shifting to Agile must have minimal negative impact on the organization’s ability to maintain its aggressive release schedules, trying to standardize and consolidate tools and repositories all at once in order to transition to Agile usually is not an option. It would be too disruptive. Yet, to succeed at a transformation and become a more effective organization, it is necessary to establish certain standards and identify ways to improve in some of the core areas of ALM.

The first step is to define standards for data descriptions – uniform definitions for different activities and assets across the organization. Use a single definition for goal stories, requirements, user stories, etc. This helps to make it easier for teams to understand each other’s work, and allow them to manage dependencies across teams. Next, use a standard management console for all of delivery projects. Stories, tasks, assets can be viewed and manipulated in it and all of the changes are reflected across the various tools. Hence, integration with existing systems becomes a much more important factor than replacement and consolidation of tools.

Planning in an Agile World

One fear that is common to organizations considering Agile is the perceived lack of planning in the approach. While the pace and fluidity of Agile may give the impression that the teams are driving forward with little regard for a long-term road map, the “flatness” of Agile teams – and the increased interaction between developers and business stakeholders/customers – actually makes it possible for teams to be more aware of business objectives and priorities than they might be in a traditional model.

To drive alignment between its Agile teams, marketing and product management organizations, and ensure that the work that is happening – sprint by sprint – enterprises need to link strategic goals directly to the ALM artifacts that are associated with them: requirements, user stories, tasks, and test cases. How does this work?

Marketing creates the overarching goal of a product release, defining and storing the high-level requirements in a requirements management system. Product management then breaks the requirements down into goal stories, and prioritizes these, along with any change requests, in a backlog. Teams then decompose the goal stories down into actionable pieces (user stories). The user stories are linked back to the goal stories and requirements. In planning their sprints, the teams estimate the size of the user stories and determine the content of a sprint based the team’s velocity (capacity) and the user stories priority (business value).

Then, as the teams complete user stories, the progress is being tracked and linked back to the high-level goal stories and requirements in requirements management system. At any time in the release, marketing or product management team has visibility into how the release is progressing in terms of which goal stories are completed, how much work is still outstanding, and how that work compares to remaining team velocity (capacity) for the release.

Agile managers must be able to quickly make informed decisions to keep planning on track. By gathering real-time status information from multiple sources – change requests, requirements, and test runs — management is able to evaluate all the pertinent information needed to make intelligent planning decisions. Provided with this visibility and the context in terms of business value, the guesswork is taken out of sprint planning for them.

Quality in Agile – A new paradigm for QA

Quality Assurance is an area that many enterprises struggle with when they shift to Agile. The initial tendency is to look at each sprint as a “mini-waterfall” with a testing window at the end. However, the reality is that Agile calls for a much bigger shift. It requires a fundamental change in the way traditional delivery organizations structure their teams and their work, because Agile testing happens in concurrence with development activities in a sprint.

An area of particular challenge is around test automation. According to Agile principles, every feature that gets developed within a sprint must have associated test cases that have been run. Unfortunately, automating the tests is not always possible – and sometimes creates waste. For instance, if the user interface of a release is going to change significantly in a given sprint, any test cases that are created and automated will have to be scrapped and redone.

One way to overcome this issue along the road to adopting Agile is to make slight adaptations to this Agile practice. For example, a feature or story is completed in a given sprint if the team has designed the test cases and run them manually to ensure they work. The automation is then completed in the next sprint. However, there are many risks involved in taking this approach. One of the tenets of Agile is that there is a clearly defined set of deliverables that must be met before a user story (or feature) is considered complete. By changing the completion criteria, and signing off on a feature or user story pending an action that will take place in the following sprint, there is the risk that the team will forget to complete the action – automate the tests – when they get focused on the next sprint.

Provided the necessary means are in place for managers to have the visibility they need - as described above - this kind of approach can actually work. If the cumulative number of test cases are shown for the release, and if this number fails to go up in a given sprint, it is likely that the tests from the previous sprint were not automated.

Managing a Successful Transition

When going through an Agile transition, evaluate it from the perspective of the business and ask, “How is Agile working for us?” Ultimately, businesses could care less what methodology teams use, as long as they are delivering predictable, high-quality results. To manage that, you need intelligence. You need to see what’s working and what isn’t, identify trends, surface areas that need more attention, and make informed decisions.

Chances are, most enterprise development organizations will never be completely Agile. Nor should they. The reason for any transformation is not to standardize on a process, but to create a high-octane, optimized delivery engine that makes the best use of its resources to deliver business value. You need to be able to manage both Agile and traditional projects – rolling them all up into a single dashboard. Further, you need a holistic view of delivery across this portfolio, into specific projects and down into teams and tasks. This information will help to plan and manage an organization's transformation. As you are making decisions on how to transform an entire organization, providing visibility into current and historical metrics is the only way to plan a successful transition. The data will help you to understand the key benefits that Agile brings to teams, so that you can identify the projects that make the most sense to transition.