The Agile Approach

An agile approach focuses on empowered, self-managing teams; autonomy that doesn't need day-to-day intervention by management. Instead, Agile management means protecting the team from outside interference and removing roadblocks that impede the delivery of business value and productivity. 

What Does It Mean to “Be Agile?”

Agile is a set of values and principles, and becoming agile means upholding these values and principles.

It's not about doing one practice (such as Kanban or Scrum) and declaring that you are Agile, it's about continually seeking better ways of achieving organizational goals.

Your company must adopt an agile culture and implement practices based on the needs of your teams and projects.

Agile Benefits Realized

Why do businesses implement agile? Since 2007, VersionOne has conducted yearly surveys on the state of agile across industries and the globe to uncover the value. 

Consistently the top reasons why companies and organizations adopt agile are to:

• Accelerate software delivery.
• Better manage changing priorities.
• Increase productivity.

The top benefits realized are the ability to:

• Manage changing priorities.
• Increase project visibility.
• Align business and IT.

(source: VersionOne)

The challenges and barriers to adopting and scaling agile are almost always cultural. You may find resistance to change, inconsistencies in process and practices, and lack of skills and experience with agile methods. This is common but can be overcome with practice and embracing a continuous improvement mindset.

Agile + Lean

Agile and lean go hand-in-hand for modern organizational teams. 

Agile is about fostering collaboration and communication, while Lean is about eliminating waste and focusing on delivering the most value at just the right time.

The term lean came out of lean manufacturing with the model Toyota Production System pioneered to streamline production and improve delivery. Mary and Tom Poppendieck correlated how Lean principles drive software development in their seminal book Lean Software Development: An Agile Toolkit. Those driving principles are:

• See the whole.
• Embrace optionality.
• Deliver effectively.
• Amplify learning.
• Empower people.
• Build integrity.
• Eliminate waste.

In 2011, Eric Reis took these concepts a step further with The Lean Startup, which emphasized tight feedback loops to learn and adapt as quickly as possible. The phases of the feedback loop are build, measure, and learn. More and more development teams are folding Lean Startup into the way they practice.

Driving outcomes using lean-agile is a “team sport” and it encourages exploration to find better ways of working together.

The Agile Models

Agile is not a set process or system, but a set of principles and values. But when it comes to acting out the agile approach, the best model depends on the unique goals and problems of your organization and team.

There are several popular models of agile, including: 

• Kanban.
• Scrum.
• DevOps.
• Crystal.
• Xtreme Programming (XP).
• And more.

All have a common solution for improving the outcomes of software development through unique concepts.

How to Select the Right Agile Model

Consider specific circumstances to figure out what might be the best fit for each situation:

• Recognize that current processes, organizational structures, culture and approaches are usually the key causes of throughput or quality problems—not your people.
• Coach your people on recognizing problems and challenges. Finding, identifying and talking about these roadblocks is expected and encouraged.
• Select the processes and approaches suited best to help your organization, based on the problems and challenges being highlighted.

Recommended reading: The Agile Samurai: How Agile Masters Deliver Great Software, By Jonathan Rasmusson

Kanban

In the 1950’s, Taiichi Ohno began using Kanban in Toyota’s primary machine shop.

Key Aspects of Kanban

Translating to mean “signboard” or “billboard”, Kanban is a visual scheduling system that helps a team determine what to produce, when to produce it, and how much to produce.

To implement kanban:

• Create a visual workflow and picture the product in each state—from concept to deployment.
• Develop rules to limit work in progress (WIP) to prevent your team from becoming overwhelmed, and keep progress continuous and steady.
• Manage the flow in order to allow and prepare for changes that will occur within the iteration.
• Make the team, queue and practice policies explicit so your team knows how to participate in the process properly, ensuring a smoother iteration.

When a temporary surplus in capacity occurs, give precedence to helping other team members complete any work already in progress, before taking on new tasks/cards.

Additional Aspects of Kanban

