The Galactic Empire was defeated by WIPAdded to Process
Starting a new project can feel as daunting as taking down a powerful empire headed by a dark force, especially at the beginning when the project’s scope looms over your planning sessions.
Yet the instant your team begins breaking down that project into smaller pieces, it doesn’t feel so impossible. Taking some inspiration from a faraway galaxy’s original one-man show, there are some lessons you can teach your team about work in progress (WIP) and the Agile mindset.
“Over my dead body!”
AKA: Retrain the way your team thinks about WIP
In Star Wars: Episode IV, Han Solo is cornered by Greedo the bounty hunter. Determined to take Han Solo in for cheating Jabba the Hutt out of money, Greedo threatens him. Han’s quick response ignores the danger posed by the hired gun in front of him.
And so, like Han, your team’s first response to change might also be a knee-jerk response. If they’ve attached their identity to a business process or organizational structure, then switching the way they use work in progress (WIP) might feel like an existential threat.
Getting your team to use WIP to keep pace with project milestones means easing them into it, especially if they’re more accustomed to starting a second project when they have a blocker they can’t get around. If they’ve learned Agile with another team or company, they may also be reluctant to let go of their old WIP habits, reinforced by lax project managers.
The spectrum of Agile frameworks (Scrum, Lean, etc.) is massive. Chances are good that the team’s different Agile experiences are creating blockers within their current projects. Forget fighting old WIP habits—instead retrain a team on the goals and purposes of Agile and let the principles guide the processes and actions.
Like Han, regardless of the danger the project is in, a team’s first response may not be their best response. If your team resists your encouragement to finish what they’ve started before adding more work to their plates, you need to help them understand the underlying Agile principle at play.
“Uh, we had a slight weapons malfunction, but uh…everything’s perfectly all right now. We’re fine. We’re all fine here now, thank you. How are you?”
AKA: Keep the WIP manageable
From the get-go, you need to create a culture of honesty. Maybe if the empire’s stormtroopers felt safer going to their bosses to confess insecurities or admit defeat, the general on the other line from Han Solo would know that he wasn’t hearing the sound of an overwhelmed “stormtrooper” when he called to check up on the “weapons malfunction.”
You’ll have to crack open those communication lines if you want to have an honest conversation about the amount of work that’s manageable for your team. You need to practice open communication with your team because, like Han Solo, when the team is placed under pressure, they might redirect your attention rather than admit they can’t finish their WIP.
Honesty is the baseline of accountability. Your team’s actions and statements should reflect that. If their PO asks them, “Can I have this tomorrow?” but they can’t get it to them tomorrow unless they pull an all-nighter, that’s not a yes. They should feel safe enough to push back on a request and be honest about turnaround time.
Being honest about work productivity levels helps your team keep the WIP at a sensible level, and gives stakeholders a realistic timeline for deliverables. Stakeholders deserve honesty, and your team will thrive with manageable WIP.
And they should be able to do that without using a blaster to shoot the communicator.
“Great, kid. Don’t get cocky.”
AKA: Celebrate WIPs, but keep your eye on project milestones
One spaceship isn’t going to win an intergalactic war. So when Luke Skywalker excitedly celebrates his first destroyed TIE Fighter, Han quickly knocks him down a peg.
Because when you’re up against an empire, you can’t get too excited about the destruction of a single ship.
Just like the Resistance is fighting a war that they can’t see the end of, your team may not be able to visualize their product’s launch. In fact, a common pitfall of Agile is a lack of clarity or vision. Don’t be like this.
When your team finishes a WIP, celebrate it. Briefly. But make sure they understand where the WIP fits into the project as a whole, so they can keep their eye on the final deliverable.
The iterative and incremental approach in Agile can make it so organizations miss setting clear goals because they have trouble managing both the short and long-term priorities. This is largely due to much of the work being undefined at the project’s beginning. As the project progresses, and long-term priorities are set, Agile teams can become too focused on WIPs and lose sight of the big picture.
One completed WIP doesn’t equal a finished product. Helping the team see how the WIP fits into the project as a whole can keep the battle, er, project’s momentum going.
“You said you wanted to be around when I made a mistake, well, this could be it, sweetheart.”
AKA: Make small mistakes with small WIPs
A huge advantage of Agile is the ability to course-correct at every step of the process. Han might call it a mistake, but in the Agile world, it’s just an iteration gone rogue.
One of the important principles I emphasize is embracing change early and often. Continuous learning and experimentation help a team work through what works and what doesn’t.
The best way to avoid a huge mistake? Start building the smallest thing first. Solving some of the smaller problems upfront will provide clarity and direction to the team. They’ll also answer several questions quickly that will help validate initial goals, success metrics, and outcomes. Keep your WIPs small and scale as you iterate.
“Look, your worshipfulness, let’s get one thing straight. I take orders from just one person: me.”
AKA: Teams can crush through WIPs together
Han Solo is a lone wolf. He’s a smuggler who doesn’t know the beauty of collaborating so closely together on a project that a person can’t identify their individual contribution—and Han misses out on the best part of being on an Agile team.
When Han takes aim at Princess Leia, over and over again, to emphasize that he’s a one-man operation, he loses out on the chance to build a team that can take down a Death Star.
High-performing Agile teams remove all silos, work cross-functionally, and strive for relentless improvement. They don’t need a boss. They take lessons learned and find new and improved ways of tackling problems.
Sure, an individual could work alone on a feature, but the creativity that a cross-functional team brings to the table is why Agile is so effective. How many times are Han’s ideas the worst ideas presented? A team’s diverse skills and experiences mean that they can come up with more than one solution for a problem rather than just blasting their way through an obstacle.
A cross-functional team works smarter, not harder. As a team nears the end of a sprint, instead of picking up another project to carry into the next sprint, they should lend a hand to finish up all of the work from the current sprint. In fact, this is one of the ways you can tell when a team has internalized Agile principles—when they limit work in progress.
Defeat the empire
AKA: Keep your WIP small
Agile is intended to provide incremental value so the team focuses on prioritized work instead of tackling every need, problem, challenge, etc. That’s where the beauty of WIP comes into play.
It’s like fighting a strategic skirmish every sprint, and then one day you look up and you’ve launched a minimum viable product (MVP).
So if your team is struggling to complete key deliverables on time, maybe it’s time to retrain them on what WIP should look like. Small projects that end up stretching out over sprints can sap a team’s energy. Instead, teach your team to keep the WIP as minimal as possible to be effective with deadlines, open up the lines of communication, allow for small mistakes, and help the team complete their WIPs on time.
A small Agile team concentrating all of its energy on winning each skirmish can eventually take down a massive project like the Death Star.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.