Agile and ALM are two terms that you don’t often see side by side. To most developers, agile means team interaction, customer collaboration, dynamism, and responsiveness to change. In contrast, ALM seems to imply the opposite of agile, with echoes of rigid procedures, inflexibility, and top-down process control. But are the agile and ALM approaches as contradictory as they first appear to be? After all, both are a means to the same end: improving software development by enabling collaboration and information sharing. So is it a question of scale? Is agile more applicable to smaller teams, while ALM is better suited to larger organizations? Maybe. But the two are not mutually exclusive. ALM principles can apply to a five-man team just as well as a 500-man team, and agile approaches can be applied to large teams as effectively as small ones—especially with a little planning and forethought.
Let’s look at how the best elements of the agile and ALM approaches can be adopted to solve key development challenges in teams of any size.
Agile Challenges
Agile principles are aimed at dealing more efficiently with the complexity of software development, improve productivity, and shorten time to market. The principles acknowledge that requirements are not always known upfront, may change over time, and embrace short-term scheduling.
Companies applying agile principles typically use a common set of techniques, such as:
- Iteration and release planning
- Daily stand-up meetings
- Continuous integration
- Automated builds
- Unit testing
- Refactoring
This list indicates the new challenges linked to the adoption of agile principles along the application lifecycle, as they go against the "traditional" development stages and roles of planning, analysis, development, and testing.
These challenges can be distilled into three main areas: dynamic planning and scheduling, effective collaboration, and performance implications of frequent delivery. What’s interesting is that these challenges apply both to small and large teams alike. The difference comes in how the challenges should be addressed according to team size. In this article, I go deeper into these three main challenge areas and propose solutions and appropriate tools for each.
Dynamic Planning and Scheduling
Agile puts more emphasis on short-term scheduling, where tasks can be moved from iteration to iteration or removed from a release due to changed priorities. This results in frequent schedule updates, which must be communicated to team members—and manual updates to different locations (or tools) quickly become impossible to handle. However, a product owner often wants to ensure that the team gets an idea of the "big picture." Focusing on the next iteration only bears the risk of getting lost in the short term. So what solutions are available?
Use a planning hierarchy to maximize business value
The first step is to use the business value of features to define their priorities. By linking features to change requests, project managers can provide direct feedback on achieved business value based on the features that are completed.
Project managers can also use products, releases, and iterations to determine the level of planning detail needed. When defining the next release or prioritizing a backlog, working with features is sufficient in most cases. It’s only when scheduling the next iteration that features need to be broken down into individual tasks. These tasks can be estimated, assigned, and completed by linking to the file changes.
Facilitate scheduling with an intuitive planning interface
Make sure that you can a) schedule easily, and b) cope with changes to schedules. This should be supported by your CM solution when working with iterations. Immediate information about task status, priority, and owner, as well as the ability to easily schedule tasks, reduces the time needed to plan the next iteration. Tight integration with your CM solution allows a seamless task-flow along the development lifecycle and facilitates parallel development.Use a planning solution that is flexible enough to support different processes
Agile helps companies cope with change in software development. However, it isn’t a "one size fits all" solution, so depending on a number of factors (including the type of work, team size, or current company culture) processes might need customization. Also, no team remains static. The planning solution itself has to be agile!
Avoid rework by automatically retrieving the correct code base
This helps avoid simple human error, especially when looking after multiple releases. Changes can be scheduled against the software version where they have to be applied: hot fixes against live releases and new features against the release currently in development. Fully integrating release planning with CM allows developers to retrieve the correct configuration automatically, based on the release that these work items are scheduled against.
Effective Collaboration
Agile methodologies rely on close collaboration between team members from an early stage. As a result, siloed planning and CM solutions for each functional group are not appropriate. Collaboration is also challenging when working with teams distributed across different sites or continents—meaning end-to-end solutions are needed.
Share scheduling information with all team members
Allowing all team members to check on progress is motivating and facilitates collaboration, as each member knows which tasks his peers are currently working on. Team members also gain an understanding of the product roadmap by looking at the features scheduled for the next release or prioritized in the backlog.
Automate status updates
Make sure task status is updated based on the actions that team members take to complete their tasks. All actions, from a checkout to completing a task or feature, should be fed through from bottom to top to provide automated, real-time tracking throughout your project hierarchy. This minimizes overhead for team members, saving valuable time that would have been used to manually update task statuses and boosting productivity. It also gives team managers real-time status reporting on project health.
Allow team members to share work throughout the development lifecycle
Having all project artifacts stored in the same place allows team members to share their work across team and geographical boundaries. Documents can be assigned to any team member for review or a development task in progress can be shelved and reassigned to a colleague, e.g., in case of a sick leave. This also increases transparency when sharing work, as any action from raising a task to its completion is tracked and accessible to team members.
Performance Implications of Frequent Delivery
Automated and continuous builds are two of the most popular agile practices, as both help with early detection of bugs. However, supporting frequent builds and labelling create another set of challenges, especially when looking at source control and CM.
Facilitate frequent (and automated) builds
When moving from weekly or daily to continuous integration, automation is required to make sure kicking off builds and getting feedback does not create additional overhead. Choose source control tools or ALM components that support integration with build tools. This allows the tools to either retrieve the latest project version or even the latest check in from each developer for continuous integration and results feedback—for example, did the build succeed or fail?
Make sure you can take frequent snapshots
Even though task-based solutions allow you to retrieve any project configuration easily, highlighting a specific project configuration as a build or release enhances transparency. This is often referred to as creating a tag, label, or project snapshot. With frequent builds, frequent snapshots must be supported in two ways: near-instant creation and no limit on the number created. Stream-based solutions do not need to write to every element of a project when taking a snapshot, but instead should make a reference to the point in time a snapshot was created, to maximize performance.Support parallel development and maintenance
Managing maintenance and development in parallel requires strong support for multiple code lines (or branches). You also need transparency to track what branches you have and their current status, as well as automation to keep branches up to date without excessive overhead. Also, with agile, frequent refactoring happens regularly. Your solution must support refactoring and editing of the same objects in parallel, making sure all changes are applied to the relevant objects in the right way and right order, and preserving their history.
An example of parallel development
Get added project visibility
With multiple releases or builds, you need to know what has changed between them. With integrated CM and reporting tools, development managers can visualize differences between any two configurations, either by looking their files and folders or completed tasks and features.
Opposites Attract
In conclusion, agile techniques can create new challenges for the way development teams manage their release planning, team collaboration, and delivery. The ability to plan easily, share plans with the team across geographical boundaries, and give up-to-date status insight is crucial.
By integrating planning with CM and their build processes, development managers can better control important parts of their development lifecycle such as branching and merging, avoid human error, and support a fast feedback cycle.
In small teams, performance of the CM tool is crucial, as frequent builds demand frequent snapshots of each code line or branch. Failure to evaluate performance upfront might lead to increasing idle time once project content (and teams) start growing. These effects are accentuated in larger teams working on a multitude of projects or releases in parallel. Here, the ALM solution has to make sure that planning, tracking, and configurations all stay in sync in order to allow frequent planning and deployment to go hand in hand.
So with the right choice of tools, it’s possible to take the best elements of both agile and ALM approaches to optimize work along the development lifecycle and reduce complexity and administrative overhead in any size of team. Even these apparent opposites can attract.