• Implement feedback mechanisms like operations review, mentorship and daily production meetings to ensure demands are being met as you identify where improvements can be made.
• Improve collaboratively with a scientific approach. This involves continuous reflective analysis paired with small adjustments, encouraging a timely evolution at a sustainable pace.
• Periodically revisit and review team WIP limits with the team, customers and stakeholders, especially when changes to the team’s composition occur.
• WIP limits are intended to facilitate the flow of work through the team by making it easy to decide whether or not the team is ready to take on new work. As such, WIP limits should never be used as a negotiation tool—only as a collaboration tool.

Recommended reading: Kanban: Successful Evolutionary Change for your Technology Business, By David J Anderson

Scrum

Scrum is an agile project management model that consists of small teams working interdependently. The teams work together, but focus on their own tasks and must be capable of self management and decision-making. 

Key Aspects of Scrum

Scrum is based around a “sprint,” which is generally a 1-4 week period for delivering a working part of the system. At the end of a sprint the results are delivered, then reviewed, and the next sprint is started.

• The product owner creates and prioritizes a product backlog. 
• The product owner selects story cards from the product backlog and adds them to the sprint backlog, deciding which cards get implemented.
• A sprint (or iteration) is a short amount of time to get a significant amount of work done, and the team selects the duration (LeanDog recommends 1-2 weeks).
• The team meets each day during a “daily scrum” to assess their progress.
• The Scrum Master keeps the team focused on their goals.
• At the end of each sprint, the work that was selected from the product backlog should be released to the customer, put on a store shelf, or shown to a stakeholder.
• Every sprint ends with a sprint review and retrospective.
• When a new sprint begins, the team selects another group of story cards from the product backlog.

The cycle repeats until there are no more story cards to be played in the product backlog, budget is unavailable, or the deadline has passed. Using the scrum process ensures that the most valuable parts of the product are built first.

DevOps

Agile development aims to break down the silos between requirements analysis, testing and development. Deployment, operations and maintenance are other activities that suffer a similar separation from the rest of the software development process. The DevOps movement is aimed at removing these silos, encouraging continuous improvement at all levels, and leveraging automation to work smarter, not harder.

The essential aspects of DevOps covered below are:

• Continuous improvement.
• Continuous delivery.
• Testing automation.
• Infrastructure automation.
• Integrate security earlier into the development process.

Recommended reading: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, By Nicole Forsgren PhD, Jez Humble, & Gene Kim

Continuous Improvement

We are not perfect, and technology is constantly changing. Part of changing your culture is improving yourself, your team, your processes and your organization. Since failure is inevitable, it’s important to set your team up to be able to absorb the failure, recover quickly and then learn from it. With DevOps, failure isn’t always a negative thing, it’s a learning experience. 

High performing teams assume things are going to hit the fan here and there, so they build for fast detection and rapid recovery.

Steps to experiencing continuous improvement:

• Recognize that continuous improvement and failure go hand in hand.
• Share knowledge from individuals and teams via methods such as Lunch ‘N Learn, Centers of Excellence, internal conferences, and other methods. The key is to remove knowledge silos within the organization.
• Look for waste and opportunities to improve your processes. Streamlining and automation can go a long way.

Once that foundation is in place, the following concepts—having a Just Culture and holding blame aware postmortems—further promote an environment of continuous improvement. 

Just culture makes an effort to balance safety and accountability. Additionally, hold blame aware potmortems as part of incident response. These help to actively foster an environment that accepts the realities of the human brain and creates a space to acknowledge blame in a healthy way. Also referred to as Actionable Retrospectives, they collectively acknowledge the human tendency to blame, they allow for a productive form of its expression, and they constantly refocus the postmortem's attention past it. Look for waste and opportunities to improve your processes (continuous improvement and the postmortem philosophy are core tenets of Google’s Site Reliability Engineers).

Continuous Delivery

Continuous delivery reduces the risk of release and leads to more reliable and resilient systems. This is achieved through automation of the build, deploy, test and release process, which reduces the cost of performing these activities, allowing us to perform them on demand rather than on a scheduled interval. This, in turn, enables effective collaboration between developers, testers, and operations.

"Continuous improvement is better than delayed perfection."

- Mark Twain

Essential aspects of continuous delivery:

