How to improve developer-led project management within build cycles?

#1

Hi all,

I’m the Product Owner in team of 6 developers, 2 UI designers, 1 QA, a head of development and a CTO. Our company is called Tempo, and we’re based in London. We’ve been doing Shape Up for the past 8 months, and work in 6 week cycles with 2 week cool downs.

When we kick off a project, we include slightly more than we think is likely attainable in that build cycle within the pitch document - sometimes we’ve been guilty of going overboard here, which has added unnecessary complexity and confusion to the cycle.

However to aid the project management and prioritisation aspects of the build cycle, within the document we identify the ‘core solution’ that the pitch should focus on. The core solution is determined alongside the head of development, and we believe it to be more than attainable within the 6 week period. If that doesn’t even get built then that’s fine, it’s just to be expected sometimes as things turn out to be harder than first imagined once you set out to actually build something.

To help task prioritisation within cycles, we list each solution in descending order of importance in the pitch document. However, these solutions often include little tasks within them that need further prioritisation, and sometimes the build team loses sight quite quickly of what the stated priority solutions are.

I therefore spend a lot of my time project managing, rather than product managing. It’s not very scalable, and we’re already a bit stretched on the resource front.

Therefore, one issue I have as the one product owner between these 6 cycles - that all run concurrently - is having enough time/resource to prioritise each individual task and therefore project manage each cycle individually. I know Shape Up says the developer should drive the project management aspect of their build cycle, but it’s not something our team are very comfortable with. They also have very little experience doing this, as larger-scale project management was not something they needed to think about when picking up smaller, already prioritised tickets during our time as Kanbanners!

This leads me to spend more time than I believe is healthy doing project management tasks, as opposed to other things that I should be focusing on in my role (i.e. in-depth shaping, talking to users, determining ROI of things we’ve built etc.). It’s also a bit of a mess if I go on holiday.

Has anyone encountered a similar problem moving from another development style to Shape Up? And if so, does anyone have any recommendations to improving the developer-owner project management aspect of build cycles? Are there any tips out there to make your developers feel more comfortable owning the task prioritisation aspect of the development process once pitches have been bet on?

Perhaps a tool like Monday could be quite useful, though I feel there’s a cultural issue that needs to be addressed first and foremost, before introducing a new tool to help on top of this. Obviously some more resource would be handy, but that option’s not really on the cards right now.

Very keen to hear your thoughts, and thanks for taking the time to read this.

Elliott

#2

It looks like you are trying to use the shape-up process with the old/conventional tasks model.

See https://basecamp.com/shapeup/3.1-chapter-10#assign-projects-not-tasks

Creating a list of “tasks” could be the problem, instead, try to create a list of “features” (without going in too much detail) and le the developers to dictate the tasks. You could bundle 3/4 “features” on a dev-cycle if those are small enough to fit the cycle.

If you have ongoing support (I do), I find it much easier to have just an “inbox” section with those, first-in/first-out, without adding those tasks in the current dev-bundle… We also have a separate support-team, that might help as well.

#3

Hi Jeff, thanks for taking the time to respond. I’ll take the above into consideration and see what can be improved - thank you.

We definitely try and present a list of features instead of tasks, but these often turn into tasks when the cycle starts as that is how they are viewed and processed by the developers. Sometimes the “features” presented may incorporate a few specific tasks (i.e. things that feature just has to do), which I struggle to see a way around…

There is a fine line in shape up between purposeful ambiguity and something just being “unshaped”, which we’ve felt the pain of a few times!

A refresh of that chapter is handy reading.

Elliott

1 Like
#4

My first instinct would be to question how cohesive the pitch is.

If the shaped work in the pitch has clear drawings or breadboards, and it makes sense as a single whole that does X, then it shouldn’t be necessary to spell out small tasks. Versus if for some reason the work has a lot of finicky details, this makes me wonder if the project itself is clearly defined as a unit.

2 Likes
#5

Thanks Ryan. I’d be inclined to agree. Think all our shapers (myself certainly included) could do with revisiting the breadboarding chapter…