Being Agile VS Doing Agile

75% of online information regarding the explanation for Agile and Scrum is either incorrect, or not consumable by someone who’s trying to immerse themselves in Agile and Scrum.

Here’s an example from one of the top Scrum coaches in the world, Mike Cohn:

Scrum is one of many in the agile process. You can think of agile as an umbrella term that encompasses other processes, such as Extreme Programming, Adaptive System Development, DSDM, Feature Driven Development, Kanban, Crystal and more.

Huh? Mike’s not wrong, it’s just that if a company is trying to embrace Agile, the person reading Mike’s statement could be a Developer or a Sales VP and not have the slightest clue of what all that jargon means. Further, Agile is very different from those processes Mike outlined; Agile is a philosophy, a mindset, a management style, a modern way to collaborate with people. Scrum is more about how to deliver something from collaboration utilizing ceremonies or purpose-driven meetings, artifacts like the Product Backlog, and specific team roles like Scrum Master and Product Owner.

Being Agile and Doing Agile

It’s relatively easy to crystallize the difference between Agile and Scrum using this concept:

Being Agile explained

  1. Being agile is simply having a mindset that embraces value, flexibility, failure, collaboration, and teamwork.
  2. Agile is a set of soft skills, a set of management practices that are flat as opposed to traditional command and control, manager-driven practices.
  3. Agile dictates how to be, not how to do.
  4. Any company can be Agile! (it’s not just for technology firms or departments)

Doing Agile Explained in Nine Steps

1

DETERMINE PURPOSE OF TEAM
For what will this team be responsible or accountable? How will this team provide value?

2

BUILD THE TEAM
Get the right people on the bus, sitting in the right seats. Scrum Master, Product Owner, Business Analysis, QA/Testing, Developers, specialists, Subject Matter experts, Executive oversight, etc.

3

BUILD TRUST
Take an afternoon to work through a Team Canvas session; focusing on what's important to each team member, core values, goals, rules and activities, strengths/weaknesses, roles/experience, working agreement, etc.

4

TRAIN ON AGILE
Mindset that embraces value, flexibility, failure, collaboration, and teamwork.

5

TRAIN ON SCRUM/KANBAN/TDD/XP/etc.
How we implement the Agile mindset and principles. An example of doing Agile is the Scrum methodology: 2-Week Sprints, Daily Standups, Sprint Planning, Backlog Refinement, Sprint Reviews, & Retrospectives.

6

COORDINATE CEREMONIES
Determine the cadence of the team and how often you'll get together for your Scrum ceremonies.

7

DETERMINE TOOLS
Determine which 3rd party tools will be used to provide the greatest value to the business. You'll need a Product Backlog tool like Jira or Azure DevOps, a tool to store documents, a tool for video conferencing, a tool for scheduling meetings, a tool for instant messaging, and a tool or stack of tools to manage ongoing continuous improvement / continuous delivery (CI/CD).

8

BUILD THE BACKLOG
Find ways to best build the Product Backlog using SIPOC or other tools highlighted within Business Analysis Body of Knowledge (BABOK) if processes are not documented, define pain points of the business if not defined, then assign value, priority, and level of effort. This is the hardest part of Scrum - the art of building requirements within the Product Backlog.

9

DEVELOP DEFINITION READY / DONE
Define how the team will know when Product Backlog User Stories are ready, and once the team has satisfied a definition of done for each User Story.

Contact Us