Starting Small with Agile: Your First 30-Day Experiment

Pick Your Testing Ground Wisely

First up, choose a team or initiative that's ripe for this experiment. The ideal candidate:

• Has a reasonably defined goal but flexibility in how to get there

• Involves 3-7 people (any fewer and it's just a chat; any more and it's a circus)

• Isn't currently on fire (don't test a new approach during a crisis)

• Has a team lead who's curious, not combative

Got your guinea pigs? Great. Now decide which flavour of Agile might work best.

Kanban vs Scrum: The Non-Technical Showdown

People love to debate Kanban versus Scrum like they're arguing about football teams. Here's the stripped-down reality for non-tech teams:

Kanban is basically a posh to-do list with limits. It's:

• Easier to start tomorrow

• Less disruptive to existing workflows

• Better for teams with unpredictable or reactive work (like HR or customer service)

• Focused on limiting work-in-progress (because humans are terrible at multitasking)

Scrum is more structured with defined roles and rituals. It's:

• Better for teams working toward specific outcomes

• More disciplined about timeboxing (those two-week "sprints" you've heard about)

• Heavier on meetings (sorry, "ceremonies")

• Focused on delivering complete chunks of value

For your first experiment, Kanban is typically the gentler introduction. Here's how to set it up:

Your 30-Day Agile Experiment: The Practical Bits

Set Up Your Kanban Board

Create columns representing your workflow: "To Do," "In Progress," "Review," and "Done" will do for starters. Use a physical board for small co-located teams (sticky notes on a wall) or a digital tool for remote work. There are so many to choose from. For quite basic needs and free access, you could try Trello or MS Planner if your company is on O365. Planner can be run as an app inside Teams, which can be handy to minimise the number of tools you need to open in a day.

The crucial bit: Set work-in-progress (WIP) limits for each column. This stops people from starting seventeen things and finishing none.

Daily Standups (Without the Drudgery)

Run 15-minute daily standups that actually work:

• Find a consistent time and location to help everyone to attend and be consistent. Most teams make it early in the work day, to set the tone, get spirits up and set up for a successful day.

• Avoid status reports. This is about team coordination, motivation and progression towards goals, not reporting to a project manager.

• Ask:

  • "What's blocking you?" - Tackle roadblocks first

  • "What would help improve your day today?" - Encourage sharing feelings about work and how those feelings could be improved

  • "What's on your mind?" - Create a culture where concerns/questions are shared, not bottled up.

  • "What are you NOT working on today?" - This helps to create opportunities for team members to support each other and pick up tasks from overburdened colleagues.

• Encourage sharing about wins/accomplishments!

• Not everyone will have a meaningful update every day, and that's fine. There shouldn't be pressure to share.

• Focus on the project goals. Updates are most effective when they relate to the bigger context.

The secret? Ruthlessly redirect detailed discussions to happen after the standup. The moment someone starts diving into the minutiae of their work, gently suggest they "take it offline" or hold a meet-after.

Some teams book a 30 minute slot for the daily- 15 minutes for the daily itself and an extra 15 minutes reserved for meet-after topics. If you don't need it, then don't use it, but it avoids calendars getting in the way of finishing an important discussion.

Break Work Down Properly

The biggest mistake non-tech teams make with Agile? Creating work items that are massive, vague, or unmeasurable.

Good: "Draft Q2 social media calendar for review" Bad: "Improve social media"

Break initiatives into chunks that can be completed in 1-3 days. If it takes longer, you've not broken it down enough.

Measuring Your Experiment

After 30 days, don't ask "Did we like it?" (that's just collecting opinions). Ask:

• Did work move more predictably through our system?

• Did we complete more high-value items?

• Did we reduce the amount of work stuck in limbo?

• Did we feel less stressed/pressured by using WIP limits?

• Are our stakeholders happier with the results?

• Are we better at identifying and removing blockers?

When Scrum Might Be Better

If your team is delivering defined "projects" rather than ongoing services, consider Scrum for your next experiment. But be warned: Scrum requires more commitment to changed behaviours and roles—including someone willing to be the "Scrum Master" who protects the process.

The Uncomfortable Truth

Most Agile implementations fail not because the principles are wrong, but because organisations cherry-pick the easy bits and ignore the uncomfortable cultural changes required. Your little experiment is just the first step in what should be a broader shift in how your organisation thinks about work.

Ready to take that first step? Remember, it's an experiment. If it crashes and burns, you've still learned something valuable.

Need help designing your first Agile experiment or figuring out which approach best Connects with your team's unique challenges? Our Agile coaches specialize in translating Agile Beyond Tech—without the jargon or the dogma.

Book a consultation!

Contact us

Whether you have a request, a query, or want to work with us, use the form below to get in touch with our team.