We are frustrated because we are doing too many things at the same time (mostly felt by devs)
We are frustrated because things get too long to be done (mostly felt by product team)
Solution:
limit work in progress
Details:
I dont think we are limiting work in progress enough in this project and that is slowing us down and creating the frustration mentioned above.
the general rule is that if a team member is available and can help with #1 priority, that’s what she should do if she can help (it doesnt matter how many people are already “allocated” to the #1 priority, it only matters if the free dev can contribute positively to move #1 priority).
Afterwards, we can go to the next priority items #2 and #5. but focusing on #1 is the most important, this way we become a lot more focused as a team, more knowledge is shared, we are less frustrated (see problem statement above), and velocity increases.
(this is not specific to any initiative in the list, this is applicable to any roadmap)
I totally understand but I’d like to add two things. I think the entire team shares these frustrations. Having so many things going on is something will all suffer I believe.
Also, I share your view on the #1 priority but it’s good to also invest some time on #2 while put most of the resources on #1. This way, other things still move on, especially given the long timespan of things like Spree upgrade, but we don’t stray much from our biggest priority.
I completely agree that we should be better at doing this. We have attempted to some degree to do this, however with multiple product managers trying to get things into the pipe and no clear single focus and continuing return to focus on that priority list then things get out of hand super quickly.
I agree with @sauloperez though, that it’s good to have an additional stream happening for other things while the longer game of tech debt pay off is happening. The problem that I think we experienced with this second stream is that we tried to put to much through that stream at once.
I actually don’t believe that your proposal to limit WIP will solve this problem. I think this problem is exacerbated by the current shallow focus on too many things, but I also think that there are 2 other causes:
Not having time at the beginning of the feature inception/discovery to fully lock down the scope, understand technical solution, and gain a shared consensus of these things with a kick off.
Scope creep which isn’t being properly managed once the work kicks off.
Finally, the thing I think will help with all of this is if we had dedicated Product/Train drivers paid similarly to devs/testers and guaranteeing a particular number of hours each week so that we know that there is someone/s taking the lead and prioritising this work. It’s awesome that we’ve got to a point in our evolution as a product development team where just having devs guaranteed and paid each week for hours isn’t enough and we now need to start having the same kind of rigour and dedicated hours for the product and train driving team
awesome @danielle I agree scope creep and having a PM is also very important.
I actually don’t believe that your proposal to limit WIP will solve this problem
Limit work in progress will increase your velocity. If we have more devs in top priority it will be done faster for sure and always… and because there’s less WIP, there’s less context switching and less overload and things become more simple.
So, we dont have v2 or subs done and dusted because we are building features in parallel. All this post is stating is that if you want to stop the slow death march of features (spree upgrade and subscriptions are 2 very specific examples), you need to stop having these parallel tracks/features in the roadmap and focus.
I didn’t put any references here but this is the fundamental concept in Lean from where Kanban comes from.
Yes…on 1 particular thing. But if you decide to have a couple of streams running you extend out the length of time each will be delivered but you also can get small things delivered quicker, e.g. bulk invoice printing.
So to me it’s not about all focus on one thing, it’s about ensuring the priority gets the bulk of the attention but don’t let that be the only thing coming through. When it comes to tech debt though of course we’re achieving something it’s really hard not to also have small functional improvements being added alongside of this behind the scenes work.
That is the magic of limit work in progress. it’s about 1. increasing the velocity on the #1 thing (that is called reducing cycle time) but it’s also about 2. increasing overall velocity, increasing the total amount of things you can do in one particular time frame, it’s about increasing efficiency (because you reduce cycle time and reduce waste like context switching you are reducing lead time and thus improving process cycle efficiency).
I hear you @luisramos0…but I don’t agree that we should only focus on 1 thing at a time. I think getting small things like bulk invoice printing out whilst this is going on has had benefits for OFN without taking too much away from the main spree upgrade push. It’s about the trade off between efficiencies of what you describe and the end user benefit of having these small things done.
If anything, given the work on the subscription v1 began prior to the spree upgrade we should actually have had that, and product import which also started beforehand, done before spree started. This is why I’m loathe to drop the things that have been in the pipe for so long, because there is waste and inefficiency in having them stick around for so long that I believe trumps the single item right now.
I definitely hear and overall agree with what you say @luisramos0 but I also agree that:
we are still cleaning up things from the old non-unified-product-team organization, so as @danielle said Sub and PI were started with not a clear scope, and pushed and start by one instance before we had a single team. We took them back on hand, scoped them, and the remaining things in the epics are the few things to finish so that we can release them. Feature are basically built, so as Danni said it would be a pity to just wait some months before touching them again, and I thin in our case it is better to parallelize the work, and keep delivering slower but still, delivering, in parallel, while 80% of dev time is on Spree.
But I think putting in new features is more debatable. Given where OFN is at, and there are still very annoying things that really prevent the local community builder to increase the mass of users, I think we need to keep on moving forward and parallelize, like still put when other priorities are done mobile ready in the pipe.
That being said, I agree that still we should limit the number of epics in dev ready to maybe 3 or 4. For instance today we would have Spree, PI, Subs and Bulk printing. Kristina would have had to help on those before starting Enterprise fee. Then only we would have pushed mobile ready. I wouldn’t include the bugs and tech debt issues we put in as long as we also limit their number, like 5 of each for instance (they can be ordered in between features depending on priority / emergency). So WIP in dev ready would be 3 epics, 3 bugs and 3 tech debt for instance (we can add straight away another bug and prioritize on top if we believe there are more than 3 bugs that needs to be done before the next feature, etc.)
awesome, I understand your point but I have created this thread because it’s not just the spree upgrade or subs, it’s a tendency in this community (and in many other teams).
Let’s ignore spree upgrade and look at the current roadmap, it’s the same parallel problem again
We have less than 3 FTEs in terms of dev power right now and, on top of the big big spree upgrade, you have 5 feature epics in progress (prod import, bulk invoice, subs, enterprise fee, mobile ready) plus s3 bugs, tech debt and sysadmin. Even without the huge spree upgrade, it’s too much. That’s the point of this thread.
So shall we consider a proposition to limit feature epic in progress to 3 ? And shall we limit bug and tech debt in dev ready as well ? I would vote for. Coudl be 3, or 5 maybe especially for bugs, a simple translation is very quick. But if we say 3 it means we just need to fuel bugs in more quickly, it’s possible to… what would you propose @luisramos0 then ? 3 of each backlog, taking into account that 3 of features mean big epic, but it can happen as well for tech debt (like Spree!) or sometimes bug.
Yes @MyriamBoure, great, thanks for putting those limits forward because that’s exactly what’s the suggestion would be. As a group, we agree on WIP limits.
I agree 3 big epics is a good number.
It looks like these 3 epics would be compared to smaller s3 bugs and tech debt issues. We could have different limits for these because they are smaller.
What if we do 3 for sysadmin and tech debt and 5 for bugs?
WIP Limits:
3 epics (including tech epics like spree upgrade or api work)
I like that ! And it doesn’t prevent to parallelize somehow the work, but within those limits What do you think @danielle@sauloperez@Rachel ?
Of course that doesn’t prevent to work better on inception, scope properly, do proper kickoff, etc. It’s complementary.
Anyway I really like this solution and will be looking forward to test it. I would even go down on 2 major epics. Indeed, if we have only 3 FTE, it would be safer to only have 2 epics. Plus it would force us to do more pairing, which would avoid situations like subs or PI where one dev only knows really well the feature. And I guess it would be the same for tech issues as well, wouldn’t it?
That being said, if I understood correctly, mobile work was introduce because a front dev was available. So maybe this is something to take into account as well : if the 3 FTE available have some special skills maybe the type of epics should be re-prioritised?
Completely agree, too much. I also agree with @Rachel that the epic limit should be 2, and we should start the process of getting down to this number.
What that means I believe is that of those listed above:
Subscriptions - was the first thing to be picked up, to me should be the highest priority to be finished if we consider things like cycle time (sometime around the middle of 2016 was when it kicked off)
Product import - similar to Subs but started later on.
Spree upgrade - the bulk of the dev capacity is focused here, as was agreed at the beginning of 2018.
Fee report - this should be almost done, it’s potentially suffering from scope creep but @Kirsten is sorting this out and it will be done soon (leaving 3 things in the pipe)
As far as I’m aware bulk invoice printing is done so is no longer in the pipe. And mobile ready, though briefly started by Maxim has been stagnating in the pipe with no one to work on it so to me is the first candidate to be pulled out of dev ready for now.
Ideally, we get subs and product import done, fee report before that, and then the only 2 things we have in the WIP are spree upgrade and mobile ready.
yes, sounds good @danielle
I think limiting epics to 2 may be too little, we are 3 FTEs but actually 6 devs plus Maxim.
A good side effect of having a small buffer for the epics is that devs will naturally realize the top priority apart from the 2 epics are the s3 bugs. so maybe limit to 2 could be a good temporary measure until we get to a better state in terms of s3 bugs. we could then move to 3 epics limit.
2 epics (including tech epics like spree upgrade or api work) and then up to 3 max (when less s3 bugs)
5 bugs
5 tech issues (tech debt and sys admin)
Let’s try to implement it ! Shall we put pack mobile ready in feature backlog ? Shall we finish the things started and implement afterward ? Else given Danni comment Spree should get out until Subs and PI are done, which is a bit inconsistent, so I would say for now let’s keep with the 4 epics, but don’t put any other epic in for now until we reach 2.
