There is no merit in almost

Often times my team would finish a story 90% by the end of the sprint and move the following 10% onto the next sprint. “What’s the big deal” I thought, the work is still getting done eventually. Wrong. By delivering 90% you’re adding 0% to the product and from the customer’s point of view, you did nothing.

Everything is about delivering value

You should always be asking yourself, “How does my task at hand benefit the customer’s overall experience?”. If you’re having a hard time answering that question, then stop what you’re doing and make a fuss to your team.

Iterate in thin vertical slices

When you have a behemoth task at hand, it’s better to first start working on vertical slices rather than horizontal slices. What do I mean by that? Say for example you need to add a feature to your product that allows for a user to be able to import data from multiple data formats (CSV, JSON, XML). Rather than writing your stories to reflect individual technical tasks, write stories that deliver value. Have one story for each data format, instead of stories that don’t deliver any value like “Migrate data”, or “Update schema”. This allows for quicker iteration like waterfall but can be iterated over in hours and not days.

QA and engineers should be on the same sprints

Imagine you’re working on an awesome new feature: you’ve got your headphones on, you’re in the zone, you’re on the verge of a breakthrough and all of the sudden you get a tap on the shoulder; it’s your favorite QA engineer to talk about a story you worked on last sprint. Oh no! There’s a bug that will delay the release if not addressed. Now we have to add time to the current sprint to fix last sprints work. This cycle never ends unless your QA engineers are tightly coupled with your engineers such that testing occurs during the sprint and not after.

Shift the role of QA

Don’t think of QA as a separate department; you should consider them as part of your team. Everything that QA does should help you as a developer

It’s OK to have unused capacity when estimating a sprint

Its better to have the understanding that a team will start the next highest backlog item (but not commit to finish), rather than trying to find a tiny story to fill the gap. Often times committing to too much is worse than under committing and starting early on next sprint’s work.

Stand ups are more important than you think

I often read about engineers who hate daily standups, and to be honest I used to be one of them. Standups are about setting the tone for the day! Be professional, be friendly, get excited! Crack a joke, ask about their weekend, comment on a co-workers new shoes; get comfortable. If you’re the type of person who requires caffeine to function, come caffeinated.

Keep your standups short

If your standups are taking longer than 5 minutes, you’re doing it wrong. Each person should be able to tell the team what they did yesterday, what they’re doing today, and if they’re blocked, within 30 seconds. If it takes any longer you’re either a slow talker or you’re starting to diverge into a deeper conversation that doesn’t belong at standup. Have a conversation with you team during retrospective or some other time about being able to guide the conversation back on track. Everyone should agree on a signal that basically means “Politely shut up”. You can just say “off topic”, or “offline”, whatever gets the point across.

Take retrospective seriously

I’ll admit, I used to hate retrospectives. Sitting around a room for a half hour with my team asking the same questions every other week? What a waste of time, I thought. But in reality it was my own behavior that made it a waste of time. By actually being open and honest with my team mates I’ve learned how important retrospectives are. It’s a time to address issues with…well anything! Team dynamics, standups, specific stories, anything you want; it’s your team’s time to shine.