The Best is the Enemy of the Good

Can you think about half of dozen schemes and processes of your project that are not going very well, but "well, we all adapted", "don't touch it - it works like this" and "it is actually not used very often"? Surely you can.
And of course these things are not going very bad, they are just bad, but nobody cares. They are similar to a creaking door or leaking kitchen tap - it will work fine for years.

I can think about 2 types of situations with those just bad processes. Think about analogies above: they are describing two different situations.
Creaking door can be easily fixed: just drip some lubricant into the door's hinge. Well, in the worst case you will have to buy that lubricant first.
Situation with leaking tap differs significantly: to change the spacer you will have to unmount the tap. And at that moment it won't be possible to use it. Even more, after you mount it back the spacer will need some time to grind in and the water will be still leaking for a while. In the worst case you put the spacer askew and you will have to repeat from the very beginning.


Let's use this analogy for the software development. If you are going to improve something your may meet the following situations:

The first one is pretty clear: your improvement makes the situation better. It is usually something as simple as providing someone with a second monitor.


But in most cases situation will follow the second picture and the change will first make everything worth: new work schemes will appear, malfunctions will occur in new communication chains, re-formed teams will go through forming-storming-norming-performing cycle and so on. And only later planned improvement will give a profit - maybe.


There are several conclusions from such point of view.
First, you always need to evaluate what can go bad. E.g. you may not need an improvement if it won't be able to affect things in short-term period: it's not a good idea to change repository in 3 days before project end. But I would like to warn here that it's a pernicious idea to excuse someone from improvements because they think it will be to expensive. Everyone needs to be aware of possible issues, but those who do not try to move up will fall down. 

Next, there should be enough time for each change to 'grind'. I think this may be one of the reasons why retrospective meetings are held just once per iteration in Scrum. But again everything is good in moderation: if it is clear that a certain change makes the situation worth then it's better to get rid of it at once.


And the last one, the most interesting to my mind. Do you know the radiophysics' wording "never twist two adjustments at once"? The conclusion from above is that in some cases you must do it. Because it's easier to re-form the team once because of two different changes in process that do it twice one after another. That's the case when total negative impact is less than two parts. 
At the same time for other cases there is a risk that negative impacts will resonate and the situation on the pictures above will go deep down: changing the source control and bug-tracking systems simultaneously with making done criterion more hard does not sound like a good idea.

It seems that each situation will need to be evaluated separately - I can't think about any common laws at this moment.

------------------------------------------

Можете ли вы для своего проекта назвать полдюжины схем и процессов с которыми не всё хорошо, но "как-то все привыкли", "оно и так работает" и "не так уж часто с этим приходится иметь дело"? Наверняка, да.
И, конечно, с этим не совсем плохо, но просто плохо, а никто ничего не делает по этому поводу. Это как скрипящая дверь или протекающий на кухне кран - можно пользоваться долгие годы.

Ситуации с просто плохими процессами можно разделить на два типа. Задумайтесь над аналогией выше - она ведь описывает две разных ситуации. Скрипящую дверь исправить легко: просто капните смазку в петли. В крайнем случае вам прийдётся сначала эту смазку купить.
С капающим краном ситуация отличается принципиально: чтобы заменить прокладку, кран сначала нужно разобрать. И в это время он перестанет работать. Более того, после сборки новой прокладке нужно будет притереться и какое-то время вода всё еще будет капать. А в самом плохом случае прокладка вообще встала криво и всё прийдётся переделывать.

Перенесём аналогию на software development. Пусть вы хотите что-то улучшить, тогда вас может ожидать одна из двух ситуаций:

С первой всё ясно: напряглись и сделали лучше. Это, обычно, простое изменение а-ля "поставили человеку второй монитор - стало удобнее".

Но чаще ситуация будет развиваться по второй картинке и изменение сначала всё усложнит: появятся новые схемы работы, новые коммуникационные цепочки будут барахлить, переформированные команды заново проходить цикл forming-storming-norming-performing и т.д. И только потом запланированное улучшение даст профит - может быть.



Выводов из такого взгляда на проблему несколько.
Для начала, всегда нужно оценивать, что может стать хуже. Например, улучшение может оказаться не нужно, если оно не успеет "выстрелить" в краткосрочной перспективе: менять репозиторий за 3 дня до завершения проекта вряд ли будет классно. Но здесь же стоит предостеречь, что оправдывать нежелание меняться тем, что это будет слишком дорого - пагубная затея. О возможных проблемах нужно знать и подготовиться, но те, кто не пытаются двигаться вверх - покатятся вниз.

Далее, любому изменению нужно время "притереться". Я думаю, это одна из причин, по которой в Scrum'е retrospective meeting'и проводятся только раз в итерацию. Но, снова-таки, всё хорошо вмеру: если однозначно понятно, что какое-то изменение делает ситуацию только хуже, лучше отказаться от него сразу.

И последнее, самое, на мой взгляд, интересное. Знаете поговорку радиофизиков "никогда не крути две ручки сразу?"  Из написанного следует, что в определённых случаях это надо делать. Потому что, к примеру, проще переформировать команду один раз из-за двух изменений процесса сразу, чем сделать это дважды подряд. Это случай, когда сумма отрицательных воздействий меньше слагаемых.
Одновременно для других изменений негативные последствия рискуют войти в резонанс и сорвать ситуацию на картинках выше в штопор: замена source control'а и баг-трекинг системы с одновременным ужесточением критерия done вряд ли будет хорошей идеей.

Видимо, для каждой ситуации прийдётся находить грань индивидуально - я пока не вижу общих принципов оценки.