In the last post from the last series, I described how scrum was introduced into the project. I remember this year when I was reading the Scrum Guide and getting the materials I could find.
the build-in quality
It may sound ironic and lofty, but it is a very powerful concept. It can be broken down into two statements:
- if product has a desired level of quality, the effor to keep it there is low but continuouse
- if product’s quality has decreased, geeting it back to previouse level of quality can be very expensive (sometimes impossible)
This concept is all about:
- importence of setting the satandard
- setting this standratd from the beggining
- when you sacriface hiht standards for the temporeary velocity boost the future cost very quickly richt ths sky limit
All kinds of automation, like infrastructure, test, code, etc., living documentation, architecture, and domain model are very easy to introduce in the beginning and very expensive to bring into a mature, complex solution. That’s why it’s too hard and expensive to build in test automation of legacy projects/platforms or even to fix, by automating, their deployment pipelines.
There is always a place to trade-off, choices but reality sometimes can be harsh. Long-term is always a key.
- Automation Journey - episode I
- Automation Journey - episode II
- Automation Journey - episode III
- Automation Journey - episode IV