How many scrums should a ScrumMaster manage?

Capturing a snippet of conversation I had with one of the managers…
Manager:  What does a ScrumMaster really do and what is his role? 
I:  A ScrumMaster helps with planning meetings at the beginning of the iteration, conducts daily scrums, conducts retrospectives, organizes demo/reviews, and helps the team eliminate any impediments. 
Manager:  As far as I understand planning meetings take 2 days, retrospective and review might take additional 2 days – correct?
I:  Yes
Manager: I heard the daily scrums are for 15 minutes. Correct?
I: Yes
Manager: If the daily scrums are for 15 minutes, then what does the ScrumMaster do for other 7 hours?
I: [huh?] ScrumMaster works with the Product Owner to groom the product backlog, he ensures teams follow Agile and Scrum best practices [Unit test cases, Integration tests, Code Coverage, TDD], he also helps remove any obstacles the team has, ensures that team is self-organized and gels together, etc…
Manager: This shouldn’t keep the ScrumMaster 100% busy – do you think one ScrumMaster can manage more than one Scrum?
….
Honestly, I don’t think there’s a simple answer to this question. As a ScrumMaster, I have managed multiple scrums and I have noticed that it’s difficult to provide enough justice to all Scrums due to various reasons like conflicting priorities between teams, schedule conflicts, divided attention, etc.
I also did some research on what the experts have to say about the dedicated ScrumMaster Vs shared ScrumMaster responsibilities. I was equally amazed to see that even they have a dilemma in creating a convincing case for dedicated ScrumMaster. This thread at Scrumdevelopment forum captures different perspectives on this topic.
However, here’s my take on this question – For a new Scrum team, have a dedicated Scrum Master for the first 8 to 10 iterations. This is to ensure that this Scrum team gets full attention of the ScrumMaster while they are going through “Forming – Storming – Norming” stages and until they reach the “Performing” stage. The performing stage is when the team achieves consistent Velocity, becomes intensely collaborative, is Self-organizing and empowered to make decisions. Once the team is in “Performing” stage, the ScrumMaster can then assume additional responsibilities.
Thoughts?

Scrum team organization – Feature teams or Component teams – Part 2

Component Teams (CT) are specialized teams organized around the architecture of the product under development. Examples of such teams are UI / User experience teams, Database design and modeling teams, team of Architects, Security team, etc.

A typical component based scrum team is more or less similar to a feature team i.e. each CT will have 3 to 4 developers, 2 to 3 testers, a Product Owner & Scrum Master with Documentation and Architect representation as needed.

The top node of the diagram “Theme/Epic”depicts customers value add features (Features that customer value). Think of this as some high level requirement that marketing will use in their presentation to advertise a product. This value add feature might not be small enough to finish in one sprint and gets decomposed in to multiple smaller features i.e. Feature 1, Feature 2, Feature 3, and Feature 4. What this essentially means is, once Feature 1 through 4 are done in its entierty, the top level Theme/Epic is “Done”.

The stories for component based teams are fed by these decomposed features Feature 1, Feature 2, Feature 3, and Feature 4. As the diagram shows, Feature 1 is dependent on Component Teams C1, C2 and C3. Similarly, Feature 2 is dependent on component team C1 and C2, Feature 2 is dependendent on CT C1 and C3 and so on. Component teams in general provide functionality and serve multiple Features. Component teams generally don’t generate products that get shipped to the customer. But they develop functionality that is consumed by feature teams and indirectly helps add value to the features being delivered to customers.

If organizations are structured in a way that specialized teams are spread globally then forming component based teams might make sense. Component based teams are great to keep site affinity, work across different timezones and also to keeping team culture intact. But it also comes at an expense of management overhead.

Few challenges with component teams based on my experience

  1. There is overhead of integrating component team’s delivery with the top level features. In the example above, when C1, C2 and C3 finishes the deliveries for Feature 1 they have to be integrated together in Feature 1.
  2. To ensure all scrums are aligned well to deliver end-to-end customer functionality, it will take lot of upfront planning as well as tracking during the entire sprint.
  3. In my experience, with component based teams it’s very difficult to deliver thin slice of end-to-end functionality at end of each iteration because feature team needs time to harden (stabilize code base + write integration tests) their code with component team code delivery.
  4. Since component team serves multiple features teams, negotiation needs to happen between Feature Team and Component teams to avoid starvation. For Ex. In the diagram above Component Team C1 gets requirements from Feature 1, Feature 2, and Feature 3. In the upcoming iteration let’s say C1 can only serve Feature 1. In this case Feature 2 and Feature 3 teams will have to wait until next iteration before their needed functionality is delivered and will be starved.

Thus, for component teams to succeed open communication channel should be established throughout the organization.

Please share your experiences.

Scrum team organization – Feature teams or Component teams – Part 1

There is a big ongoing debate within Agile/Scrum community on whether Scrum teams should be Feature based or Component based. I am currently experiencing this dilemma in my organization and would like to share my thoughts on this.

Feature teams are long lived, cross-functional, co-located teams with 7 to 8 members in a scrum team that completes many end-to-end customer features, one by one. These comprise of subject matter experts from various component areas e.g. UI, Middleware, Database designer, Architects, Business Analyst, Testers, Documentation etc. In short, a self sufficient team with no dependencies. By organizing teams in this fashion, feature teams can develop a thin slice (enough for one iteration) of customer valuable, end-to-end features at the end of each iteration.

The pitcure on the left is a over-simplified diagram of how a scrum based feature team will start executing priortized stories from overall product backlog. Each story, i.e. User Story f1.1, f1,2, … represents a thin vertical slice i.e. end-to-end incremental functionality delivered at end of each iteration. The picture shows that at end of iteration 2 feature f1 and f2 are complete.At end of iteration 3 feature f3 is complete and most likely this product can be shipped to customer. In most cases, your organization will have multiple feature teams and in that case, work allocation can be handled in many different ways. Ex. FT A can work on developing feature 1, FT B can work on developing feature 2 and so on. Other way would be in iteration 1, FT A works on story f1.1 and f1.2 as that’s their capacity and FT B can work on User Story F1.3 and other stories from feature 2. With this approach you can have customer shippable feature f1 at end of iteration 1.

Feature based teams can deliver thin slice of customer visible functionality one after the other at end of each iteration. This is possible because there is no dependency, delay or hand-off issues between teams.

Forming feature teams for an organization where everyone is co-located or at least in the same timezone seems practical. However for global teams, where expertise is spread throughout the globe, forming feature teams that develop thin slice of end to end functionality is a challenge. Forming a FT which spans multiple timezones violates most of scrum principles – as this team will have a difficult time self organizing for various reasons like culture, timezone differences, etc. This will have a negative impact on team’s velocity and their performance will suffer. In short, FT can’t scale in geographically dispersed large teams which is more or less a reality for all organizations.

In the next post, I will discuss component teams and present my view on how we can use hybrid approach that will allow scaling Agile software development in global teams.

1 4 5 6
×
×