You can start with the minimum viable process right now (Standups, a Backlog, and Demo/Retro). You can use this foundation to build a customized process framework that works for your team.
Frustrations with Heavy Process
The Software world seems split between process dogmatists and pragmatists. Dogmatists believe that the entire canon of Scrum practices must be enacted as a whole, or “you’re doing it wrong.”
I couldn’t disagree more – every process was designed to solve a problem in a particular context. This attitude runs rampant, and many teams chafe under the weight of heavy process. This post aims to enumerate the minimum viable scrum process.
Think Critically: A Process Should Solve a Problem
Any process or rule should solve a specific, measurable problem. Processes should exist to make your life better. You should know the problem(s) each process is intended to solve and answer:
- Is it working?
- Do you still need it?
Guerilla Scrum: Core Processes
I call these core Scrum processes Guerilla Scrum, the minimum viable process to get started and generate what you need:
- Daily Standups
- Single, Prioritized Backlog
- Fixed Iterations
- Demo & Retrospective
You should do a standup meeting every day to talk about what work you did, what you’re working on, and what you’re going to do. This helps spread info throughout the team and identify people who are stuck. It should take less than 10 minutes. I like to do it right before lunch to make one big interrupt in the middle of the day.
Single, Prioritized Backlog
You should have a single place people look for work and the work should be sorted by what’s most important. This is where you track new features, bugs, and anything your developers spend time on. Ideally your work should be written as User Stories, but that’s not necessary. This helps the team stay busy and do the most important things at the time.
Pick an amount of time, 2 weeks works best in my experience. Start pulling work from the top of the backlog and ship whatever you can completely finish & test in 2 weeks. Don’t start anything you can’t finish before the release date. When you’re done, ship everything you did to production. Limit scope, but don’t sacrifice quality.
When you finish your iteration, let every engineer demo the work they’ve just completed to the team and everyone else in the company. This creates closure and a sense of accomplishment, as well as finding out if you really solved the problems people expected.
After the demo, have a retrospective on the way the iteration went. Figure out:
- What did you do right? How can you keep doing it or do more of it?
- What went wrong? How can you fix it or prevent it next time?
- What are on-going issues you’re deferring tackling?
THIS IS THE MOST IMPORTANT PRACTICE. You can use this retrospective to adjust your process, add new processes, and remove things that are just getting in your way. If you do this earnestly and honestly, you can generate any new processes you need to solve your problems in the context of your organization through continuous improvement.