Appetite for destruction - risk awareness VS chickening

I had quite an interesting discussion about frequent delivery of value via changes in software. The topics itself is not new and everyone who knows the basics of Agile / Lean...

5 years ago

Latest Post On Meditation. And Mindfulness. by Sebastian Gebski

I had quite an interesting discussion about frequent delivery of value via changes in software. The topics itself is not new and everyone who knows the basics of Agile / Lean approach (or just Theory of Constraints) knows that stashing the inventory should be reduced to minimum - one should deliver as frequently as possible (while making sure that delivered chunks actually bring some value), even if it means smaller portions.

The Context

In this particular scenario I'll write about, team is delivering more than 1 feature in the same time, BUT people work on feature sets in pairs - each pair is working on one, single, particular feature. Here are some other, relevant details:

Consequences

Obviously, this set-up has some consequences you need to realize - here is the short version of team's findings:

  1. As features are still somehow dependent, people have to synchronize their changes constantly (pair to pair).
  2. Due to coupling - features have to be continuously integrated and tested against each other: that also means their deployment IS bound: if feature no.1 is delayed, feature no.2 is delayed as well, because it depends on no. 1.
  3. As the features are in different products (applications), the number of applications deployed will be wider - and that will increase the risk of failure (more changes = bigger risk of failure).

Team's recommendation

That's why team has recommended changing the approach in a following way:

  1. We should introduce 1 feature at time. Other features should wait until:
  1. As the features are introduced gradually, all the interfaces have to be prepared in more than 1 combination of communicating components, for instance:
  1. Such an approach will:

Where's the catch?

Unfortunately this kind of thinking seems a bit flawed (even if the priorities makes sense at the first glance).

  1. Avoiding interdependencies is awesome, but sometimes you just can't - the stuff is related and you can't help it. That means that YES, you need to synchronize work but:
  1. If Team consists of 4 such pairs, but only 1 of them can introduce their changes in the given moment, what happens with the deliverables of other ones? They get into the inventory - the exact place we don't want them to rot in.
  2. Creating more and more variants of interfaces (because of the version combinations) to develop and maintain is not only an additional cost (and waste ...) but also seriously increases the probability of error occurance. Especially in this case - due to scenario specifics, some tests won't be automated.

Conclusion

Here are my thoughts:

Sebastian Gebski

Published 5 years ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.