Challenge your assumptions

Following is a list of stuff I noticed we tend to accept blindly.

1. Why do we work in two-week iterations?

Who decided ten working days was the way to go? When did they decide that? What was the context? Is it still valid?

Could we make them shorter?

What would it take to work in shorter iterations (say, a week, three days, a single day)? How could we find a healthy signal-to-noise ratio? How could we validate ideas and gather feedback?

Are two-week “sprints” the only way?

2. Why do Product Owners attend to the daily stand up meeting?

Is the Product Owner taking the lead role during this meeting? Does it make them be seen like the Bo$$?

Is it the best way to empower the whole team? What would the meeting look like if the customer advocate wasn’t there? Better? Worse?

How would the Product Owner be in sync with all other team members?

Are daily stand up meetings the only way?

3. Why do we use Pull Requests?

Why don’t we commit directly to the main branch? It would be faster, wouldn’t it? A shorter path to production, a shorter feedback loop. A decreased lead time.

What would it take me to be confident enough to work this way? What should a team look like work like that?

How should commits look? Should they be smaller? More frequent? Utterly tested? Where/When would you run your tests?

How would I spread knowledge among peers? How would we ensure a certain degree of quality, safety, control?

Are Pull/Merge Requests the only way?

4. Why do we have backlogs?

What is a backlog? A list of “what needs to be done”, right? But… is it?

Isn’t a backlog where ideas are left to die? Is it worth the effort of keeping it up to date, in sync?

How could we make sure we’re working on the most important thing, over and over?

Are backlogs the only way?

Bottom line

I guess your first reaction will look like mine.

You’ll come up with reasons, justifications. A lot of them! These reasons might be sensible. That’s good! It means you know what you’re doing. Or at least you think so (I did).

I don’t believe assumptions above are 100% wrong (whatever wrong means).

Yet, there’s value in challenging them. Because when you challenge assumptions, you force yourself (and others) to understand “why”. After that, you might find better ways of reaching the same goal.

It fights the “it’s always been done that way” mindset. Has it? So what?

Gather your team and ask these questions. See what happens next.

Assumptions are just that – assumptions.