Local Peaks: thoughts, ideas and lessons learned from a web-native CEO/CTO

Iteration 1, Day 1 of multiple scrum teams....

December 17, 2008 | By Jeff Freund
Comments (0)

Today was a milestone for our development team at Clickability.  We have made the quantum leap from one scrum team to two scrum teams and today was the first day of the first sprint as such. 

Please consider this post as an initial report of what we are doing, to be followed up with future posts as to what has worked, what we have changed, and what has been challenging.

As of today, each scrum team consists of:

  • 3-4 java engineers
  • 1-2 QA engineers
  • 1 Product Manager
  • A tech writer (too frequently over looked!) that serves both teams

Members from these groups serve in the roles of:

  • Product Owner (the PMs)
  • Scrum master (one of the Engineers)
  • Tech Lead (another one of the Engineers)

[Note: We have found the role of Tech Lead to be particularly important right now as we have a lot of team members who have only recently joined the company.  If everyone on the team had been here for a long time, probably not as important to distinguish]

There are definitely things that we are concerned about in doubling our number of scrum teams.  The top ones and how we plan on addressing them are as follows:

  • Knowledge sharing – all code reviews will be performed across scrum teams to prevent the silo’ing of information
  • Parallel teams / single code branch – this is both a challenge and an asset.  Conflicts will occur, but we have a build engineer to keep things running smoothly and by maintaining a single branch, our continuous integration environment can uniformly deliver on a, well, continuous basis
  • Coherent design and architecture - we are forming an architecture committee that will consist of members of each scrum team that will ensure that architecture and design decisions are made consistently and in the context of "the bigger picture"
  • Consistent practices - over the past year, the team has collaborated to produce a well documented set of best practices around code style, refactoring practices, etc. that will serve to maintain consistency in the code base regardless of how the team operates as a whole
  • Stand up meetings – who goes first at the daily standup meeting has already been decided by a coin toss…

Below is a picture of our expanded scrum board, or as I have taken to calling it, the “double barrel scrum board”.  If it looks like it takes up an entire wall, that is because it does!  If you are ever in the neighborhood, feel free to stop by and look at all the PostIt’s.



PS - Those who have read my bio will realize that the last time I was dealing with 2 scrum teams was in a very different context....



Post Comment

© 2019 All Rights Reserved by Jeff Freund | Technorati Profile