But the wholesale adoption of agile techniques and vocabulary has been a cargo-culting disaster, imho.
1) Everyone. I mean _everyone_ in the organisation needs to commit to the Scrum model. Sales guys aren't excepted from the scrum cycle. If they need a "quick little thing" they put it in the backlog and wait. 2) The Scrum model needs to be adapted to the organisation, it's not a one size fits all model. Most maintenance-style operations don't fit the standard scrum model (ongoing CS issues etc), and testing is kinda iffy (do we test the sprint result during the sprint or during the next sprint?).
* 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.
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.
There really aren't any good solutions for that, only bad and worse ones...