RSS

Agile/Scrum procedures to follow even if you aren't an agile purist

Say as a developer one more time

My coworkers call me an “agile purist”, because I constantly want to abide by the “rules” at all times. Rules like:

  1. The sprint is sacred
  2. User stories need to be written
    1. From the perspective of the user. (They aren’t called developer stories!)
    2. In the correct format
    3. With reasonable acceptance criteria

However, I understand that full-blown Scrum is not for all projects, or all teams. So, here are some things I believe still need to be done even if your project/team-members don’t want to be “agile purists”.

Keep your velocity high

A simple definition of velocity is this: You receive a task, you work the task, you finish the task. Velocity is how long it took you to do it. You want your velocity to stay high, because that is how you GET. SHIT. DONE. You only get credit for velocity when your task gets done. If your velocity is zero, you aren’t getting anything done. You are dead weight on your team. If your task is 50% completed at the end of the sprint someone has failed. Either the task was too big (meaning your team messed up when refining and scoring the story), or your velocity wasn’t high enough.

Here are some recommendations on how to increase your velocity:

  1. Work on as few tasks at a time as possible. When I work in a sprint on my team, I have a single task assigned to me at a time. The only exception to this is if someone didn’t keep the sprint sacred by asking me to do something out of the scope of my sprint, or my current task is blocked by something out of my control. This is commonly known as single-piece flow. It comes from the manufacturing world and is one of the core concepts of DevOps. Check out this article for more info.

  2. Don’t allow scope creep. If the acceptance criteria for the task you’re working says “The lawn is mowed”, The ONLY thing you should do is mow the lawn. If the Product Owner wanted the edging done, or the sidewalks swept, they would have added it to the acceptance criteria. If you take it upon yourself to do “extra” stuff, you will spend all day working on something your PO didn’t care about. You could have been done in an hour, got your “velocity credit”, made your PO happy, and moved on to something else. This can also manifest as something called yak shaving. For an example, see Hal fixing a lightbulb:

  3. Keep tasks small. As mentioned above, your velocity is zero until the task gets moved to the “done” column, so keep them as small as possible

Enforce the standard meetings

If you are going to be a Scrum team, even if you aren’t going to go whole-hog on it, you need to make sure the right people are making it to all of the Scrum “ceremonies”. I usually see this breaking down one of two ways:

  1. A manager who is an integral piece of the Scrum process because they are either the Product Owner or the primary stakeholder starts skipping meetings because they are too busy with other things. Product Owners don’t need to be at EVERY meeting, but they MUST be at the ones they are a part of, which is always the Sprint Review. If your PO isn’t at your Sprint Review, there is no point in having the meeting and it should be postponed.

  2. A team member regularly skips the daily standup because they are either “too busy” or they don’t think daily standup is important. They are wrong. Daily standup is the touch point for teams to resolve road blocks and keep things moving forward.