I’m sure most of you already have implemented some hybrid way of project (and org structure), mostly known as “Agile”. Following some principles, some not. If you have “sprints”, a whiteboard on the wall with some sticky notes, or you’re planning to test and deliver your software without waiting for the end of the line, keep reading.

Which is your concept of Sprint Planning?

The worst mistake you can do here is to only do follow up on the tasks. It’s a huge waste of time. It’s even worse if you’re “creating the tasks” in the same meeting, just as a ritual procedure. Completely meaningless.

Sprint Planning is the opportunity when the Product Owner can expose his point of view about which should be the direction of the project. Backlog items should exist and must be already designed before that meeting because they will be prioritized on it. That involves acceptance criteria, goals, deliverables, expected docs, etc.

It’s painful to realize that most teams fail on this. Most Sprint Plannings are a boring 1-hour-long weekly standup.

Who is the Scrum Master? Who will be next sprint?

A couple of days ago, I saw at LinkedIn a person willing to hire a “Scrum Master”. The first thing I thought was: “What a shame” because the concept of Scrum Master means somebody who in the current sprint will be in charge of speeding the process, coaching and unblocking team members. It can be the Designer, the Architect, the Developer… anybody. In fact, that role should have a rotation making sure all the team members will do it least once.

What I’ve seen in most companies is a single person (mostly the Project Manager) who takes the ownership of that role without being asked to do it. That’s a huge mistake. Let’s go with our first truth:

Scrum is an agile framework designed to work with horizontal teams. There is no managers, just team members and customers. If you do something like putting a “manager” above the team you already failed. And the failure will be incremental through the entire project. At the end of the project (if it ends someday) you’ll remember me.

The Scrum Master is the coach, the facilitator, the unblocker. But also, is the glue that holds the team together.

1. Empower your team, don’t micromanage
2. Trust and build trust
3. Advocate, advise and enable
4. Follow through on promises
5. Solicit feedback and own mistakes

At Scrum, managers are deprecated

Awkward truth. But it’s a fact. To establish a relationship of dependence between “Managers” and “Employees” isn’t compatible with Scrum principles. If your legacy-old-corporate hierarchical tree needs to have “managers” and “employees”, please make sure you have:

“Scrum Master” instead of “Manager”
“Product Owner” instead of “Project Manager”

If you’re a Manager or a Project Manager, (aka SDM and TPM in some big companies like Amazon or Microsoft), please. Act like it. Stop being a Manager. Act like a Scrum Master. Act like a Product Owner.
Kanban will help you to avoid bus-factor

If in your team you have four developers and they’re developing different features, they must know about the features the rest is developing and be capable to work with those features. What if one of your developers get hit by a bus and no one in your team knows how to continue his work?

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, from the phrase “in case they get hit by a bus”.

Don’t limit developers to a single feature. Make them able to participate in other features as well. Kanban will help you with that. It follows the common practice of distributing tasks between columns (commonly: TODO, Doing, Done) but with a particular key-element:

When you’re done with your task, you’ll take the immediate next one in the TODO list, even if it’s related to a different feature you were working on in the last task. That will ensure everybody knows about every feature. If there’s something to fix in the future, the entire team will be able without any hassle.