AGILE GROWS UP AND CLAIMS ITS PLACE

February 2011 marks the ten year anniversary of Agile, when a visionary group of self-styled “anarchists” met in Snowbird, Utah to discuss and debate their ideas for better ways to build software. Now ten years later, a new report from Forrester Research finds that 35% of developers are using some form of Agile methodology. How are they using it and how is mainstream adoption of Agile changing Agility?

Let’s examine Forrester’s findings and best practices for getting the most from incorporating Agile techniques.

Who’s Becoming Agile?
Information technology firms are increasingly looking to Agile methods to improve time to market, provide flexible management approaches, and increase application quality. For background, the Agile Manifesto embodies much of the thinking behind today’s Agile movement. Its four values and twelve principles are intended to guide software development teams in a leaner way to work and interact with customers.

The recent report published by Forrester Research, “Agile Development: Mainstream Adoption Has Changed Agility” looks at survey results to see how Agile is being adopted and provides some interesting insights on Agile’s evolution into mainstream adoption. The findings show that while a preference for no methodology still prevails among both application developers/programmers and development managers alike, Agile is a close second for both groups, in both large and small companies. In fact, many developers who have shied away from formal development methods in the past—believing them to be the province of “management”--have embraced Agile as a “formal” development process. As one developer put it, “I was never interested in process before Agile, but now I read books on how to organize my work better and deliver better software.” This comment seems to typify the sentiment of many who have become Agile adopters.

Scrum Leads the Pack
Of the various Agile approaches, Scrum is the overwhelming favorite. By focusing on how people work together instead of on the work they do, Scrum relies heavily on Manifesto principles, but its popularity is attributed to these qualities:

• Scrum is simple. At its heart, it’s easy to understand guidelines describe key roles, interactions, and artifacts required for high-quality software delivery, focus on the practical and allow the team to determine how it will undertake the tasks required to build software.
• Scrum is practical. Scrum addresses the practicalities of organizing the team, allocating work, reviewing status, and correcting course through its daily stand-up meetings, where the team reports progress and makes decisions.
• Scrum is popular. Teams tend to prefer an approach that others have adopted successfully, and Scrum is regarded as the “safer bet”.

Mixing and Matching New Hybrids
The Forrester research shows that being Agile is not black and white—teams do not usually implement all of the Agile techniques simultaneously, tending instead to cherry pick the ones that work best for them. Teams operating in traditional software delivery environments may choose to adopt particular Agile techniques—i.e. daily stand-up meetings or shorter iterations-- to improve outcomes, while ignoring others. In fact, Agile Orthodoxy was found to be the exception, not the rule—only 27% said they stick as closely as possible with a particular Agile methodology while 74% either mix Agile with other methodologies or mix different Agile methodologies into their adoption practices. Agile’s remarkable ability to bring value in a hybridized state, is a key to its ubiquitous adoption.

The survey found it common for teams to select the Agile techniques that most helped them achieve their organization’s priorities. For example, IT departments often struggle to get requirements right and test effectively, so they tend to embrace techniques such as story-based requirements, daily Scrum meetings, and rapid feedback mechanisms, which help keep project deliverables on track to meet business needs. On the other hand, technology industry companies are typically under constant pressure to deliver new products and services, so Agile techniques related to speed, such as daily Scrum meetings and short iterations, tend to be prioritized with these teams.

Teams Are Evolving To Support Agility
As teams have adapted Agile to fit their organizational circumstances, they have also adapted themselves to fit the essentials of Agile. New attitudes are transforming individual contributors into team players. Work environments are changing as teams move from separate offices into open space work environments. The prevalence of these changes is another sign that Agile adoption has become mainstream.

The resulting change within organizations can sometimes present new challenges, often when they expose or put new strains on weak points. For example, teams that have been sloppy about prioritization may need to develop new discipline to effectively assemble a backlog or stick to the functionality planned for a single sprint. Employees accustomed to being responsible for their own deliverable can struggle to place the team’s needs above their own. However, these challenges signify growth and teams tend to adjust their dynamics to make Agile possible by focusing on evolved roles, updated practices, and practical application of process.

Defining Clear Lines of Authority
Agile depends on rapid decisions, so to be successful teams are advised by Forrester to streamline their decision-making process as much as possible. Delays in scheduling meetings and the “power vacuum,” that occurs when no one wants to take responsibility for decisions, can be fatal to an Agile team. Some common strategies for more efficient decision processes set out by Forrester include:

