Shape Up Forum

Explaining the Hillcharts

#1

Hi at Avocode we are currently running the first development cycle, for now, we decided to skip tracking progress via the Hillcharts.

Some reasons why:

  • We didn’t fully understand it
  • We don’t use Basecamp so we didn’t want to waste our time with setting it up in a different tool

Now we are only tracking the progress via To-do lists which works ok, but still, it doesn’t tell you the exact progress of the project. So, I’d like to implement the Hillcharts method for the next dev cycle, but the biggest thing I struggle with is how to explain it to the devs. How did you explain to your dev teams how to use these Hillcharts? Even for me it is a bit abstract and I can imagine questions like “How should I know where to put the dot if I discovered this and this etc.”, “How should we start?” and other similar questions. In other words, I need to be sure that devs will understand it because otherwise, they won’t use it. So any advice about the explanation to the dev team or experiences with using the Hillcharts will help a lot.

Thanks :wink:

#2

When explaining Hill Charts to my team I took direct examples, particularly the visual aides straight from the Shape Up book. Showing why To Do lists only work in theory and that in reality there is more work to be added to the list that is not yet captured. This concept of “found work” resonated very deeply with the engineering team and seemed to go a long way to internalize the concept of a Hill Chart and the problem that it is solving. Hope this helps for you and your team!

1 Like
#3

Something that I did was draw a physical Hill Chart on a whiteboard and used post-it notes to demonstrate how it works with an example. I also mate it clear that “where on the hill should something go” is mostly based on gut feel. There’s no science to it and they will get better at it over time.

As commented above, making sure they understand that new things will usually be discovered and added to the Hill Chart as they dicover them, and that is good. Rather than them trying to figure out all the dots to put on the chart from the start.

It sounds like you still may not 100% understand it yourself. If this is the case, it may help if you expand on what you’re still unclear about and we can help you with that. It’s very hard to teach something to others if you don’t really get it yourself. Hope what you’ve heard so far has helped!

#4

Thank you for both replies it helped.

@Aylon you were right I didn’t fully understand it too, that’s why I was concerned about explaining to the devs. Yesterday after your post I tried to dig a bit deeper in that and I think now it makes more sense. What helped was that I realized that I work the similar way during the shaping process so I tried to make a few Hillcharts for my work and it worked.

So, for the explanation, I’ll use my real experiences and maybe try to demonstrate it on one of the projects that are currently under development because I hear the guys are working the same way already.

Cheers :wink:

#5

The most important thing from Hill Charts to understand, in my opinion, is that you can be in the first half of the chart or in the second half. Where you are in the half itself is less important. Our team understood it far better when they got this distinction very clear.

The first half (going up hill) is when you are figuring things out, when you are testing assumptions etcetera. The second half is when (you think) you know what there is to do, you only have to do them, like mostly checking things off your todo list.

When there are still some spots that you don’t know how to solve, you can not be on the right side of the hill chart. I stress this very much to our team. The second half is only when you have things figured out.

When you have this distinction very clear, it is easier to create and easier to read the hill charts. The examples in the book make this clear as well. Especially the making dinner and shopping for groceries example made it clear for me.

Hope this helps a bit.

1 Like
#6

This blog post on SvN Running in Circles gives more background on the Hill Chart. Might be a nice addition to the chapters in Shape Up.

I agree with @Aylon that using Hill Charts isn’t exact science and is something you and your team will probably get better at by using it a couple of times.
During this time it does serve as a valuable conversation piece within the team and to others on where things stand.

#7

We have struggled with this at Zaarly as well. When we introduced Shape Up to our existing team, not forcing everyone to also switch over to basecamp helped to ease the transition.

While I personally like the hill chart approach in basecamp, our engineers wanted something more precise. So in the last two cycles we have left it up to the teams to decide who they’d like to show progress and made defining that one of the agenda items in our kick-off meetings.

All of our teams opted to stick with Github project boards, which seemed to work ok for them. We haven’t had to pull a circuit breaker yet and everyone feels generally proud of their work, but I do think I’m going to ask teams to make an “uphill” column or a “questions” column in front of the the “to-do” column in their kanban boards.

On one hand, it has been less clear to me where a project is at any given moment without those distinctions and I still have to reach out more than I care to for status updates. On the other hand, we hold a weekly demo day and that goes a long way to helping us all understand where a project is at.

1 Like
#8

We’ve introduced something new this Cycle that I’m hoping will work. Still in week 1 so we’ll see.

We use Azure DevOps and on one of the boards where the team would create their Scope tickets, we only have the following columns

  • To Do
  • Figuring out (Had Unknowns)
  • Getting Done (No Unknowns)
  • Done

I do lose getting any sense of progress within those columns, but at least I can stage of the work the various things are at. If they are moving along or stuck there still requires manual intervention to find out, which is a shame. But this feels like a good start :slight_smile:

#9

During the cycle, is it ok to jump between left and right? We experienced several rabbit holes that came to light as we were going through the cycle. We ended up moving scopes we thought we figured out back to the left. Is that common or an indication that the pitch wasn’t defined well enough?

#10

Is it ok to … move back to the left? … Is that common or an indication that the pitch wasn’t defined well enough?

No, it doesn’t tell you anything about the pitch. It’s about how that piece of work was scoped. It could be a few things…

  • It’s possible somebody moved it over the hill because they had it worked out in their head but hadn’t actually validated it with enough implementation. There should be some real hands-on work on the uphill side that proves the hypothesis before you consider the scope to be over the hill.
  • Another possibility is the scope was too broadly defined. If the scope has too much stuff in it, it’s hard to ever be done. But if it’s tighter and smaller, you can see the edges more clearly and just get that one piece done. This means you need to factor more (break things apart more).
  • Sometimes you think a scope is small enough but it turns out to be bigger than you expected. Let’s say you have a scope for “reply notification” and you move it over the hill, but then you realize there’s a weird issue with notifications on the phone. Instead of moving the scope backward, first check if all the rest of the work, without this phone issue, is actually over the hill. If so, you can just narrow your definition of that scope and think that this is referring to all the work except for the phone thing. Then continue to track that work and create a new scope specifically for the phone issue: “reply notification on phone.” This lets you identify the unknown and track your progress of figuring it out without muddying the water of the other work that is going along just fine.

See “Prompts to Refactor Scopes” in Chapter 12 for detail on this.

And here’s a piece on the first case, where you mark the work as over the hill without doing all the real work to validate it: Real Work vs. Imaginary Work.

I’m curious to hear if that helps or if you’re seeing something different.

.

1 Like
#11

Thank you for your thorough explanation and tips. As we’re just ramping up our next cycle it will be really interesting to see if we can do a better job at scoping. I’ll be happy to report back.