• Source control not only code, but configuration management of infrastructure.
• Deploy code and servers almost completely automated.
• Every check in, compile, test, and validate happens via continuous integration.
• Avoid long-lived source control branches, which degrade quickly and cause problems.
• Don’t manually setup test data every time.
• Exercise security reviews early in the dvelopment cycle. 
• Prevent one application’s issues from disabling other apps in the system.
• Teams should be empowered to introduce change and not fear of retribution when an innovative idea doesn’t work out as planned.
• Monitor applications efficiently and quickly in a measurable and scalable way.
• Proactively monitor the infrastructure, platform, application and business objectives layers.

Recommended reading: How to Succeed with Continuous Improvement: A Primer for Becoming the Best in the World, By Joakim Ahlstrom

Infrastructure as Code

An essential part of continuous delivery is being able to manage infrastructure in an automated fashion. Organizations looking for faster deployments should treat infrastructure like software: as code that can be managed with the same processes software developers use. These let you make infrastructure changes more rapidly, safely and reliably.

IaC ensures that all infrastructure environments are setup the same. It cann be used on bare metal, virtual machines and on cloud infrastructure. Many tools out there to facilitate this, including Ansible, Puppet, Chef, SaltStack and more.

Shift-Left on Security

As we become a more connected society and our reliance on the Internet grows exponentially, the threat of security breaches only increases. We need to stop doing security reviews at the end of our development cycles and instead bring security professionals into the cross-functional teams we are building.

Start with the following:

• Learn that security is everyone’s responsibility.
• Bring individuals of all abilities to a high level of proficiency in security in a short period of time.
• Know that the internal security team is not an adversary.
• Acknowledge the following: Developers build value for an organization; Security builds trust.

Learn that security is a context bound job with behavioral analysis and forensics as a foundation.

Testing Automation

DevOps can not succeed if it requires a large number of test cases to be run manually. Since we are only human, we make mistakes no matter how hard we try. Testing automation not only encompases running unit tests as part of a continuous integration system, but also includes acceptance tests (also called behavior driven development), integration tests and regression tests.

The value of testing automation:

• Reduces errors in specifications and understanding.
• Mitigates risk by being able to repeat the tests on demand instead of scheduling resources to do that.
• Allows computers to perform repetitive tasks and lets people solve problems. It frees up your testers to focus on the hard problems.
• The test data and fixtures can be managed and reused during automated testing.

Recommended reading: More Agile Testing: Learning Journeys for the Whole Team, By Janet Gregory & Lisa Crispin

Story Card Writing

A Story Card is the unit of each deliverable for an agile team. Story cards include a sentence or two describing a needed function. Rather than representing detailed requirements, story cards are a “placeholder for a conversation.” Each card is testable, includes acceptance criteria, ad the details are elaborated upon via conversation between the customer, and the delivery team. 

How to Write Story Cards

• Cards are handwritten.
• Cards should follow the format: "As a [who], I want [what], so that [why].” This template, comprised of the Values, Roles, and Goals of the card requested feature, are explained below.
• Create Spike cards for experimental stories, mitigating your risk. 
• A Spike is a time-boxed experimental story card that is included in the iteration cycle to determine an estimate, but stops short of completing the story. Spikes are an excellent way to try out something quickly, and are usually a few hours to a couple days in length.
• Follow the INVEST rule for how to write a good user story (explained below).
• Story cards should represent a vertical slice of the application and deliver business value.
• Story cards are sized to fit an iteration.
• Use the 3 C's: the Card, Conversation and Confirmation (explained below).
• The definition of "done" must be clear.

How to Take Story Cards to the Next Level

• Pair developers with business analysts/product owners to write cards.
• Utilize Story Mapping as a tool to identify stories and priorities.

The INVEST Rule: Writing a Good User Story

• Independent: Story Cards should be independent of each other.
• Negotiable: The card should be a short description of the deliverable without too many details. The details should be worked out during the “conversation” phase.
• Valuable: Each story must be of value to the customer and have a value given to it.
• Estimable: In order to plan and prioritize, developers need to be able to ballpark or estimate the effort to complete the story.
• Small: Ideally the story should be small typically taking no more than 2-3 days.
• Testable: If you cannot test it then you will never know when you are done, so a story needs to be testable for confirmation to take place.

