I’m currently helping a small software shop within a government organization where multiple Scrum Teams are serving the same cause. They are building one product that has several sub-systems, which sometimes need to be integrated. Mostly, they have a low amount of dependencies between teams and systems. Today, the wind is slowly changing and the trend is “unity,” so the sub-systems need to be closely integrated. I suggested they use the Nexus Framework to help them manage their development. They decided to integrate the systems gradually, starting with two Scrum Teams and adding more teams as it goes. They have implemented the Nexus Daily Scrum.
A few weeks prior to beginning development, the Dev Teams refined their dependent items. I knew there was some anxiety. At that point, they were conducting Nexus Daily Scrums but felt that these daily meetings in addition to the Daily Scrums were overkill because there were no dependencies between the sub-systems. So, they decided to stop. They managed instead with offline ad-hoc conversations about upcoming “dependent” work. However, after a few Sprints, they selected the dependent items that needed to be developed and decided to reinstate the Nexus Daily Scrum and synchronize daily.
The teams organized an ad-hoc pre-planning meeting that included a few members from each team. They wrote down the list of dependent items and had a high-level conversation about how they would integrate their work. After this discussion, they decided to postpone the release off by one week in order to allow for “recovery” and “stabilization.” Those two words made me twitch instantly. The habit of “stabilization period” is so frustrating! These are old habits left over from using waterfall and poor technical practices. What does it mean to be “done” at the end of a Sprint? Why do you need a stabilization period if you were “done”? What can you do to mitigate risks earlier, now? I went on for a little rant with the teams. I saw heads nodding, reasons were disclosed and it occurs to me that they were using a risk assessment practice that they used in the past. Anyhow, a potential topic for the next retrospective.
The Sprint continued. Every day, at the Nexus Daily Scrum, most of the developers would start their turn by saying “there are no dependencies, can we go now?” and then, at last, someone would say “I will be doing this highly technical thing, how will I integrate with this other thing?” and the conversation would trigger everyone’s interest. The equivalent of the Nexus Sprint Backlog would be updated with new information and they would carry on.
Even if the teams were not ready to plug and play their parts fully implemented, the Nexus Daily Scrum continues to be held every day. It enables the team members to discover small experiments they can do before going too far into the development.
Furthermore, although they haven’t been using the Nexus Framework fully as described in the Nexus Guide, they created the equivalent of the Nexus Sprint Planning and created a Nexus Sprint Backlog for tracking their dependencies. I cannot wait to see what they will come up with for the Nexus Sprint Review and for the Nexus Sprint Retrospective!