Agile in a Nutshell: An Executive Overview

Harold Campbell, Shane Ferley and Brain Leke

What’s the current problem?

Non-agile delivery methods are costly, slow and often deliver software that requires expensive rework. Additionally, these delivery methods often don’t deliver the expected customer and business value. Bummer.

Some common problems that affect organisations that use non-agile delivery methods include:

• Expensive project deliverables
• Expensive re-works
• Delayed Projects
• Missed market opportunities
• Being unable to deliver meaningful value to clients
• Lots of “Accidental” Complexity
• Ballooning of costs
• Inherent “Waste” embedded in rigid processes, re-enforced by organisational culture
• Silo-ed teams
• Poor collaboration between teams
• “Code then Fix” approach to delivery
• Difficult to respond “Quickly” to market changes
• Long feedback loops between product delivery and expected customer value
• Phased SDLC
• Little to no predictability (e.g. quality, schedules, risk, costs, value, etc.)
• Strong focus on process and tools, over delivering “actual” business and customer value

What is Agile?

Hmmm. So what’s this Agile thing then?

Agile is a group of delivery methods, principles and practices for effectively delivering software that leverages collaboration and customer feedback.

There are various Agile Delivery Methods, like:

• XP
• Scrum/Kanban/Scrumban
• SAFe/LeSS/DAD
• FDD
• Crystal
• Adaptive Software Development
• Lean Software Development

At its core however, Agile is about four things really:

1. Delivery: Focus on Income and Learning
2. Collaboration: Focus on Trust and Team collaboration
3. Reflection: Focus on Insights, Improvements (and celebrating success)
4. Improvement: Focus on Experimentation and actual Change (which includes Data-driven decisions and Hypothesis validation)

Alistair Cockburn (Co-author of the Agile Manifesto) referred to these four principles as The Heart of Agile.

See: http://heartofagile.com/expanding-the-diagram/

Additionally, when using Agile Delivery methods, we use iterative processes to deliver small increments of value at short and regular intervals (AKA sprints, or iterations). These iterations are typically either 2 or 4 weeks long.

Steven Thomas: Iterative Incremental

See: http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa

However, just having short iterations where no business or customer value is being delivered at the end of each iteration really doesn’t help.

We need both: An iterative process and incremental delivery of value.

Henrik Kniberg: Iterative Incremental

Also see: https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

What do the delivery teams look like?

Short answer: It depends on the “flavour” of Agile that you are using.

For instance, Kanban is structure agnostic. While Scrum, another popular methodology, has the following structure:

• 1 x Product Owner
• 1 x Scrum Master
• Development Team (the people that produce the actual product): QAs, Analysts, UX, Developers, etc.

Going back to that iterative process and sticking with Scrum, their process may look like the figure below.

Scrum’s delivery process

Why Agile?

Staying relevant, innovating and increasing shareholder value are some of key reasons why companies undertake delivery transformation, with Agile. The benefits are similar but more wide-reaching.

Additional benefits of adopting Agile Delivery methods include:

• Happier and more productive employees
• “Healthier” delivery teams and work environments
• Fast feedback from customers
• Early validation of business and market assumptions
• Increased innovation
• More predictable product delivery costs
• Shorter delivery cycles
• Less risky product delivery
• More predictable cycles/cadences (e.g. releases, inspect and adapt, etc.)
• Continuous focus on improvement

Agile Delivery Values

There are only four values that guide Agile Delivery methods.

The four values are:

1. A focus on delivering working software
2. A focus on customer collaboration
3. A focus on individuals and their interactions
4. A focus on responding to change

See: http://agilemanifesto.org

These four values relate directly to the four principles that are at the Heart of Agile (described above).

Scrum, Kanban, XP, SAFe, insert-shiny-new-agile-thing-here, (etc.) are all just frameworks/methods that build on these four values. Different methodologies (or the various combinations) will be better suited for different types of teams , or organisations — There is NO ONE TRUE WAY!

Once your delivery methodology is based on the four values above, and there is a deliberate focus on delivery, collaboration, reflection and improvement, you will become agile.

What’s required from Executives?

A shift in the organization will require a shift in thinking and most likely changes in organizational structures and processes.

Executives need to lead the transformation. This is done by:

• Changing mindset
• Shifting from Command-and-Control to Mutual Learning
• Being courageous (by being vulnerable)
• Adopting the Agile values and principles
• Focusing on delivering value vs. meeting deadlines and plans
• Being transparent
• Learning from “Short” failures
• Embracing the fact that the adoption of some Agile delivery practices will require structural changes within the organization (e.g DevOps).

How do you adopt Agile Methods in your organisation?

Again, like with most things Agile, it depends.

Adoption can be seen as a two-pronged transformation initiative — it will require changes in cultural principles and delivery practices.

Cultural Principles

Culture is that intangible thing that resists change within your company. It is the thing that embodies the ethos of the organization. As such, it is critical that a systematic, from the inside-out approach, is taken to change cultural norms, assumptions and beliefs. This is where the “radical shift” needs to happen.

To achieve this, there are a few core principles that should be adopted and promoted within the company. Specifically, these include:

• Servant Leadership
• Coaching — Process, technical, leadership and behavioral
• Continuous learning — Promoted at the organization, team and individual-level; and is budgeted for and factored in during planning
• Frequent reflection — Retrospectives, Sprint/Iteration reviews, etc.
• Individual feedback — Effective/impact feedback, speed-dating feedback, etc.
• Estimations as guides not commitments — shift from date-driven planning to value-driven planning. Engineering effort estimates should be seen only as guides and not “holy” commitments that can’t be changed. This promotes transparency and ensures that any change in facts, assumptions and dependencies, or knowledge and experience (e.g. changes to the team), that will impact delivery are shared as soon as they are known

Harold Campbell and Brain Leke: All Estimates are lies!

• Data-driven decisions — PDCA/Build, measure, learn/OODA models
• Incremental delivery of value — see above

Delivery Practices

At the other end of the spectrum are delivery practices. These changes refer directly to how we deliver software.

These practices typically include:

• Engineering practices — adopting Test-driven development, Pairing, having a code repository were developers commit code frequently (e.g. daily vs weekly), etc.
• DevOps — Practices that focus on getting fast build feedback, reporting, automated testing, improving code quality, continuous integration and continuous delivery of software
• Co-location — As much as possible, having the development team together or being able to collaborate easily
• Small batches in queues
• Work-In-Progress limits
• Self-organising teams
• Continuous team/self assessments
• Transparency over Cover-Your-Ass
• Iterative software development — see above
• Delivery team provides estimates for engineering effort — The people doing the work make the estimates
• Empiricism — Data-driven decisions using hypothesis validation (e.g. with Plan-Do-Check-Act/Build-Measure-Learn)

Next Steps

Pick a method and start. It’s doesn’t really matter if you start with Scrum or Kanban or whichever. Simply start.

What is important however, regardless of your organisation’s maturity, is that you have a process that is focused on consistently improving your delivery, collaboration and reflection processes.

Special thanks to Shane Ferley and Brain Leke for their contributions and feedback in creating this piece!