Adopting Agile Practices

As the software development lifecycle shifts toward agile and lean methodologies, quality in every build becomes critical. Continuous integration allows development teams to receive immediate feedback on their code, creating more efficiency and higher quality. After exploring the differences in continuous integration, continuous delivery, and continuous deployment, Jennifer Bonine and Michael Faulise discuss what is needed for their successful implementation, including the technologies and resources required at each stage of the process.

Agile works. We get it. You don’t have to sell people on the underlying principles anymore. Even so, many large-scale agile transformations are struggling. Some have failed. Others can’t figure out why things aren't working after multiple attempts. It’s easy to blame the people, the process, and the culture. And it’s especially easy to blame management. However, the underlying problem is that most large organizations weren’t built to be agile. You need a way to safely and pragmatically refactor your company into an organization that can adopt agile and sustain the transformation.

Until your code is in production, making money for your business, or otherwise doing what it was built to do, you are merely building toy castles in a technological sandbox. Continuous delivery gets more business value into production as soon as possible, validates business decisions, and responds rapidly to customer feedback. Steve Povilaitis demonstrates what continuous delivery is all about and why automation is your only option for rapidly and reliably building, testing, and deploying software.

In today's rapidly changing environment, organizations—both large and small—must quickly respond to shifting market requirements to remain competitive. To be successful, many are adopting agile development and continuous delivery methodologies to deliver software quickly, while keeping the quality and maintainability high. Several years ago the WebSphere Application Server development teams embarked on the journey from traditional waterfall development to agile. They are now expanding to use both agile and continuous delivery methodologies across their organization worldwide.

Distributed work is common today, and often the talent you need is in another geographic location where time zone differences can impede communication. Building seamless collaboration across distributed teams to support development and operational initiatives can seem impossible—even for the most experienced technology leaders. So, where do you start? How do you organize and manage distributed development and operations when traditional silos exist? Bill Krebs, aka AgileBill, will discuss six categories of tools and six practice areas to help you leverage today’s global talent.

When the agile consultants leave, how do you ensure that the enterprise agile transformation sticks, evolves, and grows throughout the organization? What challenges will you face? What support must be in place to address the challenges? Like software products, the real cost of an agile transformation occurs after the initial rollout. Salesforce.com has sustained an enterprise agile transformation for more than seven years.

Capital One has a highly integrated environment, creating many dependencies for its agile teams. As a result, the teams faced prolonged and increasingly more difficult sprints over time, and did not realize expected improvements in time to market. As Capital One Technology worked through the implementation of various facets of agile, it wasn’t able to take full advantage of the real benefits that agile promises. To solve this, the group leveraged DevOps and ATDD practices, branding them quality-driven delivery or QDD.

One of the most misunderstood concepts in the agile community, complexity is often used to explain why we can’t predict anything or why there are no rules we can follow. Ironically, it is exactly this attitude that allows complexity to work against us. Al Shalloway discusses the true nature of complex systems, why we must deal with them in a holistic manner, and ways to evaluate structural and organizational changes to manage this complexity. Unfortunately, most agile implementations take an incremental, piecemeal approach to change, ignoring complexity.

Many resources describe how to accelerate performance of your development organization through adoption of agile methodologies, but very few cover testing in a practical manner. And those that do generally focus on technical details, leaving out how to build an agile testing culture while facing numerous adoption challenges. Leigh Ishikawa describes how an organization needs to rethink testing in the agile world. He begins by taking a holistic look at how different groups combine in an agile testing culture.

Many teams practice agile development as an integral part of their organization with the benefits of collocation and local decision making. However, it is increasingly more common to develop code across continents, either in distributed organizations or with the help of offshore outsourcing partners. Igor Gejdos explains the essential principles of interfacing with distributed agile development teams and describes the essence of successful communication techniques that bridge cultural and time differences.

Performance engineering and testing are a set of activities by which we design, test, and implement the most optimal system that meets the expected performance goals, based on planning and estimation coupled with tests to verify the system’s capabilities. Although the conventional approach to performance testing works well for traditional delivery models, it is ineffective in agile as it involves testing and tuning near the end of development.

Small companies that have been highly successful delivering software often struggle as they grow larger and their software needs to grow with them. They must learn to manage multiple technology platforms and multiple releases while dealing with the associated roadmaps and support plans. A small company experiencing phenomenal growth, Apex Capital has built four major platforms with two more coming online in 2014. Apex needed a way to consistently deliver software across each platform and communicate that to the respective user communities.

It is widely understood that agile mitigates project execution risks. However, auditors and regulators unfamiliar with the agile process often reject it as non-compliant. In regulated industries, organizations seeking to adopt agile are often challenged to provide evidence that prescribed processes are being followed and can be evaluated to ensure adherence. This issue is compounded when auditors expect a more traditional, artifact-driven process, which, in an agile environment, does not necessarily mitigate the risks for which they were designed.

Agile has delivered impressive performance improvements at the project level, and some attempts to scale agile’s success to the IT project portfolio have also demonstrated good results. However, agile is not for all IT projects nor all project teams. Sometimes other approaches may be more appropriate. Can disparate approaches co-exist harmoniously in the same project portfolio? Can portfolio managers apply a flexible, “best-tool-for-the-job” approach, while simultaneously driving portfolio-wide adoption of disciplined, hyperproductive techniques?