What Scrum got right

Scrum was a huge change in how software was built and a lot of its ideas are great, but some also have major problems.

Most of my experience is in early stage startups and may not apply as well to larger organizations, though I think a lot of it still does.

What scrum got right

Continuous improvement: Retrospectives on a schedule to keep improving the process for the team.

Daily stand-ups: Help make sure people aren't spinning their wheels and help collaboration between team members.

Demos: Keep everyone up to date on what's working and get feedback. More important as the team grows.

What scrum got wrong

Sprints: I really hate sprints. They cause constant deadline pressure that isn't helpful and doesn't help get work done quickly. In my experience it just burns people out.

Sprints, even short ones, always have other tasks/stories that come up and need to be done during the sprint. I've handled this differently on different teams. In one we had a rotating role that only worked on bugs and one off things that came up during the sprints. Most of the time it just ends up meaning something else on the sprint doesn't get done.

Priorities can change at any time and waiting for the sprint to end to adjust just delays things in the best case and causes work to be thrown out in the worst case.

"Work expands so as to fill the time available for its completion" - Parkinson's law

Sprints lend themselves to this and it almost always works that way. This is kinda of a double hit between sprints and estimation.

Now for Estimation...

The idea of estimation by points in scrum is good, but in practice it doesn't work well and doesn't provide the business any more meaningful expectation of completion then just ball-parking an estimated date.

I know there are lots of reasons why business wants estimates from the development team. But I really don't think development, specifically custom development like in a startup or quickly moving team, can be estimated with any accuracy.

My process or at least my starting point.

• Monthly retrospective & OKRs review

• Daily stand-ups or check-ins.

• Prioritized backlog of stories or tasks.

  • Releasable, can be released.
  • Small, under 3 days of work.

• Kanban board to pull work though.

  • Backlog: Priority ordered stories.
  • Blocked: Things that can not be worked on right now.
  • WIP: Work in progress is moved to verification after it's deployed.
  • Verification: This should be done by product people.
  • Completed: Tested, in prod, and verified.

• Continuous Delivery

  • Automated Unit tests
  • Automated Integration tests
  • Automated Deployments

• Scheduled Demos

Retrospectives & OKRs

I like doing these once a month and I like the normal:

"What'd we do well, What can we improve, and What should we stop"

I think the last one is the most important for improving the process.

OKR's or goals are good to have and review in these meetings. Without them, people don't know where they are going. I want everyone to know where we're going and let them figure out how to get there.

Daily Stand-ups

Again I like the normal scrum:

"What did I do yesterday, What I'm doing today, and I'm I blocked on anything?"

Though, I mostly don't care about the first one.

"What am I doing today?" gives the rest of the team a chance to jump in with helpful information or questions that might be related.

"What's blocking me?" allows me to help remove the blocks and keep things moving forward. I'd rather hear about these before the stand-up, but sometimes people don't know they're blocked until they think about it.

The Backlog

This is just a list of stories in descending priority order. It up to the product and the development team to keep them in order. Having clear goals will help this happen.

When someone is ready to work on something, they take the closest to top thing that they can do. This helps with cross pollination because the top thing might not be the normal stuff they work on, but they should still choose it if they can.

Stories should be releasable bits of functionality and have some clear value, even if it's really small.

They should be about 3 days of work with a very general ballparked estimate. If it's more than that, break it down further.

The development process

The idea is to pull a story on the backlog to working in production. We need a few things in place for this to happen.

• Code should have automated tests. Mostly unit tests with some integration and some acceptance tests as the system grows.

• Writing and running test should be easy for each project.

• All code checked into master should be releasable and should be released with an automated process.

• Code changes that feel like they should be reviewed, should be done with a pull request.

With this in place, the general flow goes something like this.

Take the top story and move it to Work In Progress (WIP). Once it's released to production, move it to Verification and notify the story creator. It then becomes that persons task to take a look at it and move it to complete or back to WIP.

The hard part: The number of things in progress, WIP, Verification, Blocked, should be close to one per team member. If verification starts building up you should work with the team to get those cards verified before taking another card from the Backlog.

In the past, I haven't enforced WIP/Verification limits to the number of things in those states, mostly because people will just work around them.

Lastly, there is usually a Blocked column or state for things that are blocked. Having a column allows it to be noticed and unblocked quickly.

Demos

Get everyone on the same page!

There are two things that need to be demoed, production features and development features. While these have different audiences I think it is valuable to demo both at the same time.

Demos should happen on a regular schedule like weekly or every other week.

No Estimation

Some business have deadlines, but most business don't have many, if any, hard deadlines. So trying to estimate ends up being a waste of time and a self fulfilling prophecy.

There are lots of arguments on both sides of this and reality is always somewhere in the middle.

My approach is to keep the stories in the backlog to a size of 3 days work or less. And that 3 day estimate is just a quick gut based guess.

If there is a deadline to a need to communicate a date to a customer, I like to talk through the details of that specific thing and figure out a plan.

But we need some estimation and plan...

I recently came across the idea of GIST Planning which seems like a really good way to manage roadmaps.

I don't know the right answer here, but I think traditional roadmaps and detailed estimation isn't it.

What other approaches have you used for this?