Next-Gen Kids:
I asked my son to read a chapter for his upcoming unit tests, and he replied I know everything, so it’s not required.
When I insisted, he gave me an analogy: How would you react if someone asked you to read the Scrum guide and then asked about the sprint time box?
You know that, don’t you?
I was stunned, as I had never discussed Scrum with him. Are kids smarter these days, or do they have more exposure to many things?
Misleading Consumer Feedback
One way customer feedback can be misleading. To tell you a story, recently, I got a call from one of the Covid mask provider’s executives.
=====================================================================
Dear Sir
As discussed, please give us a 5-star rating on Amazon.com and share the screenshot.
We will send you an N95 pack of 5 masks as a complementary gift,
Thanks
XYZ
=====================================================================
This can result in the following:
Internally (within the company), the product leadership team won’t be able to make the right decisions as Amazon.com ratings are manipulated/doctored.
Externally (to the firm), Amazon customers observe a high rating and buy that product.
Intra-Sprint production deployments
Scrum teams often develop and deploy functionality into production before Sprint’s time-box ends.
But what about the Sprint review?? Shouldn’t the stakeholders review the Done increment first?
To me, the release of the product increment should not be tied to the sprint review meeting, especially if the marketplace demands it. It’s up to the PO when (s)he decides to release the increment.
However, we should update the DoD and add “Ready to Release” and “Deployed to Production” to it.
One obviously needs an automated CI-CD pipeline to have intra-print production deployments. Within a year of Amazon’s move to AWS, engineers deployed code every 11.7 seconds, on average.
Sprint burn down chart
Does it look familiar?
What can you do to address the underlined issues?
Some tips:
- Get into the habit of updating Jira tickets on time
If you see a similar pattern, use your sprint retrospective to address the inherent issues. - Get better at story sizing; break big user stories into smaller ones.
- Identify external dependencies and try to address them.
Waterfall Scrum?
In Scrum, the team should work on shippable increments every sprint. It should deliver something valuable to the end users. But how about the following scenario where a team is working on a major release (in a two-week sprint cycle)
Goal:
Product upgrade of a third-party enterprise tool used by thousands of users in the organisation.
Assumptions/Constraints:
- The team has to undergo the Dev, UAT, and Governance phases before the actual Go-live. As we can see, there is a dependency, and the team can not move to production without a successful UAT.
- Communication with end users who want to test new features and provide sign-offs.
It’s quite possible that in one of the sprints, the team is just working on the infrastructure setup by refreshing the Dev database or copying application binaries.
In such a scenario, how can they deliver features that users can see/use and provide feedback on?
Is the team using Waterfall cum Scrum? What options do they have?
Leave a Reply