Agile State of the Art Survey

How IT development teams are managing the transition to agile methods

Paul Gorans ( pgorans@us.ibm.com ) Accelerated Solution Delivery Practice Lead, IBM Global Business Services, Application Services IBM Scott W. Ambler Chief Methodologist for IT IBM The "Agile State of the Art Survey" was designed to gather information about how businesses are actually implementing agile techniques. There were 168 respondents from around the world, working in various business sectors, including government agencies. These respondents shared details about how they have benefited from agile methods and the challenges they still face. This article shares some overall numbers from the survey and covers the top benefits and challenges. Skill Level: Introductory Date: 23 Jan 2012

About the survey

Small firms typically have little difficulty implementing agile development. It's not too difficult a task. Where most teams run into problems is at the larger organizational level. This is what we've spent a number of years trying to help our clients figure out: How do you plan? How do you manage your stakeholder and executive sponsorship? How do you work with other teams that the agile development team depends on to ensure the successful delivery of the final product? When we go out and talk to clients, our intent is to help people by sharing practical, proven experience and practices that have worked in our engagements that they can apply to address the transformational issues in their organization. The majority of the agile teams we find are parts of large organizations that need to scale an agile project, yet face challenges at a cultural level.
Copyright IBM Corporation 2012 Agile State of the Art Survey Trademarks Page 1 of 6

developerWorks

ibm.com/developerWorks/

We conducted the Agile State of the Art Survey because we wanted to ask our fellow agile practitioners, "What are you actually doing with agile methods in practice?" We also wanted to understand the types of benefits they are getting from using agile (including what their organizations are achieving) and what impediments they've run into (or were currently running into) in the process of adopting agile. We limited the survey to those respondents who actually had agile experience. Our survey respondents included a wide range of people from different sectors and different organizations. Many were on fairly small agile teams but also some respondents were on very large teams. For example, 16 percent indicated teams of 21 or more people, and a good percentage of these were teams of over 100 people. These are the sorts of statistics found in traditional software development organizations. Interestingly, only 26 percent of those surveyed were on co-located, that is, the majority were distributed geographically in some way. A third of the respondents indicated that air travel would be needed to get their full teams together. These details are important because the agile community tends to emphasize the importance of co-location. And yet, when push comes to shove, we're seeing plenty of distributed team organizations. The full details from this survey, including the source data and the original questions that we asked, can be found at www.ambysoft.com/surveys/.

Using agile methods in practice

Our survey showed that people are using agile successfully in regulatory situations, such as projects requiring compliance to standards and governmental mandates, and in complex technical situations. The responses demonstrated that agile scales; however, larger teams must modify some of the practices applied. Even common practices, such as having a daily stand-up meeting, have to be tailored to reflect real world realities. Teams need to adopt a truly disciplined, full lifecycle approach, especially when addressing crossorganizational practices such as DevOps. These results support the idea that agile projects should be governed and be enterprise aware. Project managers should be working with the enterprise architects and following common coding conventions for existing data sources. A mature approach to agile delivery reflects the type of organization you find yourself in.

Agile benefits
Our survey looked into a full range of benefits. Four out of five of respondents indicated that the overall quality of their deliverables had improved because they used agile techniques. Another four out of five noted improved productivity, along
Agile State of the Art Survey Page 2 of 6

ibm.com/developerWorks/

developerWorks

with increased usability in the end result. Two-thirds said that they had increased ROI and improved time to delivery. Most likely, all this is a direct result of working closely with stakeholders, working iteratively and incrementally, which means that development teams build the things stakeholders really want as opposed to what they specified. Interestingly, one-third of those surveyed indicated that the documentation provided along with the system had improved and half said that they were seeing the same level of quality in the documentation and the system. Roughly 80 percent reported having as good or better quality documentation than with prior methods. What's the big deal here, you ask? Simply that documentation is one of the things that the agile community has been criticized for over the years, but in fact, agile documentation practices seem to be delivering solid results after all. Of course, all the technical agility in the world means nothing if it can't help the business itself become more agile. Our survey showed that more than 90 percent of respondents stated that their ability to react to change, including changes in business environment and business needs has improved. The results point in this direction: the quality of software development practices align with the quality of the business. Frequent stakeholder interaction and close team collaboration are perhaps the core for all other agile techniques. We believe that stakeholder satisfaction would go up substantially if teams focused more on planning for agile, laying out the stakeholder sponsorship and driving toward these benefits. It might require increased training, perhaps by getting more familiar with the added disciplines need at the higher ends of the scale versus the basic training that is provided in Scrum or XP methods.

Agile is more than basic training

Although we have been assisting clients for years with very pragmatic approaches for agile, lean and rapid development, for the last two years we've been standardizing our disciplined and scalable practices into an end-to-end methodology and helping clients implement it. Disciplined Agile Delivery (DAD) is a process framework that reflects the realities organizations face when adopting agile methods and trying to apply agile approaches effectively. DAD supports more robust ways of working than pure agile methods alone. Therefore, one of the questions we really wanted to ask was whether or not a twoday Certified ScrumMaster (CSM) class was everything they needed for success. Fewer than 4 percent of the respondents said yes, so here's our takeaway: It's a reasonable beginning, but training shouldn't stop there. Basic agile training is definitely essential, but it is only the tip of the iceberg for what you need to be successful. When you address the big picture in a mature organization, one with DevOps issues, a need for improved governance, enterpriseAgile State of the Art Survey Page 3 of 6

developerWorks

