More than likely, you’re going to work in a company that is attempting to be agile. Many companies, while sincere in their attempt to leverage agility for better outcomes, tend to make a lot of customizations in their approaches. These oddities become what many developers encounter, see as normal, and then wind up hating. Let’s break this down from a developer’s perspective, how this is supposed to work.
Scrum vs. Agile
Before getting into the nuts and bolts, there is a clarification to make. Many companies employ a framework called Scrum as a way to become agile.
You may be thinking, what’s the difference? Well, agile is a set of four values and twelve principles.
Scrum is a straightforward framework that, when followed well, can allow teams and organizations to live with those values and principles while having better results.
Challenge
Do you know how companies decide to go agile? It starts with a team of passionate developers employing agile principles and values. Over time, their results mystify the rest of the company, who, in turn, decides everyone should work that way.
It almost always starts with a team of passionate developers who want better ways of working and better results. In a grass-roots way, they start doing Scrum.
I want everyone to know that as a developer in a team, it’s possible to do something radical. That’s how it starts; one person in one team wanting to do better.
Foundations of Agile
There are a few cornerstone elements to Scrum that must be identified otherwise it will hinder instead of enable you.
Self-Organizing, Cross-Functional Team
Big words used to describe what a team needs to succeed.
Most companies struggle with these two team qualities. For the cross-functional piece, they tend to limit the team composition to software developers. Well, most teams need help from designers, quality folk, marketing, operations, and legal. Getting access to these people is what enables rapid results, yet handing work off to the other teams will almost always cripple your results.
So, if you know you need input or different skills from another team, ask them for help!
Self-organization is when a team can make the decisions needed in order to be successful. Here are a common set of decisions that teams make when they’re thriving:
The scope of their sprint
How to handle vacation/sickness
Alternatives to project ideas
How to improve
If a new hire is a right fit
Managing deadlines
Tech-stack
Architecture
Your company may not be comfortable with all of these topics, but the trick is that if you can show that you and your team are capable of handling it, most of the time, managers will gladly let these things go. It’s less work for them, and if the team can do it, that’s a win-win.
Inevitably you’ll find some decisions that you can’t make. If you believe that it is one the teams should make, start the conversation, and find a way to try it with lower risk. This approach is how grass-roots teams do things. They start and push for what they believe to be right.
I’ve heard stories where teams even decided their bonuses and pay raises. It is possible to have incredible autonomy.
Empiricism
Another fancy word. Empiricism is about recognizing that you can’t know the future. So working empirically means that you try something, then take an honest look at the results before you try something new.
All of the meetings that exist in Scrum exist to enable empiricism. As a team, you all can talk about what it means to be empirical with your process, standards, quality, scope, and how you delight your customers. It all boils down to doing something small and looking at the results. This approach is the catalyst for doing less work that has a higher impact with better quality— all of Scrum’s parts exist to allow this to thrive.
Think about how you can be methodical with an empirical approach.
People
The following roles are needed on a Scrum team:
Scrum Master - Coaches everyone in Scrum and agility and facilitates the meetings. Serves the team and organization
Product Owner - Orders the backlog to optimize the value in it. Works with customers, stakeholders, and teams
Development Team - Delivers working product in regular increments. Could be software developers, designers, marketers, lawyers, operations, or anyone else needed to deliver the product.
Sprints
Sprints are a pretty big piece of the whole thing, and many teams wind up hating them. However, they can be a crucial element of success for teams that understand their purpose.
Sprints are a time-box where everyone attempts to deliver a more valuable version of the product.
Great teams understand that they need short time-boxes to be empirical and therefore learn and adapt. The time box forces small changes and improvements.
Great teams also know how to slice their work so that they deliver something valuable each time. The first version may be technically incomplete, but each sprint gets better and more complete. Slicing work is unintuitive but a radical approach.
The Agile Process
Let us look at the day-to-day that happens and where really powerful teams stand out. As you read, see if you can identify where the foundations of empiricism within the team fit.
Here are the essential Scrum meetings and their purpose:
Daily Stand-Up/Daily Scrum - To begin the day’s collaboration and coordination towards the sprint goal
Retrospective - Discover insights that lead to improvement
Sprint Planning - Collaborate on a plan that accomplishes a goal
Backlog Refinement/Grooming - Gain understanding and insight in upcoming priorities and value
Sprint Review - Gain feedback, and true up the work that has been delivered so far
1. Daily Stand-Up
This meeting is a 15-minute meeting where developers talk amongst themselves about how they’re going to get closer to their sprint goal.
That’s it.
I didn’t say they tell someone their status or report on a Jira board.
It’s about the team talking amongst themselves about how they’re going to succeed in their sprint. If this isn’t what is happening, this meeting tends to feel like a chore.
When it is working, team members start helping each other, they cut scope out of their sprint, and find alternative ways to accomplish their goal better.
2. Retrospective
This meeting is a chance for the team to improve. Teams that struggle wind up in a retrospective that is short, full of complaining and no action happens.
Teams that focus on having great retrospectives wind up finding Ah-ha! insights that they then turn into small changes that improve things.
If you’re not getting what you need from retrospectives, talk with the facilitator about it. You need to have insight before you have change.
An easy way to get started is to look at your team’s definition of “Done”. Then discuss how it’s working, how it is not, and what you can change to stretch the team to do better.
3. Planning
Planning happens in two parts. First, the team needs to see what has been ordered by the Product Owner, and then everyone comes up with a goal for the sprint. The goal is the reason for spending the time to make something.
There are no sprint commitments in Scrum!
Once the team sets the goal, they come up with their plan to accomplish their goal. It doesn’t have to be complete, but the team has to know what they’ve planned so far.
From this point on, the sprint is in the team’s hands.
The best teams are excellent about breaking their work down into small versions that take 1-3 days. Avoid large work items as big plans tend to fall apart in a big way.
Most teams work with the idea of committing to a certain amount of work each sprint. When teams only have a bunch of work to get done, they can’t make good trade-offs for the product, and technical health of the system. They need to know why the work matters and what the goals are. That information allows a team to find alternatives and innovate as they build.
The idea is that the team discusses what is important and why, then creates a goal that acts as a north star, and comes up with a plan to get to that goal. Scrum teams are goal and value-oriented, not scope oriented.
4. Refinement
Technically this is an optional meeting, but most do it. The idea here is to help get a preview of what is coming up. That way, when it comes time to plan, you’re already familiar with what is important.
Some companies want people to estimate or break things down here. The most important point is that you’re not completely surprised by the time you plan.
5. Sprint Review
This meeting is typically the weakest link in the whole thing. Sprint Review is when the team gets in the room with customers, stakeholders, and everyone else who cares. Then the team shows in full transparency what happened in the sprint.
They show the working software, and they talk through the goal and if they achieved it. They talk through the challenges. They hear what people have to say about the work. And the feedback in this meeting will alter the priority for the next sprint.
If you don’t have your customers and stakeholders in the room, get them in. This meeting is how you get the feedback you need on the work you’ve been doing. It can hurt, but eventually, it turns to trust, understanding, and a better ability to deliver what matters.
Summary
While this is an incomplete version of everything that exists in agility and Scrum, what I’ve seen over and over again is that teams who decide that they are tired of the status-quo leverage Scrum to create a better future.
If you want that, follow the advice outlined and avoid the pitfalls most companies fall into. If you and your team want better, get in a room, and talk about it, and take action.
As you change the culture of your workplace, leverage Scrum to learn and course-correct along the way.
