So in the upcoming changes we're making, we want the team to be part of it. Thursday, we did a partial retrospection, to test the water. Why partial? Well, it's full when you take at what's good and what can be improved, and decide on ways to take the next time. We just did the first part, get people's reaction and readiness for changes.
This team suffered from turnover this year, and it showed, as new people talked about having no on-boarding plan. This is in part, because we are doing real-time hiring, with no ongoing recruitment plan. Has been like that since I got here 10 years ago. New people come in when needed, or in a worse case, later after their needed, and there's no succession planning. Related to that, people talked about having no back up, in terms of team members having the same knowledge. This stems from the team structure (and yes I claim responsibility here).
The other major thing that came up is the one we're going to attack first. This is the parallel development inn teams, for a while, without integration and making this work, before moving forward. This has implication in so many levels:
- Requirements close late, so developers and testers work partially on their related tasks, lengthening the tasks and splitting them
- developers and testers do not work on features at the same time, making long cycles of find-fix-verify.
- because the releases are big, and mostly late, there's a big pressure period toward the end, which is followed by big relaxation period after release, and so on. There is no sense of sustainability.
People seem ready for changes. I'm not sure what measure of commitment they will show, based on past experience. We'll see.