Next-Gen Kids

I asked my son to read a chapter for his upcoming unit tests, he replied I know everything so it’s not required.

When I insisted, he gave me an analogy that How would you react if someone asks you to read the Scrum guide and then ask about the sprint time-box, you know that, isn’t it?

I was stunned as I never discussed Scrum with him. Are kids smarter these days or do they have more exposure to many things?

Misleading Consumer Feedback

One way how a customer feedback can be misleading…I just got a call and a message from one of the service provider.

……………………………
Dear Sir

As discussed please give us 5star rating on Amazon.in and share the screenshot with us
We will send you N95 pack of 5 mask as a complementary gift,

Thanks
XYZ
……………………………..

This can result into:

1. Externally, customer observes a high rating and buys that product.

2. Internally, product leadership team won’t be able to make right decisions as Amazon ratings were manipulated.

Intra-Sprint production deployments

Scrum teams often develop and deploy a functionality into production before Sprint 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.

We should however update DoD and add “Ready to Release” and “Deployed to Production” to it.

Needless to say that one needs to have an automated CI-CD pipeline in order to have intra Sprint production deployments. Within a year of Amazon’s move to AWS, engineers were deploying 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:

1. Get better at story sizing, break big user stories into smaller ones.
2. Identify external dependencies and try to address them.
3. Get into the habit of updating Jira tickets on time

If you see a similar pattern then use your sprint retrospective to address the inherent issues.

Validation

Validation is a very important step in Agile Software development. It helps us in course correction. Scrum framework gives us an opportunity in the form of Sprint reviews where we can validate our hypothesis via stakeholder feedback.

That’s why it is important to have the right set of stakeholders invited to the sprint review meeting. If relevant stakeholders are not attending the review meeting then its one of the Scrum anti-patterns and we should immediately address the same. If we don’t then we may stumble hard in the future.

Don McGreal and Ralph Jocham gave an example of real-time Stakeholder engagement & validation when they mentioned the sandwich creation process at the Subway shops. it’s an excellent example of how to get a product created in close collaboration (leaving no room for a blame game later).

Waterfall Scrum?

In Scrum, team should work on potentially shippable increment 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:-

• Team has to undergo Dev, UAT, Governance phases before the actual Go-live. As we can see there is a dependency and 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 team is just working on the infrastructure setup by refreshing the Dev database or by copying application binaries.

In such a scenario, how they can deliver features that users can see/use and provide a feedback?
Is the team using Waterfall cum Scrum? What options do they have?

And Finally

Had a wonderful time listening to Ralph Jocham at TryScrum event.

Thanks Venkatesh Rajamani 🇮🇳 for having him and giving us an opportunity to learn on the nuances of product ownership.