Recommended Delivery Methodology

Agile

Appian uses and recommends an Agile delivery methodology as it is the best way to ensure speedy delivery of value.

Agile is an umbrella term that describes a growing list of methodologies that all support the same principles and the same goals of speed, quality, adaptability, and transparency.

Why Agile?

Since Agile methodologies are based on incremental and iterative delivery, value is delivered throughout the project as opposed to only at the end and project risk is, therefore, reduced as feedback can be gathered and incorporated at every stage.

Agile principles align well with Appian strengths, delivering benefits that include:

• Minimizing the cost of delay through rapid incremental deployment
• Strong collaboration through business and technical teams working closely together
• Keeping the cost of change low by incorporating feedback and responding quickly to change
• Increased transparency into the project schedule and state

In most cases, software development is an empirical process, requiring multiple cycles of testing initial assumptions and designs and then making the necessary adjustments to incorporate feedback and new discovery. In these situations, a traditional waterfall methodology necessitating all requirements be fully and perfectly understood up front, with no way to accommodate change along the way, is a poor fit. On the other hand, Agile is specifically designed to harness change to deliver what the end user truly needs, making it a better fit for delivering results.

Consider two scenarios:

1. Imagine first a product owner who has worked extremely hard writing many detailed use cases to fully capture how she imagines people will use the system and a team who works diligently fully delivering on this vision through six months worth of sprints. It’s not until the big bang production roll out at the end of the six months, that the business or team has the opportunity to get feedback from real end users and discover that they’ve built many features people do not even want and are missing several critical ones that people need! At this point, however, the project budget has been used up and estimates to go back and make changes are quite large.
2. Now imagine that same product owner begins with similar assumptions about user needs, but works with the team to determine the small portion of functionality that will be most valuable to users immediately. The product owner still plans to implement more features after the initial set, but the team develops for just 8 weeks before releasing to production. Within days they receive feedback from real users which reveals that many of the assumptions they made about how users would interact with the system are not valid. However, since they only developed for eight weeks, it’s relatively easy and affordable for them to make changes and incorporate the new knowledge gained into their plans for the next release.

Appian’s Agile Approach

Appian typically kicks off projects with Sprint 0, which is intended to perform quick, collaborative product discovery to understand the project goals and context. By the end of Sprint 0, the team will have created a release plan to provide transparency into release goals and track delivery.

Appian then delivers projects incrementally through a series of short, typically 2 week, product delivery sprints (iterations) which each result in a small piece of tested and working product. These sprints allow teams to decompose the release plan scope into smaller pieces to create solvable problems. The goal is to always keep releases small in order to release frequently and get fast feedback.

Since each delivery sprint results in a piece of working product, within the sprint the team completes all necessary activities. This includes working on any analysis, design, development, testing, and revisions necessary to get the item to "Done". Teams avoid setting up separate sprints, in a waterfall fashion, for each of these stages. Waterfall sprints increase the time it takes to get “Done” work, slow down feedback cycles, and increase risk.

Should look like this:

Not this:

Within each sprint, the delivery team utilizes several key ceremonies to ensure they are continuously improving the product and the delivery process, for example:

• Sprint Planning to break down and plan how the team will implement the sprint’s goal
• Daily Stand-Ups (Daily Scrums) to stay aligned and communicate any risks that may be impeding the team’s ability to deliver the sprint goal
• Sprint Reviews (Sprint Demos) to show the completed sprint work and immediately get feedback from stakeholders
• Sprint Retrospectives to inspect and adapt on the delivery process and make any necessary changes prior to the start of the next sprint

For more details on each of these ceremonies, see the Scrum Guide.

Appian carefully chooses and tailors the Agile processes it uses to the specifics of each project to ensure they are in support of the unique situation. The various Agile methodologies utilize a wide array of practices, each of which is in support of a shared Agile principle, but which may be more or less applicable in a given situation. It is, therefore, important to use the Agile principles as the key guidelines while customizing the processes.

"Failure at an organizational level seems to come from the inability to customize processes and make them their own...Rubber-stamping agile processes is not agile. The value of having a principle-based process is that you can apply the principles for an individualized process for your situation and, as an extra bonus, one that has been designed to adapt from your learning as you adopt changes into your organization. It is always "custom.“

-Kent Beck, Creator of Extreme Programming

Additional resources

Websites:

• Agile Manifesto and Principles
• Scrum Guide
• Agile Alliance
• Scrum Alliance
• Scrum.org

Books:

• Essential Scrum, Ken Rubin
• Succeeding with Agile, Mike Cohn
• Software in 30 Days, Ken Schwaber and Jeff Sutherland