Coaching Agile teams provides one with a few extraordinary moments that make you go wow! I am sharing one such event in this blog when I saw self-organization manifest at a different level.
As part of a coaching assignment at an organization, I was asked to help a team adopt agile scrum, they were totally new to it. The team happened to be a component team, working on the back-end of an investment-related system.
In course of the initial discussions discovered that there were two other component teams. One working on the front-end and they were practising agile scrum for quite some time, doing week long sprints. Another was the middle-ware team that was doing two-week sprints and had adopted agile scrum a few months back.
I connected with the other two Scrum Masters and the Product Owner to bring in some basic alignment like common sprint duration. Though they understood the importance, they were not willing to change their way of working. One team was too set in their ways and the other was wary of introducing a change.
I apprised the manager of the back-end team that the benefits would accrue only if all three teams align. I learned it was difficult to do that due to the way the organization was set-up. The manager understood the situation, his intent was to make the team experience agile scrum and then decide/work on the next steps.
The back-end team was adamant that they needed four weeks to create a potentially shippable increment if one could call it so. Working with them and deep diving onto their backlog, was able to convince them for a three-week sprint.
The team enjoyed the move to Scrum, they loved the daily scrum, the sprint planning and the retrospectives. They loved the story point estimation and how it unravelled the requirements as well as the knowledge of the team. It was a marked difference from the past, where they would formally interact once a week and work mostly by themselves for the rest of time.
Back-end team depended on the other two teams (front-end and middle-ware) to complete the testing and getting their work meets the Definition of done. They incorporated the planning for the dependencies into the sprint planning. But often the other teams would not deliver as expected to make an impact on the team’s deliverable. This resulted in a build-up of incomplete stories, technical debt and resulted in a much longer than planned hardening sprint.
With some coaxing the three teams had started sharing the issues from their retrospectives with each other and started doing a Scrum of Scrum on the weekly basis. We had planned a Release retrospective; luckily other two teams had consented to do and share their findings. I kept checking on the team to help them with the Release retrospective, but the team continued to be doing their hardening sprints.
At this juncture, I started coaching couple other teams and interactions with the team reduced.
After a few weeks I bumped into the Scrum Master for the back-end team, he was looking for some help to get started on the next Release. He mentioned, in a matter of fact way, that all teams are now planning on doing two-week sprints. This was a surprise! – apparently, the long hardening sprints, sharing of Release retrospectives and the resultant push from the Product Owner, had propelled the teams to adopt a common sprint duration.
The teams felt SAFE to align themselves to a common sprint duration.
It was a great learning for me, I started the coaching with toned down expectations, that the team can only go so far due to the lack of alignment and the organization constraints, but lo behold, they started on the alignment by themselves.