Three Aspects of  a user Story: Value, Role & Goal

The template for writing a user story is this: “As a [who], I want [what] so that [why].”

• WHO is the user role or persona that receives the benefit:
  • As a _______
  • Examples: user, return user, power user
• WHAT refers to the overall goal of performing something:
  • I want ________
  • Examples: work quicker, make more informed decisions
• WHY represents the specific value, either to the customer or the business, of that story:
  • In order to _______
  • Examples: find the right folder, browse product options, see my purchase history
• Or, Alternate Format:
  • In order to [X]
  • As a [Y]
  • I want [Z]

The 3 C's of User Stories: Card, Conversation, Confirmation

Each user story has three critical aspects:

• Card: Stories are written on cards. Each card does not contain all of the information, but just enough to show the requirements of the feature. Cards are used during planning.
• Conversation: The requirements on each card are communicated from the customer to the delivery team members through conversation: exchange of thoughts, opinions, and feelings. These conversations happen many times before/during release planning, during iteration planning, and again when the story is ready for implementation.
• Confirmation: After running acceptance tests and confirming with the customer that the tests were successful, a card has been completed.
•  

Agile Techniques

Feature Evaluation: The Estimation & Sizing Techniques

Estimating and Sizing are techniques for evaluating the size and complexity of delivering features in order to facilitate planning and guide investment decisions. A good planning process based on a reliable estimation and sizing approach: 

• Reduces risk and uncertainty.
• Supports better decision making.
• Establishes trust.
• Conveys information.

Tips of Effective Estimation and Sizing

• Use relative sizes.
• Try planning poker, which is a technique used to build consensus among a group for estimating and sizing development without initial bias.
• Understand it’s not just time, it’s complexity.
• User very few large cards.
• If a card is too large or complex to complete within one iteration, it should be broken down into smaller, less complex cards.
• When significant new information is uncovered, such as a team change, re-estimate the feature, as it changes complexity.
• Recognize the differences between size/estimating vs. hours.
• Rewrite, breakdown, decompose card when a smaller slice is found, making all cards as small as possible.

Pro Tip: Measure and account for “Card Growth” between planning and delivery (e.g. 1 card in the backlog may turn into, on average, 1.25 cards delivered, due to some fraction of the cards being able to be decomposed into smaller slices when we discuss them in detail with the product owner).

Setting a Time Period: Sprints and Iterations

A Sprint / Iteration is a set period of time for measuring a development team's throughput. Sprints/Iterations are one to two weeks in length with shorter iterations being the goal.

How Sprints and Iterations Work

• Work is organized to be completed in short time frames (i.e. 1 - 2 weeks).
• To be considered complete, the story cards worked on during an iteration must meet the team's definition of done and get Product Owner acceptance.
• Team gets credit for functional, tested and approved code.

Pro Tip: Unplanned work is noted at retrospectives

Customer Collaboration: Listen Your Way to Better Development

Customer Collaboration is the practice of including your customer throughout development. Only the customer can tell you what they want, and collaboration allows you to listen to their needs instead of guessing at what they need. 

The customer drives the requirements, prioritization, and review of work. While it is not always possible to have customers on site, you must make interaction with them a priority.

Steps to Effective Customer Collaboration

• The customer must be clearly identified, and roles and responsibilities clearly defined.
• The customer may take the form of customer proxy, product owner, business stakeholder, end-user or any combination of these roles. 
• The customer owns the responsibility of driving work in the team that meets overall product goals and objectives for software being built and delivered by focusing the team’s efforts on the highest priorities, highest business value features, and stories for release.
• The customer works closely with the team to break features down to stories.
• Customer determines minimal marketable features and signs off on completed stories supporting those features for release.
• Grooming of product backlog is a collaborative effort between customer and team to adapt to changing product goals and objectives.
• Customer listens to the team, the team listens to the customer.
• The definition of "done" must be clear.

Advanced Customer Collaboration

• Create personas as a tool to better understand customers and their expectations.
• Co-locate with the team to increase collaboration and communication.
• Have customers attend team meetings (i.e. stand-ups, retrospectives, sprint planning).

Recommended reading: Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results, By Morten Hansen