5 ms·
I think there may be a chance for success in going FULL scrum, but really there are a couple of caveats. * The appropriate sprint-length must be found, there i
by wirrbel 5y ago
I think there may be a chance for success in going FULL scrum, but really there are a couple of caveats.
* The appropriate sprint-length must be found, there is a lower-bound by how long you need for developing something with user-value (i.e. demoable), and upper bound the tolerance of your customer (or sales organisation) to wait until requested features will be implemented. Most scrum teams seem to use 2 week sprints which is typically too short unless you are developing simple products like CRUD applications potentially.
* If we take 1 sprint-length (1 SL) as a basic time unit, then you need to realise that a new, highest-priority feature will on average take 1.5 SLs to delivery if it really is Priority 1.
* teams must really be 90% self-reliant to do everything needed in the sprint. Once you have need to synchronise development across scrum-teams, you loose. basically now value delivery can easily take 2-3 SL OR needs to be carefully planned / aligned for the same sprint ahead of time so you get at a lower-boundary of 2-2.5 SL (> 1.5 SL) for work involving more than one team, easily exploding to 3-4 SLs.
deve
With these considerations, we quickly get into longer-ranges of planning, especially if you are in a multiple-team kind of situation, that you get easily into when you (a) don't have a dev team deploying to the cloud (b) are developing more-complex software systems with multiple components / services developed by several teams.
The elephant in the room of course is that all of this thais not discussed in your Scrum training, because they mostly outline a happy-path for this 8 person team
disclaimer: I prefer Kanban-style sprint-less work mode overall.
- splittingTimes 5y agoWholeheartedly agree. On our side we are not only multiple dev teams working tightly together on the same product (CAD application in a highly regulated medical field), but we also have a domain experts group, a designer group and the POs that need to prepare the high-level user stories and behavior of the features pre development. Our teams work with 3 week sprints and we found that in order to actually start development of a topic we need ~3SL prep time, meaning POs write high-level user stories, domain experts discuss how the detailed workflow behavior should best be like, then the designers come with mockups. Those are typically not aligned and need several feedback loops until it is settled. Then we devs need to break this down, look into the technical side, groom the tickets, write Dev stories and estimate them. Then the PO prioritizes the tickets and we pick em for the sprint. Then we develop for typically 3 sprints, but sometimes longer. After the pure development come the feedback loops again with the domain experts and the actual stakeholders. This can also take 2-3SL easily. So we have 3SL prep | actual implementation ≥ 3SL | 3SL feedback loops & polish Post development our deliveries also have to synch with the bi-yearly sales windows of our parent company and need coordination for marketing, regulatory affairs / verification & validation, training & education and the sales team. The real challenge is to somehow interface our agile development process within a traditional workflow (marketing, T&E, sales needs to know upfront what features will be delivered at a given release some month in advance so they can plan and prepare their activities and materials for a commercially successful software release.
- theshrike79 5y agoYea, syncing work across multiple teams is a pain in the ass. There really aren't any good solutions for that, only bad and worse ones...