Return to site

SCRUM: Defer Constraining Commitments by Chuck Suscheck

· scrum,video

 

Hi, I want to talk about one of my favorite 💗 principals,

Mary and Tom Poppendieck wrote a book 📕 about lean software development.

One of the things they mentioned there was to defer constraining commitments until the last responsible moment.

Defer ⌚ constraining commitments until the last responsible moment.

That's a strange and unusual way to think of things;

but if you can defer a constraining commitment;

you can learn 👩‍🏫 more and apply it to making that constraining decision.

Don't do it past the last responsible moment ⚠️ ; that's probably the hard part.

So deferring constraining commitments until the last responsible moment means learning more by doing, and making a more perfected constraining commitment.

Airline pilots 👨‍✈️ do this apparently when they have an indicator come on in the cockpit;

they don't immediately think that they're going to land in the next farmer's 👨‍🌾 field;

they think about it for a while and defer making that particular type of decision until later ⌚;

so that they can diagnose 🔍 and diagnose 🔎 and diagnose 🕵️‍ the problem.

Similarly, if you have architecture;

architectures are good 👍;

you should have architecture.

Architecture is also a constraint;

every decision you make in architecture can be a constraint;

so ask yourself 🤔 as you're coming to these types of decisions: do I have to make this decision now or can I postpone it to later

Postpone it without having an ill effect 😵‍💫 on my current trajectory;

if you can postpone that architectural decision;

perhaps mock it 👨‍💻 out or use a simple framework.

As you're making that decision, you can learn more by doing, executing against the product, developing a snippet of the product, and perhaps making a more informed architectural decision.

Similar to your product backlog 📃: have a product backlog.

Here the top ⬆️ has more detail, and the bottom ⬇️ has less detail.

Of course, we're trying to defer the level of detail at the bottom so that we take things off as we add to the product backlog.

With product backlog and learning more, we can perfect these requirements based on what we've learned during that particular sprint.

So it's not laziness 😴 or anything to that effect it's that we're trying to defer some of these details in our requirements so that we can execute and learn more.

And as we perfect these requirements make a more informed ☝️ decision.

The hard part is making sure that you do it but don't pass a last responsible moment.

That's a matter of balancing risk ⚖️ in your particular environment and looking at certain things and asking yourself can I defer this decision?

If you can, maybe you should, then when it comes time to make such a decision; you'll have more information about it 😜.

#scrum #defer #decision #architecture

Video👉https://youtu.be/NxXKN-thOX8