Agile is not a process – it’s a mindset rooted in continuous learning by observing real world human behavior.
For a long time, software was built using waterfall, a long, sequential process that requires many handoffs between product, design, engineering, and QA. A project goes from inception to requirement gathering to design to build to test and then deployment. All that could take months, and by the time the software is released, business priorities might have changed, or users might not like what they got.
Agile aims to remedy this by putting software into the hands of users faster and then measuring whether the changes are delivering the expected business outcomes. If so, great, keep improving on what you have. If not, no worries – you learned something about why not, and you only invested a few weeks to gain that insight.
Switching from waterfall to Agile isn’t easy. But here are some tips to keep in mind.
Tip 1: Know the Roles
This is your “squad”:
The person responsible for ensuring the squad is constantly delivering business value through the product. This person often translates and prioritizes ideas from “the business” (CEO, strategy team, sales, marketing, etc) and customers for the squad who is actually producing the software.
The folks who do most of the building – focused on how to deliver business value from a technical implementation perspective.
The people who test changes before they go to users. Testing strategies fall into 2 main categories: manual and automated, with much emphasis on automation as a more scalable/risk-reducing strategy.
These folks translate stories into user journeys/experiences. Typically they’re sharing their ideas via wireframes (for User Experience or UX designers) or visual comps (for User Interface or UI designers).
This person’s role is to ensure the squad is efficiently and consistently delivering business value. He or she will schedule all ceremonies (see below).
Subject Matter Experts
Not required, but sometimes it’s helpful to have SMEs on the squad to answer complex questions (for example, if you operate in a heavily regulated industry, you might want someone from compliance on the squad to approve changes quickly).
Tip #2: Commit to Frequent Production Releases
A key output of the process is shippable software. It’s important to make always ship to production at the end of a sprint because:
- Go/no-go meetings to decide whether to ship are painful and time-consuming. More often than not, you’ll feel like you’re not ready and postpone, never knowing if you’re spending more time on something that’s not even going to deliver the business outcomes you’re expecting it to. Shipping often lets you get feedback (qualitative or quantitative) from real users and eliminates the time needed for release planning (you always release).
- The deadline creates a powerful forcing function. As the sprint end date nears, the squad is forced to make scoping decisions and rally as a team to ensure there’s something to ship.
Most teams use 1, 2 or 3 week sprints to dictate how often they ship to production.
Tip #3: Follow the Ceremonies
There are only 5 meetings that should happen every sprint:
A weekly hour-long session where the top of the backlog is discussed and estimated by the squad. Prior to this meeting, the product owner should prioritize the backlog such that the top items represent the most meaningful ideas to deliver business value / move the product KPIs.
During the meeting, the product owner should present each ticket, starting with the top of the backlog and the Scrum Master should ask the squad to estimate (I prefer estimating via planning poker because it eliminates any bias in estimates but there are other techniques). I’ve found asking for an estimate is the best way to force clarifying questions to come up from squad members – things like what users will this impact, what browsers are included, how will we know if we’ve succeeded (tie the story back to a KPI), etc. Anything to clarify the scope of the story or what needs to be true in order to be successful.
Assuming the top of your backlog is estimated, sprint planning is where the Scrum Master asks the squad to make a commitment to delivering specific stories/bugs in the next sprint. Ideally the squad is just determining how much of the top of the backlog they think they can take on, but there might be scenarios where new items that were not discussed in the last backlog grooming are estimated.
Key questions to ask during this meeting:
- How much did we take on last sprint? Did it feel like too much? Too little? Just right?
- Are there any other factors in this sprint we should consider? Considerable unknowns with some of the work? Production support spikes we might anticipate? Planned squad member vacations?
At the end of the meeting, the commitment should be clear to all, and the sprint should begin. The product owner may want to communicate the commitment to stakeholders.
This is a daily 10-15 minute meeting, typically in the morning but as long as it’s the same time every day, any time is fine. Each squad member should answer the following questions:
- What did you do yesterday?
- What are you planning to do today?
- What’s blocking you from doing what you planned to do today? (for example: I got pulled into a lot of meetings related to some other project at the company, I can’t test because the environment is down, I don’t understand what we’re trying to do, etc.)
Other squad members should listen for blockers in particular, but also items that might require some collaboration (for example: “oh, you’re working on that? I had some ideas, I’ll find you after standup”). Scrum Masters should be making sure the squad is on track to deliver their sprint commitment (burn down charts are helpful for this) and that there is a game plan to remove any blockers that day.
This is typically a 30-60 minute session open to the squad and all stakeholders to see what was shipped that sprint. Squad members (including technology) should demo the changes, perhaps providing some color commentary or “behind the scenes” on what it took to implement. This is a great place to test squad communication – anyone should be able to get up at the showcase and explain the background/rationale for the change, along with demoing it.
After or during this meeting, stakeholders should provide feedback to the product owner. (ex. “looks great”, “wait, I didn’t realize that’s what we were gonna build – tell me more”, etc.).
This is typically a 30 minute meeting for the squad between the showcase and sprint planning. The outcome of this session is to identify from a process perspective, what went well that sprint and what could be improved. There are a few ways to do this:
- Go around the room and ask each squad member what went well and what they would change
- Ask folks to fill out a short form before this meeting, then identify themes and discuss
- Ask the team to write down what went well on Post-Its and put them up on a wall. Then do the same for what could be better and discuss each Post-It afterwards
- Bring up the sprint burndown chart and discuss whether it looks right (ideally you’re claiming points evenly throughout the sprint – something is wrong if it looks like a cliff where all points are claimed on the last day of the sprint)
I’d recommend switching up the format of this ceremony periodically (not necessarily ever sprint) to keep this meeting fresh.
Another key part of the retrospective is addressing the feedback that comes up - if needed, create action items with owners and deadlines and allocate time in the next sprint. Nothing deflates the value of a retrospective than a feeling from the squad that things aren't getting better.
It’s really tempting to skip these ceremonies because “it feels like a lot of meetings” but if you’re doing them right, they’ll go by fast and you’ll understand the value of them.