When Agile isn't agile

Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

agile (adjective)  : able to move quickly and easily  : quick, smart, and clever

A desire to be agile when developing software products is at the root of the Agile Manifesto. Other methodologies, such as Scrum and Extreme Programming, are based on the Manifesto’s teachings. Many enterprises migrate to Agile methodology and its ilk but fail to achieve agility. That’s because, in its naive implementation an Agile Sprint is no better than the Waterfall process.

When Sprint == Waterfall

Adopting an Agile process without a corresponding change in organizational structure and business processes will not achieve the desired results. Organizations must change to reflect the move to a faster and more integrated software development process. In a truly agile software development organization, product management, architecture, design, development, testing, and operation all become functions of the software engineer role.

Each engineer will have strengths and weaknesses spanning these functions, and corresponding responsibilities and seniority levels within the organization. Merging these distinct roles, which crosses most organizations’ traditional boundaries, is key to achieving fast and incremental iteration.

The business processes that need adoption alongside an Agile software development process are:

• Adaptive Planning
• Early Delivery
• Evolutionary Development
• Continuous Improvement

Adaptive Planning

The Cone of Uncertainty makes traditional planning methods flawed for the fast-paced technology sector. The longer out a plan tries to predict, the worse the ambiguity gets. Agile redefines the concept of a fixed-term plan. Adaptive planning starts by capturing backlog stories, considers organizational output -- also called velocity -- and then continuously adapts the plan to reality.

In adaptive planning, the key is to get all of the things you want to do written down, designed, prioritized, and labeled before resources and dependencies are identified. Planning becomes a bottoms-up discovery process that engages and leverages technical talent. Longer term planning becomes an opportunity to dream bigger. The resulting plans are not rigid formal contracts, but living and dynamic documents. Adapting the plan becomes a business process executed by project managers, and does not need to involve, and thus disengage, key technical talent who would rather be, and should be, coding.

Early Delivery and Evolutionary Development

Setting goals and being accountable are important in high-performance organizations. Each goal has a delivery date, and organizations push themselves to deliver earlier than what's comfortable. In Agile, this means shipping the product as soon as it is a Minimum Viable Product, then evolving the product iteratively and continuously based on feedback. The business process becomes one of informed evolution instead of prediction.

Market, product, and business research is still critical. Before a new product is developed, the research identifies which ideas to pursue, and what the minimum viable feature set is. After the product goes live, the research identifies which products should evolve and in what direction, and which products should discontinue.

Continuous Improvement

Continuous improvement is a goal for both the software product and the software development organization. Continuous delivery is a process designed to achieve both these goals. When implemented correctly, continuous delivery ensures early delivery and evolutionary development, in addition to providing all the necessary inputs for adaptive planning.

Continuous delivery demands that the first milestone of software product development is to fully automate the delivery process. This automation is done prior to any product functionality being implemented, and thus the entire product is developed evolutionarily in small increments. Feedback loops and key metrics tracking lead to continuous improvement.

The connection between continuous delivery and organizational improvement is perhaps more subtle. Continuous delivery exposes the velocity of the organization and the trend of this velocity. When changes are made in the organization, the effect on velocity is immediately exposed. With this information, managers are forced to drive toward organizational improvement in small increments, and experimentation is achieved through normal operating procedures.

Let it Go, Let it Go!

Traditional planning is key to top-down control in enterprises. Through the planning process and subsequent resource allocation process, executives decide what projects to fund. Resource allocation is a key part of executive function in these enterprises. So what replaces the traditional plan as input to the resource allocation process?

In an agile enterprise, the input to the resource allocation process is derived from the organization's backlog and current velocity. Resource allocation becomes a question about which organizations would benefit from increased velocity to tackle valuable product stories faster. The fundamental difference is that it's not projects that get funded, it’s organizations that get increased velocity. Control has been transferred from the executive to the organization, and ceding this control freaks out a lot of executives. It is a necessary and critical part of becoming agile.

Achieving agility

Adopting an Agile software development process (e.g. Scrum, XP) without the corresponding organizational, business process and management changes, will fail to achieve organizational agility. To become agile, an organization must empower its engineers; the people doing the day to day work. In order to move fast they must make the majority of decisions. In an agile software enterprise, management and business processes aim to empower and unleash the software engineers, not control them.