Hot to properly split cycles, projects and scopes

1

Hi everyone! Just discovered this forum and it couldn’t have happened at a better time.
I’ve read Shape Up in the past but didn’t have the opportunity to put it into practice (I’m going to read it a second time soon)…

I’m currently working as a tech lead for a small company in Brazil and was just recently given the opportunity to adopt a new strategy for my team. The team is composed of 4 senior developers (including me) and we have been working in (loose) cycles of 4 weeks for the past 2 years using Gitlab’s boards to do a little bit of Kanban (backlog → to-do → doing → done).

Since this is a greenfield project, we had a lot of “flexibility” around scoping our work - not without major challenges though, like dealing with stakeholder’s and client’s volatility and expectations.

This is a reality that probably won’t change because of the company’s culture and background. However, the technical team did and still does its best to remain detached from this reality. I’m comfortable saying that we feel like we work almost as a separate entity within our current company that has its own culture and processes, trying to deliver as much value as we can - given our constraints, of course.

So, after this introduction, I’d like to ask for some advice about some points I’m still unsure regarding implementing Shape Up at work…

What we are doing today

  • I started our first cycle with shaped work and it’s going very well so far (the amount of visibility the team has gained is noticeable from my end). By shaped work, I don’t mean work that is just well specified but also structured in the sense that we can now remove most of our unknowns and still give the team flexibility enough to come up with the implementation by themselves.

  • We are using Gitlab’s Milestones for cycles (deliverables) and we have a board for planning where I shape the work we are going to deliver (since I’m the oldest employee in the company and also the one that has the most history with the product) and development, where the team and I push the work forward to completion.

  • We have issues (features) that have a pre-defined budget of up to 4 weeks that we have shaped, pitched, and bet on before committing to work on it.

  • Each issue has tasks that the team ads while they are working on the discovery phase (to-do → discovery → doing → done); it’s not perfect but we are trying our best to adapt the process¹.

¹I’m still trying to convince our CEO to buy a license of Basemcap so we can improve our cross-team communication and gain visibility on our processes, but the currency rate exchange makes this decision a little bit harder than it should be.

The things that are not completely clear to me yet

  • It seems to me that when a new cycle is announced, I would have to create Basecamp Projects for each cycle project that I have. The problem is that because we are a small team, this means I’d have one person per project most of the time - which kinda defeats the purpose of having a shared space to work (in my mind at least).

  • It also seems to me (looking at the book examples), that I would define each project in the cycle in terms of a single feature, while the scopes (to-dos) represent the feature’s “requirements”. However, in our current scenario, we have very small features that don’t make sense to bet even 1 week of work on but are still important enough to be tracked. Those features usually compose most of our work routine… This means that someone will usually work on something and be ready to deliver another piece of shaped work. It seems to me that creating Basecamp Projects for this kinda work is a bit too much, but I don’t have another alternative yet.

  • Another thing that happens very often is that we have to release software mid-cycle. This of course, only makes sense for work that is already done, so we should be capable of delivering value as soon as possible if a client emergency comes up (and I’m not talking about just bugs here).

  • Right now I’m adapting our Gitlab board to adjust the team’s capacity inside our 4-week cycle. So no one takes two features (projects) that we bet 2 weeks on each or one project that we bet 4 weeks on. I also watched Adam Wathan’s talk with Ryan Singer (@rjs) in the past and they talk about scoping work inside a “box” to have a kind of self-organizing and controlled chaos. But I’m not sure I’m tackling this properly for our use case.

I’m doing my best to adopt as many elements from Shape Up that I can and I know we are already getting some benefits from it. I also believe that we have a long road to maturity as a team and I’d very much appreciate critics and suggestions to level up our team’s planning skills.

Cheers!

2

Three options to consider:

a) Save this smaller work for the cool-down period between cycles
b) Bundle these small tasks into a “small batch” project and set an appetite to it
c) Take the smaller work out of cycle and dedicate someone to tackle this list Kanban style

I think Shape Up is compatible with mid-cycle releases, although it is not best practice. I think the trade off is that it breaks the “uninterrupted time” principle of Shape Up. One of the first things I did when I started Shape Up (in addition to killing all the Agile meetings) was to enforce a release cadence, e.g. only one mid-cycle release per six-week cycle, and only on Tuesdays (so the devs could predict when their time would be taken from them). So while I couldn’t get rid of mid-cycle releases, I could make them less frequent and more predictable.

Best of luck trying to implement Shape Up!

3

Hi @nt-from-chicago, thanks for your time!

I was about to post when the forum went offline and had to wait until now to respond to your comment :sweat_smile:. Even though some perceptions have changed, I’ll post my initial comment with a small update at the end for context’s sake.

Because of low team capacity, I think option c) is out of the question. It also does not solve the problem we have today with process transparency, since Kanban’s “definition of done” gives little to no information about the actual work - it only deals in absolutes (done/not done).

Option a) seems the de-facto answer to this kinda problem, but since most of our work is composed of those “small projects”, I think all of our cycles would turn into a big ‘cool-down’ period :sweat_smile:.

Option b) seems very reasonable and I can see how this would work in practice, except it doesn’t answer my biggest question directly: For example, how do you set up this within a cycle (see my previous remarks)?

I do believe that’s the case and I agree it’s not the best practice, but it’s a compromise on my end to stimulate our environment to change. I figure that once this process is well established, we’ll gain a little thrust to improve our async work skills in the future.

Update 28/08/2021:

Since the last time we interacted, I ran two cycles end-to-end with my team and this helped me to test some theories in practice. I’d like to share my experience so far:

  • I tried bundling two to three tasks inside a “support” project within the Cycle but it gets very confusing to track scopes on the TODO tool with the current version of Basecamp (It seems that Basecamp 4 will solve this by allowing more tools per project though).

  • With only three developers now, everyone is doing a little bit of everything. Even though I’m still doing most of the planning and shaping myself, the team agreed that at our size, everyone is responsible to push forward the projects we bet on.

  • Each project we bet on has one person responsible for orchestrating the delivery. This means that we can scope three projects per Cycle and each “project lead” can coordinate with the other two developers if necessary. On this part, Basecamp has helped us by creating a framework that allows us to share information and have better communication.

Another thing that I’m going to try next is to go a little bit more “free-form” with some of the “small batch” stuff. We currently have a list of “quick improvements” that we are tracking. This list is composed mainly of tasks that don’t have enough input to become projects (bugs, small technical improvements, and R&D stuff). For us, these tasks are nice-to-haves, but it doesn’t make sense to have a project with a fixed scope and deadline attached to it (most of the time at least).

We have to be careful though as we might have other priorities for the Cycle, since those tasks can potentially consume more time than we want to spend at a given moment, the team is completely responsible for tracking the “scope” for those tasks and choosing if they’ll tackle it at the begging of the Cycle or at the end - usually projects will have priority. I can see creating a Cycle in the future with the same proposal as a “Bug Smash Cycle”, but for R&D work.

1 Like
4

Hey @tmg

Any new update on your shape up implementation?

In my experience for reactive work or some things that are not strategic projects it’s better to have some capacity in reserve.

I prefer to have a person designed as Pivot, that person will be most of the time in Slack waiting for reactive work and also attacking some of those minor bugs/improvements/small features. That person also can be assigned for “small devops tasks if needed”.

We are doing that with great satisfaction. In fact we detected that some people on the team like to be the pivot more than participate in the other strategy projects.

Regards!

5

Hi @jvillarejo! I’ve been running Shape Up for the past six months or so now and I think that most of my concerns were addressed by getting more experience on running cycles.

My team and I still have a lot of small-batch work as we approach the end of the product roadmap. For those cases, I still use the concept of “controlled chaos” where we tag a new project based on what value we want to deliver and just let the team ship what’s inside.

One of the things that Basecamp 4 did very well that helped me organize that, was allowing multiple TODOs inside the same project, which made my life a lot easier to bundle up multiple artifacts for delivery.

Another valuable lesson is that R&D work is and should be treated differently. We usually run those on the sidelines until we have enough information to identify delivery boundaries and define the “work shape”. For some cases is useful to define a time limit for this kind of work, mostly if we have a rough idea but are not quite sure on the execution yet. However, if we don’t have any previous information on a subject we extend the work until the team can have an informed opinion on the matter to decide.

There’s this post that DHH authored recently called Worrying yourself into excess, which kinda corroborates with another concept I head in the past called Assimetric Opportunity, which defines a situation or decision you put yourself in where the advantages outweigh the disadvantages. This is a very useful mindset to apply generally to the betting process because it facilitates understanding how much time you are willing to allocate to figure out specific problems. After all, you are “betting” time to extract the most value of a certain “outcome”.

IMHO, Shape Up is not a very bureaucratic workflow to follow and there are core principles that one can acquire by running it daily. Things like: well-defined boundaries, alignment of expectations, open communication, and process transparency are some of the pillars that I personally could identify as a drastic improvement in my day-to-day work. I think that most of those principles are actually better enforced by the Basecamp tools (which of course helps a lot).

Another thing that helped me tailor Shape Up to my team’s needs is this section of the book called Basic truths vs. specific practices.

6

Cool @tmg ! That’s great to hear!

Regarding this:

My only warning there with a lot of small batches is that maybe a lot of bureaucratic rituals might be taking more time than building time.

On R&D:

Totally agree with this, R&D work should be treated differently because the expectations are very differently, you don’t want to ship something but to learn if that path is correct. However an appetite should be defined as a stop lose so the team doesn’t run in circles.

Regarding Asymmetric Opportunities that’s the way we try to think about Bets. The best bets are the ones which you can identify the the upside is very big (it it goes well it has a huge return) contrasting the downside (opportunity cost). That’s the idea of Optionality on the book Antifragile by Nassim Taleb.

I try to pitch and bet on things that not only would have a huge impact on the customers, but also might be enablers for future ideas that also can have huge impact so they can compound.

You mentioned that you have a product roadmap, what’s the time for that roadmap? I would try to avoid roadmaps, because those make the team following a script, and if an idea for a powerful bet comes up in the middle sometimes is difficult to change the “roadmap”.

Sorry for the long post, I wish my comments were useful somehow.

Regards!

7

I agree, and I think that the concept of “controller chaos”, improves decisions in that regard because it makes the team optimize for what they can realistically deliver for a given amount of time.

The roadmap we work on is a loose definition of what the CEO expects from the product. I say “loose” because we usually only sequence key features that present extreme value from a product standpoint. It’s mostly an alignment of expectations with the stakeholders than everything else, not a commitment to ship anything at a given date (that’s also why we do this yearly).

The thing is when you are getting closer to “feature complete”, you end up with work that does not have clear boundaries and R&D becomes the predominant type of work (changing building tools, making CI a little faster, fixing bugs, improving UI, researching new technology, etc).

My concern at the time was exactly how much we were allowed to wing it without hurting the process, and I think that each team will have to figure this out in its own context to see what fits right for them.

1 Like
8

I get the uninterrupted time part; however, are we making a trade-off between that and the holding code in inventory (not shipping when we could to protect time)?