ibm.com/developerWorks/

aware development environments and enterprise architecture, you find that you need a more mature, more disciplined approach as you begin adopting agile methods that scale up to meet those challenges.

Challenges noted, too

Sometimes well-intentioned boutique agile consultants try to help larger organizations with their agile transformations, but they're not always equipped to address some of the things that are transformational in nature. Our survey validated the notion that there are common barriers that teams face as they attempt to implement agile practices. Even teams that deemed themselves successful still had these challenges. Among these challenges were measuring success, the disconnect between financial governance of IT and agile strategies, and working with non-agile teams. Measuring success For the last ten years or so, IT organizations have been split apart from the business, more focused on cost cutting than enabling the business. But agile practices really cannot be beneficial without considerable realignment between business and IT. When agile champions make inroads that lead to corporate sponsorship, the practices themselves begin to provide that end-to-end visibility, which means accountability, even in large organizations. With greater measurement and visibility, teams find more common ground to work with their executives and sponsors and stand a better chance of bringing business and IT back together again. Agile practices offer a mechanism to do that. While many people think of it simply at the project level, you really have to think about the organizational level and put higher-level metrics in place. Finance and agile disconnect Almost half of respondents indicated there was a disconnect between their approach to financial governance of IT (project) and Agile strategies. Many teams reported that they were still being forced to give a detailed or accurate estimate at project inception, which, frankly, is very bad practice even for traditional projects, let alone agile ones. This a serious issue that companies need to overcome. In general, we still see a fairly big disconnect between the business needs and effective IT governance. Asking for detailed specifications and detailed or accurate estimates upfront is not the way to overcome that challenge. The DAD process framework addresses this by reflecting the realities that organizations find themselves in when they're adopting Agile, and when they need more discipline around supporting practices required in most organizations. Non-agile teams Almost two-thirds of respondents indicated that their agile teams were being hampered because other teams they rely on are not working in an agile manner.
Agile State of the Art Survey Page 4 of 6

ibm.com/developerWorks/

developerWorks

For example, the data management group or the QA group were taking a traditional approach, slowing those processes down and making things more difficult. In fact, non-agile teams actually increased the risks to the larger organization and not just the risks to the agile team's success because the non-agile practice reduces team and individual productivity. Those who end up on multiple teams, usually because they have certain specialized skills needed in multiple projects, actually end up being bottlenecks on the development teams. These problems will likely go away over time, but some organizations will struggle for a while.

Parting thoughts: IBM and other large agile adoption efforts

IBM represents one of the largest agile adoption efforts in the world. Not only do we have agile methods in our own development teams (and we've been written up in several books now and in agile adoption case studies), but we've also helped hundreds of organizations with their agile transformations. That's our focus. We help organizations understand agile strategies and how to adopt them effectively. Many of our teams in IBM are working at scale, and a very large portion of our development teams are working now in an agile manner. IBM Rational Team Concert is a product that was built by a globally distributed agile team for agile developers. And we're actively helping our customers understand agility@scale. Our Rational and Global Business Services agile offerings provide the foundation for scaling. If you get a chance, keep visiting the Agile Transformation Zone and drop by Jazz.net to learn about some of the really interesting things that we're doing. For clients who are struggling to implement agile with discipline and scale, reach out to your IBM representative, and we can discuss your specific challenges and tailor an engagement to suit your needs.

Conclusion
From the Agile State of the Art Survey, we learned that a high percentage of respondents were benefitting from higher quality deliverables, better usability, improved documentation, increased productivity and better ROI. The challenges included determining how to measure success, disconnects between agile and finance and bottlenecks created by non-agile teams. For those seeking assistance with their challenges, we recommend turning to IBM because we have adopted agile on a very large scale and have helped many other large organizations move to agile development methods.

Agile State of the Art Survey

Page 5 of 6

developerWorks

ibm.com/developerWorks/

About the authors

Paul Gorans Paul Gorans is the global leader of the Accelerated Solution Delivery practice for IBM Global Business Services. He and his team support "agile with discipline" services, work with other IBM groups to integrate agile practices into services and product implementation engagements, and provide agile training to IBM Global Business Services professionals. Paul has more than 20 years of IT experience, and he has led multiple agile projects, decomposed agile programs and conducted agile assessment and transformational engagements. In the past 10 years, he has personally consulted for more than 400 agile client opportunities and engagements, increased IBM global agile capabilities and contributed to agile development books and Forrester surveys.

Scott W. Ambler Scott W. Ambler is IBM Rational softwares Chief Methodologist for IT, so he works with IBM customers around the world to help them to improve their software processes. He is the founder of the Agile Modeling, Agile Data, Disciplined Agile Delivery, and Enterprise Unified Process methodologies and creator of the Agile Scaling Model. Scott is the author or co-author of 20 books, including Refactoring Databases: Evolutionary Database Design, Agile Modeling, Agile Database Techniques: Effective Strategies for the Agile Software Developer, The Object Primer: Agile Model-Driven Development with UML 2.0 (3rd Edition), The Enterprise Unified Process, and the forthcoming Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise (IBM Press, June 2012). He is also a senior contributing editor for Dr. Dobbs Journal. You can keep up with his work through his Rational Experts page and his Agility@Scale blog on developerWorks. Copyright IBM Corporation 2012 (www.ibm.com/legal/copytrade.shtml) Trademarks (www.ibm.com/developerworks/ibm/trademarks/)

Agile State of the Art Survey

Page 6 of 6