4 ms·

Let see if I understood correctly. 10) Now teams are releasing in production every other week and with single branching and the continuous delivery teams are g

Let see if I understood correctly. 10) Now teams are releasing in production every other week and with single branching and the continuous delivery teams are going in the direction of daily releases (as soon as a single feature is ready is released). Do I understood correctly ? 11) Your domain and requirements are pretty stable so are technology and teams and people involved (i.e. few unexpected/unpredictable events and changes, few unknowns and uncertainties) and teams are able to deal with the challenges well with anticipation and reflections and with less/minor needs for reaction/adaptation/explorations. Do I understood correctly ? 3 additional questions 12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers? 13) A dev can look in isolation at 1 or few classes and understand their behavior and can safely make changes and test them, without the need to follow a dependency chain of more classes and check internal implementation details (that cannot be understood by looking at public members, interfaces, types, parameters and their naming) ? Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ? 14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ?

tablet 14y ago
> 10-11) Yes. However, daily releases are possible for SaaS solution only. > 12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers? Yes, deployment is automatic. Roll-back is semi-automatic so far, but we are working on fully automatic roll-back and it will be ready soon (for SaaS). However, customers can install TargetProcess on their own servers, and in this case there is no automatic roll-back. > 13) Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ? UI layer - yes. Caches and persistence layer, not so easily. Codebase is 8 years old in some places and definitely there are parts that are hard to modify. Several years ago speed was more important than code quality, so we have dome debts to pay. New code is very clean and cool, old parts of the system refactored gradually. > 14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ? The main reason to try Kanban was an ability to release each feature or bug fix separately, so we did not considered cadence of any kind. I don't think cadence is required in Kanban. But definitely team can keep it and see how it goes. Changes were not easy initially, but in 2-3 months situation improved and it was clear that Kanban works better for us.
- lucaminudel 14y ago
  Nice to hear of teams that found sustainable approaches to sw development and still pushing to improve. Thank you very much! A really interesting report.

tablet 14y ago

> 10-11) Yes. However, daily releases are possible for SaaS solution only. > 12) Are release and eventually rollback operations automated just like a one-click operations and so are the deploy to the automatic test servers? Yes, deployment is automatic. Roll-back is semi-automatic so far, but we are working on fully automatic roll-back and it will be ready soon (for SaaS). However, customers can install TargetProcess on their own servers, and in this case there is no automatic roll-back. > 13) Can teams make architectural changes (i.e. change the persistence technology, change the presentation technology, change the authentication method/technology, change the caching or session state implementation) comfortably and gradually and without pain or huge risks ? UI layer - yes. Caches and persistence layer, not so easily. Codebase is 8 years old in some places and definitely there are parts that are hard to modify. Several years ago speed was more important than code quality, so we have dome debts to pay. New code is very clean and cool, old parts of the system refactored gradually. > 14) When you removed the time-boxing and at the same time adopted some kanban practices (from the report I understood WIP, leading time, just-in-time meetings as retrospective and planning) have you considered the possibility to keep both (as I understood time-box and kanban practices are compatible and so kanban and meeting with a fixed cadence are compatible, so as I understand all are valid options that team can adopt) ? What teams sensed in order to make the decisions and what consequences have observed ? The main reason to try Kanban was an ability to release each feature or bug fix separately, so we did not considered cadence of any kind. I don't think cadence is required in Kanban. But definitely team can keep it and see how it goes. Changes were not easy initially, but in 2-3 months situation improved and it was clear that Kanban works better for us.

lucaminudel 14y ago
Nice to hear of teams that found sustainable approaches to sw development and still pushing to improve. Thank you very much! A really interesting report.