• Having a product owner. Even if you elect not to have a product owner, many teams will embrace the product owner role to ensure someone is clearly responsible to answer questions, define general product direction and prioritize work.
• Letting business analysts and product managers make business decisions. Developers typically do not have time or the desire to meet with customers or users, analyze markets and use cases, and perform the other work needed to understand the business context to make sound business decisions. Therefore, teams assign decision-making responsibility to Business Analysts  and Project Managers, who normally are not the product owners but who focus more on the development team’s daily activities.
• Defining product roles based on complexity and stakeholder characteristics. As project complexity increases, teams are advised to look to outside resources, such as Business Analysts or Project Managers, to handle research tasks and to mediate stakeholders, particularly when there are numerous stakeholders with limited availability.
• Empowering the team. Teams that have to wait for stakeholders to give them their time and attention are advised to renegotiate their relationship with those stakeholders. Executives must have the power to set general direction, but in all other matters Forrester counsels they should step aside, giving the development team the ability to define the problem space, craft the solutions and deliver results—for which the team will be held accountable.
• Leaving room for mistakes. Software development in any form entails an ongoing process of experimenting, learning, and revising. Allowing teams to fail gives them the opportunity to make mistakes early and correct them. This is especially powerful when risks arise late in the development cycle—for example, in system testing following unit testing—because it ensures that teams have the flexibility and the attitude to address errors head-on and ensure quality deliverables.

Does Size Matter?
When assessing how adopting Agile changes teams, it’s important to note what does not change and what organizational characteristics have not been an obstacle to Agile adoption. Prior to adopting Agile, teams may worry that Agile processes cannot support geographically distributed or outsources workers. An equally frequent concern is that Agile won’t work for very large teams.

Researchers find that the image of the Agile team that works in the same office, attends daily Scrum meetings and does daily check-ins and builds of working code is in fact a stereotype. In practice, teams figure out how to work around obstacles such as:

• Team size. The stereotypical perception of an Agile team is that it consists of less than a dozen members. In the teams surveyed, only 50% reported 50 members or fewer. The remaining teams are larger, with a third having more than 100 members.
• Distributed geography. Only a small minority, 17% of teams surveyed, are 100% co-located. For the majority, most of the team members are co-located: 78% reported that up to 50% of their teams are co-located. The remaining 22% reported more than 50% of the team is distributed in different locations.
• Use of outsourcing. More than 50% of Agile developers surveyed are willing to outsource components of software development, even though it requires both geographic and organizational distribution of effort.

Forrester Research finds that teams have overcome obstacles to adapt Agile methodology that was originally envisioned for small teams by employing these best practices:

• Dividing labor within projects. By breaking projects into smaller chunks, smaller sub-teams can accommodate stereotypical Agile methods. Release teams then aggregate the work of the smaller sub-teams, often organized through some version of a “Scrum of Scrums.” Higher-level team structures also handle integration, testing, and other tasks for the overall project. The project-level life cycle is usually simple, focused primarily on ensuring that each sub-team delivers what’s needed and that dependency management remains feasible across deliverables.
• Adopting techniques and technologies that support distributed collaborations.  A variety of tools, from Agile-focused project management aids to wikis and Web conferencing platforms, can help project teams bridge geographic and organizational boundaries. Content communicated and managed through these tools include backlogs, progress dashboards, and task lists. Team members are also urged to beef up their communication and listening skills. This is especially important for globally distributed teams, where time differences and cultural variations can significantly impede progress. See recent articles from Insight on managing multi-cultural teams and top Agile lifecycle tools.
• Creating and sustaining well-designed partnerships. While working with a systems integrator (SI) that also uses Agile is important, more-prosaic details about the contract with the SI are also important. Contracts should reward progress and value rather than task completion and deliverables.  Teams should treat SIs as genuine partners, demanding transparent reporting and providing easy access to internal resources and systems and include coaching and training. Another best practice when working with outsourced providers is implementing logical groupings of work around teams to ensure clear ownership.

Forrester encourages software development professionals to “stop sitting on the fence where Agile is concerned.” According to those who have adopted Agile, the benefits are well worth the effort, and with the recent dramatic increase in Agile adoption, the possibility of working in or with an Agile team has increased for everyone.

Contact Software Consortium or call 1-877-850-9393 if you would like to discuss how to leverage our top-level talent to empower your business.

 

Baltimore Office
Local Phone: 410.583.9393
sales@softwareconsortium.com