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.