Need your views
All,
What's your take on following topics?
If delivering 'value' at the end of the sprint is primary measure of success, what's wrong, if the team is running mini waterfall within the sprint, to meet that objective? Should they be bother that they are misusing scrum framework or they feel more motivated that they are delivering success to end users sprint on sprint without paying due attention to process?
If the team is newly formed (developing 'T' shape skill set is long term goal), mixed with services dev, front end dev, UI/UX, automation engineer (I know there is only one role 'Developers') etc. how to manage the predecessor/successor dependencies for tasks within 2 weeks sprint? Like, unless services are ready UI can't consume the services etc. Even we are following 'swarming' approach, it's not removing the dependencies at all. Considering that two challenges are arising, first- utilization of all members at optimal level not possible (that's secondary concern) and second - it's very challenging to complete/deliver 'vertical' user stories at end of the sprint (it's primary concern). Any thought?
Thanks for your time in advance.
If delivering 'value' at the end of the sprint is primary measure of success, what's wrong, if the team is running mini waterfall within the sprint, to meet that objective?
How important is it that value is not just delivered, but maximized?
If delivering 'value' at the end of the sprint is primary measure of success, what's wrong, if the team is running mini waterfall within the sprint, to meet that objective? Should they be bother that they are misusing scrum framework or they feel more motivated that they are delivering success to end users sprint on sprint without paying due attention to process?
I will echo @Ian's point here. Also why even use scrum ? Do you think you need to do Scrum to deliver the increments iteratively and incremently ?
utilization of all members at optimal level not possible (that's secondary concern)
That should not even be a secondary concern. That should be of no concern at all.
I love analogies and quotes, so I'll give you one of each.
If you've ever bought a piece of software, how often have you considered the optimal utilization of those who helped build the product? My guess would be never. What is important is the quality of the product, the features (value) it provides, and the timeliness of its availability. Focus on the work, and not the workers.
And a quote from Ken Rubin on this very subject:
“Working on all of the items (in a sprint) at the same time might be a great way of keeping people busy, but it is a poor way of getting things done.”
Should they be bother that they are misusing scrum framework or they feel more motivated that they are delivering success to end users sprint on sprint without paying due attention to process?
Why do they have to misuse the framework in order to be successful? It's not a process. Scrum is designed to allow you to identify the most important bits of work to do first by understanding the customer/stakeholder needs, and getting feedback after a fixed amount of time.
- Let's plan to do these bits of work first cause we believe customers want this before that.
- Let's work on this stuff until It's done.
- Enough time passed since we started the work, let's get some feedback on what was built/delivered to help us determine if more work is needed before we shift focus onto the next thing.
Success isn't about delivery frequency, you can deliver multiple times a day if the PO wanted to. Scrum doesn't dictate the release frequency. Instead, Scrum provides you the opportunity to determine if you've delivered the right thing in the right way for the right people, and then be successful by helping you identify improvements to your processes, product, team, and working environment to make.