So you’re doing Scrum. Great! But are you Agile?
“Wait a minute,” you might say. “Isn’t Scrum an Agile framework? How can you be doing Scrum and not be Agile?”
Well…it’s actually quite easy.
The Agile Manifesto
Let’s start at the beginning.
Unless you’ve been living under a rock, as an Agile practitioner you’ve heard of the Agile Manifesto. This brief 68-word manifesto establishes a set of values that are key to agility.
What you may not know is how this manifesto came to be.
At the time of its creation (2001), there were a number of heavyweight development processes, with Rational Unified Process (RUP) the most popular kid on the block. Due to the high rates of failure in software projects, these processes were designed to model and understand everything about a solution early and lock in decisions to create predictable outcomes. The idea was that if you know exactly what you are going to build, you can better understand and plan for what you need to do, how much it will cost, and how long it will take.
Change was discouraged because changing requirements and/or technical approaches would frequently wreak havoc with the plan. If replanning was not done, changes could easily result in a product not ready for release once the schedule and budget were exhausted.
Thus, more complex and elaborate ways of capturing change, determining need, understanding the impact, obtaining approval, and re-baselining the entire master plan were created. This was done under the belief that if the release was planned out in enough detail, change would be infrequent and minimal.
Although outwardly logical, this entire movement toward heavyweight processes in the industry had numerous flaws:
- It was extremely expensive and time-consuming to create exhaustive requirements, designs, and plans upfront.
- It locked people into decisions. There were mechanisms in place to change some decisions, but due to the large amount of effort involved, change was discouraged unless absolutely essential. Project team members would often be criticized for missing things during the business discovery, requirements, or design phases when change manifested.
- It created horrible working environments, as the team worked frantically and frequently cut corners to stay within an established plan that was rapidly diverging from reality. No matter how much effort was put in upfront, ‘unknown unknowns’ always existed.
- Heavyweight processes weren’t effective — success rates of software projects did not go up appreciably.
A number of thought leaders emerged who were actively trying to create better ways of developing software and wanted to prevent the industry from continuing to double down on bad approaches. These leaders created alternative approaches such as Extreme Programming (XP), Crystal, Scrum, and Adaptive Software Development (ASD).
Each had their own approach to creating effective solutions, but they recognized that without a cohesive movement to unify them, the heavyweight frameworks would continue to dominate. At the Snowbird ski resort in Utah, 17 of these thought leaders met with the intent to come up with something better.
Although technically competing with each other in their specific approaches, they wanted to understand what was common amongst them. Ultimately, they created a list of the key things they agreed on. This became the Agile Manifesto, outlining the primary values and principles of Agile development.
You can read the entire story of how this happened in a post by Jeff Sutherland, the creator of Scrum.
Why does this matter? Glad you asked.
Dark Agile / Faux Agile / Cargo Cult / Zombie Scrum
Scrum is not a prescriptive solution that forces you to embrace the values and principles of the Agile manifesto. Rather, it’s a framework to support teams that already embrace Agile values and principles. As the ‘Snowbird 17’ discovered, Agile values are the ‘secret sauce’ that makes all Agile frameworks effective, including Scrum.
“There’s cargo cult Agile where you’re doing and saying the right things, but you don’t understand the fundamental principles. You’re not getting the results.” – Ian Buchanan
Without embracing the Agile values and principles, Scrum can easily turn into Zombie Scrum — looking like Agile on paper but anything but Agile in reality. The un-Agile Agile team.
Which takes us back to why I led with the Agile manifesto and its importance. With imitation the sincerest form of flattery, let me mimic the format of the Agile manifesto and look at a Scrum team through the lens of the four values of the Agile Manifesto.
Value #1: Individuals and Interactions Over Processes and Tools
“Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” - The Scrum Guide
You can get a good sense of this Agile value simply by attending a few of the team’s daily scrums.
In an Agile team, you’ll see a good amount of collaboration and interaction during the daily scrum. The purpose of the daily scrum is to plan out the next 24-hour period of work. The team will discuss how they are progressing on the Sprint, coordinate who is going to do what next, and highlight anything getting in the way. The team will put their heads together on what they need to do for the day and swarm where necessary in order to meet the Sprint Goals.
In a non-agile team, you’ll see the team gathering with very little interaction. Each person will simply answer the “3 questions” and it will feel much more like a status meeting, with people reporting what they did, will do, and problems they’re having to the Scrum Master or a lead developer. There will be very little team interaction or discussion on how the team is progressing.
Interestingly enough, the “3 questions” were removed from the Scrum Guide in 2020 because it was seen as too prescriptive. Without the Agile mindset, too many teams used it to create a ‘status’ vs. a ‘plan the day’ meeting.
Value #2: Working Software Over Comprehensive Documentation
“In order to provide value, the Increment must be usable.” – The Scrum Guide
You can get a great sense of this Agile value by reviewing the “Definition of Done” created by the team, as well as by attending the team’s Sprint Review.
An Agile team will have a well-formed and thought-out Definition of Done that ensures a story is in a state that can be deployed to production any time after the story is completed. Furthermore, when observing the Sprint Review and in particular the demonstration of any completed stories — everything should work. The completed stories should be showcased in an environment representative of production and in the context of the business problem that the story was written to address. Each sprint should in effect result in a new version of the product ready to be released, regardless of if it is intended to be released to production.
In a non-agile team, the Definition of Done will focus more on the completion of the feature functionality than in ensuring those features are useful to the end user and can be deployed to production. Typical things missing include scripts to configure the environment, automated deployment, the staging of data, and sometimes even testing.
When attending a Sprint review, features might be demonstrated in isolation and in a manner nonsensical to the business. A test page showcasing a feature that has yet to be integrated in the application at large is a great example. Or the feature could be demonstrated in a non-representative environment, such as a developer’s laptop. Or worse yet, the feature won’t function until another part of the application is completed.
In short — if the desire was to put the demo into production the next day for the end users, the team would be unable to comply as there is still significant work to be done.
Value #3: Customer Collaboration Over Contract Negotiation
“Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.” – The Scrum Guide
One of the best places to observe Customer Collaboration is in the Sprint Review.
In a well-functioning Agile team, key stakeholders are presented with the results of the work the Scrum Team accomplished. They discuss it along with the progress made toward the Product Goal during the Sprint Review. Beyond what was accomplished, they also discuss what has changed.
Attendees collaborate on what do next and may even adjust the Product Backlog within the meeting to handle changing conditions or meet new opportunities. It is a working session with the client — accomplishments and challenges are discussed, not just presented. It isn’t unusual for things to change coming out of a Sprint Review.
In a non-agile team, a Sprint Review often takes the form of a ‘Sprint Demo.’ The team will present what they have done to the key stakeholders with very little discussion. There will be minimal interaction regarding changing conditions or needs. The Product Goal and Product Backlog will not be discussed.
In extreme cases, the key stakeholders may not even be present. Much like the daily scrum in an un-agile team, the Sprint Review will feel more like a status meeting than a collaborative review of the Sprint and next steps. A non-agile team’s takeaway from the Sprint Review will be that the team is ‘on track’ or ‘behind’ rather than the attendees of the review collaboratively adjusting their aim.
Value #4: Responding to Change Over Following a Plan
“A Scrum Team is expected to adapt the moment it learns anything new through inspection.” - The Scrum Guide
This Agile value is best observed in the daily scrum and Sprint Review.
In an Agile team, the team members are empowered and self-managing. During the daily scrum, team members take initiative and broadcast their intended actions to address problems or needs as they arise.
There are discussions amongst team members both inside and outside the daily scrum to determine how to adapt or re-plan the sprint as the need arises. Each member of the team takes pride and ownership in ensuring the Sprint Goals are met and are bold enough to take action when needed.
Likewise during the Sprint Review, the team discusses with the key stakeholders the issues, needs, and priority changes. In collaboration with the key stakeholders, the team determines what they will do and how they will do it.
In a non-agile team, team members will not respond to change during the daily scrum until their proposed actions are approved. They will often ask for permission, deferring to the Scrum Master, Product Owner, or a senior engineer who maintains the plan for the team.
Even worse, some team members may require the next task be assigned to them from an authority figure, remaining unproductive until that occurs. When new problems or needs (not impediments) arise, those problems may need to be taken to someone in management and the manager’s decision brought back to the team. During the Sprint Review, the team does not weigh in on non-technical issues and instead defers to the key stakeholders on what action to take.
In short — this is a team that must be led and, when left alone, is lost and unproductive.
Oh No! We May Not Be Agile!
Fear not. Agile isn’t an absolute thing. Agility is a spectrum, and most companies do have elements of agility. Very few are what I would call ‘pure draconian.’
So while I may say the words ‘not agile’ in this article, what I mean is ‘unaligned with some of the Agile values and in need of some calibration.’
The most important thing is awareness, because then you can put in the collaborative work necessary to move the team further up the Agile side of the spectrum. This is the job of your Scrum Master and a great discussion to have with them.
I’ll be following this up with another article to provide some tips and tricks for creating and maintaining an Agile (and innovative) mindset within your organization.
Realize that there is no perfect prescriptive solution or definitive set of steps to follow. Every environment is unique and has its own set of challenges. But a good Agile mindset is grounded in basic human needs and a desire to be effective. Empowerment, trust, empathy, understanding, and collaboration create better outcomes than administered, wary, indifferent, uninformed, and isolated behaviors.
In that regard, it makes no difference if you are using Scrum or not. If you aren’t practicing Agile values, you aren’t going to see results.
That’s all for now…get off of social media and go make a human connection!
