Bridging the Gap, etc.

Greetings all –


My apologies for being behind on posting.  Things have been really crazy around here with VS2005 shutting down and work on the next major release ramping up.  I’ve been tasked to help out with some engineering improvement initiatives going on in the division and this has soaked up much of my available time.


During the last sprint (sprint 8), we put all the efforts of the MSBuild team on a Scrum team.  This had one downside, which was that the team got too large (10+ people).  I knew this would be an issue, but it turned out to be really big.  The meetings got too big and the goal was too unfocused, and people definitely didn’t like it (the sprint retrospective had a very negative cast to it).


During the current sprint (sprint 9), we finally split into two separate teams, one doing more internal-focused work and the other doing more forward-looking work (although the entire team still comes together for design decisions, etc.).  This has so far worked quite well (or so it seems).  It will be interesting to see what the team thinks at the sprint retrospective.


One of the more interesting phenomena is that during the last sprint a few team members were complaining about how they thought Scrum had too much overhead and they wanted to try something different.  One of the really ironic things about this is that they were using Scrum data to argue this, and they were using the Scrum retrospective as the window into their issues!  Whenever I start to drill into why people think we should use another process, they usually come back with an answer like “we have too many other distractions”, “so-and-so is too hard to work with”, etc. – generally things that have nothing to do with Scrum, but that Scrum has showed them.  Very bizarre.  Usually I’m pretty patient with this, but sometimes I want to pull my hair out and point out that if we weren’t using Scrum, the same issues would exist but there would simply be less visibility into them and less opportunity to fix them.


Another good one is that one or two of the people on the team will occasionally complain that they don’t like having a meeting every day, but these are often the same people who would otherwise complain that they didn’t have enough insight into what the rest of the team is doing.


Anyways, I’ve found that Scrum has been useful for us in “bridging the gap” between the end of one product cycle and the beginning of another.  When other teams were trying to figure out their plans, we simply continued to execute against our product backlog and kept doing sprints, and the team stayed engaged, we have avoided analysis paralysis, and things are rolling pretty well.  Right now I really feel like the avoidance of analysis paralysis is an enormous benefit, but a hidden one – you don’t notice the benefit unless you’ve lived through the problematic situation from past experience and realize the joy in not going through it.


That’s all for now!



Skip to main content