Tag: Templates

by Kent McDonald

Did I get your attention? That’s a pretty bold title for an article on a site that offers subscriptions for templates and checklists. I could just have easily used one of these titles, which may be closer to what I’m getting at:

“A fool with a template is still a fool.”
Or “Templates don’t mess up projects, people with templates do.”
Or how about this: “You can lead people to knowledge, but you can’t make them think.”

Perhaps I should explain.

I was working with a team recently helping them to address some challenges they were having with backlog refinement in a Scaled Agile Framework (SAFe) setting. (No, I’m not trying to pack this article with buzzwords to get you to read it, but if it works, well, go with the flow I say.) As we discussed a couple of different tools to help them with backlog refinement, a couple of people said, “You know, I think we do that, but it ends up being a ‘check the box’ activity. We do it to say we do it, but then move on, and we never really seem to put any thought into it. So we technically do it, but we don’t see the benefit from doing it that we just talked about.”

And there, my friend is the insidious evil of templates and checklists.

Objectives Are More than Just a Field on the Project Charter

The first case we talked about was establishing SMART objectives for a project (Epic in SAFe terms). I use this definition of SMART:

• Specific
• Measurable
• Agreed-upon
• Realistic
• Time-framed

Creating objectives with SMART characteristics is the best definition of scope you are going to find.

An example of a SMART objective might be “Reduce the number of paper claims received from 1,000 per week to 500 per week by the end of 2014.” Creating objectives with SMART characteristics gives the team a shared understanding of what success looks like for the project. This is also the best definition of scope you are going to find.

How can you define scope as an objective? By establishing the scope of a project as the things you need to do in order to meet that objective, you provide the team with a great deal of freedom to figure out the minimally viable way of getting there. Defining scope based on that rather than a list of items (i.e., a backlog) increases the chance that you will stop when you achieve your objective. Keep in mind you’ll have other constraints regulating what you do, including our friends Budget and Deadline, so it’s not going to be a free for all.

But if a team just sees a place for objectives on their project start up template, hurriedly scribbles something down, and thinks “Whew, got that done, we can now head to happy hour,” they are doing themselves a huge disservice.

The conversations a team has surrounding identifying objectives builds a shared understanding of what they are trying to accomplish. Determining that 17 objectives is too many for a single project (don’t laugh, I’ve seen projects with that many objectives) and narrowing it down to a set of three can be very powerful. These highly-focused objectives will also provide a great guide for decisions throughout the course of the project when team members struggle with day-to-day decisions.

Prioritization Heuristics Are There for the Conversation, Not the Number

SAFe suggests (prescribes?) a technique called Weighted Shortest Job First (WSJF) for determining priority of features. It’s predicated on the idea from Don Reinertsen’s book The Principles of Product Development Flow that you should consider the economic factors of your project to determine what to do when. WSJF combines the economic theory from Reinertsen with the perceived benefits of relative sizing to provide an “easy” formula for coming up with numeric ranking of features. The approach works great when this heuristic is used as a guide to a conversation and the people doing the ranking (usually Product Management) discuss the relative rankings of each parameter in the formula, then use the resulting WSJF number in conjunction with other information to make an informed decision about priorities.

The trouble comes when you have multiple Product Managers introducing features and using the WSJF scoring for their own features in isolation. When these Product Managers get together and use the WSJF number as the only source of information about how to prioritize, they can end up thinking “this isn’t working” and stop using WSJF altogether.

Some people suggest that sticking with real numbers is a more meaningful way of utilizing the Cost of Delay information (I strongly suggest looking at the work of Joshua Arnold on his site BlackSwamFarming.com), but the relative numbers used in WSJF can be helpful if:

• They are derived from joint discussions among the people who are responsible for prioritizing features (and probably identifying them)
• The resulting information is used as a guide to prioritization but is not blindly followed

The relative scoring of features using WSJF is very similar to the relative sizing of user stories, in that when done correctly the collaborative approach to relative sizing is an excellent way of getting assumptions, knowledge, and constraints out of the head of one team member and into that of the others. In other words, it builds a shared understanding of what the story (in the case of sizing) or the feature (in the case of WSJF) is intended to be about.

You don’t want to use WSJF information blindly. The group I was working with told me of several situations where a feature considered extremely valuable on the surface (especially by the person who came up with it) ended up being marked fairly low on a WSJF ranking because it would take a long time to deliver as initially described. (Job Size is the denominator of the WSJF equation.) Theoretically this is right and proper — the shorter the job the sooner you want to do it so it’s not clogging up the flow. However when the team saw this happening they thought the WSJF was not working. A better approach would have been to see what aspects of that feature were adding the majority of the value and split it up so those parts could be delivered sooner.

Why Ask Why

In both of these cases, team members had lost sight of why they were using a technique, a template, or checklist.

In both of these cases, team members had lost sight of why they were using a technique, a template, or checklist. Or perhaps they never did know why they were using it. I see that happen all too frequently when new techniques or templates are introduced. When (if) people receive training on the new technique/template, they’ll often receive instruction (orders) on what it is and (hopefully) how to use it, but rarely any guidance on why to use it. There are a variety of reasons for that, which I don’t think I can go into without taking pot shots at those who create and rollout methodologies and tools.

That’s unfortunate, because most techniques and templates are very helpful when those using them understand the proper context and why the technique/template is helpful. With that crucial information, even the simplest technique or template can be extremely powerful. If that information is missing, something intended to be helpful can actually become detrimental to the progress of a project.