Have you ever tried geographically distributed cross functional scrum team?

For one of the projects that was being built ground up, we formed a geographically dispersed cross-functional team. This team had a very good balance of developers, testers and a dedicated PO as well as Scrum Master, a role that I played. This team was distributed across US, Ireland, Cork and Bangalore, India. As a team, we lined out some really good development and Scrum Best practices and we started with a mission of forming a model scrum team that would start training other teams as they came on board.

The momentum of the team was great with excellent participation — A point to note here is – this was a global team – so some folks in this team worked off hours (late at night). As time progressed reality started sinking in — I just want to highlight few issues that became very obvious
  1. Planning meetings, Retrospectives, Demos, Daily Scrum meetings were becoming extremely painful due to time zone differences. Morning meetings in US meant late night meetings for folks in Bangalore and vice versa. Put Cork from Ireland in this mix and you are left with couple of hours slot in the mornings. As time progressed, getting full participation from all team members became challenging and as it was affecting people’s personal family time. This is where I believe site afffinity that Ken Schwaber swears on definitely helps to build team momentum.
  2. The idea behind co-located, self-organized team is to ensure that all issues are resolved by standing in your cube and giving a holler to your team mate. In global scrum teams, this is a major impediment, as defect fixes, build failures, code reviews, etc might have to wait until the next day. Again this depends on how the expertise in your team is distributed. As a Scrum Master, I have lived this experience where teams had spent cycles waiting for updates/feedback from remote site that could easily have been avoided.
As a Scrum Master, I saw the above mentioned issues first hand and after a few iteration we just realized that forming Co-loated teams at each site would make more sense. In any case, I still take pride in forming this team, as the development and scrum best practices that came out of this team are used by the entire organization.
What are your thoughts?

Can you form a Scrum team with just one person?

Recently, one manager approached me for advice on scrum practices which I was happy to assist with. This manager had a request to build some new features and integrate the same with the existing product. She was also looking to develop these new features using Agile software development with Scrum. All was good with me so far. What I found a bit unusual was this manager only had one person @ 60%capacity to work on the scrum. The manager herself would play role of a scrum master as well as a product owner.My first thought was does she even have a Scrum team, a team of just one? However, talking further with this person and understanding what she was looking for, I thought one person scrum might make perfect sense too. She was looking for predictability on how long it will take to get this project done with one person working at 60%. Secondly, she also wanted to make a case to management that this project might not be one person effort and would need multiple folks to pull this release off. So, scrum made perfect sense for both her concerns. For now, I have asked her to do capacity planning, list sprint goal, conduct planning meeting, and finally demo at end of the sprint to demonstrate what was achieved to management. Only time will tell how successful or not so successful she was. However, I am inclined towards saying one person Scrum team is a real scrum team and a lot can be accomplished by this one person army.I have posted this blog in scrumdevelopment forum and it has generated some really good discussion.

How to roll out a process for large global teams?

My role as a program manager demands communication in various forms within organizations. I have seen and used various approaches, some effective and some not when a new process is rolled out. I would like to share my experiences and at the same time would like to learn from your experiences.
My definition of a process, is a systematic and disciplined way of doing things that creates a positive impact on how the overall business is conducted. Some examples are scrum best practices, transitioning to a new tool, generating org wide common metrics, etc. Now consider rolling this out to a large (150+) engineering team (development,QE, project managers, etc) spread around the globe (America, Europe, Asia,…). The impact of a new solution depends on what mode of communication is used.
Email communication: I’ve noticed email communication works out better for general announcements like org changes, something to do with HR activities. However it has not always been as effective for process communication. Again, it depends on how big the change is and what type of impact you are trying to make. Email guarantees that a new process lands in everybody’s inbox, but does not guarantee that everyone will adhere to this new process. Why? Because as my new manager says, “every individual is wired differently, has different ways of doing things and has different attention span” -( I think I am going to take her offer to read a book on Human Dynamics). My experience has also shown that for email communication to work effectively, multiple reminders at constant intervals are needed for a process to be part of an organization’s DNA.
Meetings: From my experience, this approach seems to be most effective. This can be implemented in various ways.

  • One approach is to roll out a process in phases. Select couple of high performing teams and educate them on a new process. Monitor and measure their progress for a short duration (2 to 3 weeks). Once you feel comfortable, use their success stories and start rolling out the new process to all teams by conducting further meetings. This also gives you an advantage of making tweaks to the process based on working experience of these teams. The cons of this approach is, it takes a while until the entire organization comes up to speed.
  • Another approach is to form a team of key players like managers, team leads, scrum masters for Agile development across the organization that can be trained and educated on a new process. The next step is to hold them accountable as well as responsible for rolling out this new process to their teams. The trick to making this approach successful is to ensure that these subset of players talk and have same understanding of the process. If not, its difficult to get consistency, as each team will be trained differently based on the version of the new process understood by these trainers.

All hands: This forum can be a very effective and can make a huge impact if senior management briefly discusses the new process and enforces the importance of implementing it successfully for the organization. Honestly, I have my reservations on implementing any new process this way. Why? One. just because getting every participant in a room or on a phone in global teams is almost impossible due to timezone differences. Secondly, sharing minute details of a process and opening the forum for general Q&A is not viable.

Individual Goals and MBOs: Making everyone in the organization take a shared goal of some healthy percentage i.e 10 to 20 % almost guarantees that the new process will be effective. By tying dollars to a new process, everyone has equal stake in making the process work. However this can be an extreme step, as it can make lots of folks unhappy if the shared goal has to be marked incomplete.
In summary, there are multiple ways to roll out a new process in a large global team. The best way to ensure that everyone within the organization is in unison, is to use a combination of the above methods.

How can code reviews help with Agile development?

Effective Code reviews can help scrum teams scale in agile environment. In scrums I have managed, each team member allots 10 to 15 hours of their overall capacity to perform code reviews. It’s encouraged that each member burn out their allotted hours for code reviews before the end of each sprint. We are also trying to follow certain best practices around defining tasks that are granular enough so that the resulting code to be reviewed turns out small enough for team members to review.

What does code review help achieve

  1. It helps teams get familiarized in different areas of the code base.
  2. This makes each team member a generalist instead of a specialist in particular domain. No individual team member becomes a bottleneck (sick leave, vacations, etc..) as others within the team can fill in for their tasks.
  3. It helps establish common coding standards and gives common look and feel in the entire code base.
  4. Ensures that every one is generating enough documentation, writing unit tests for their classes, and functions.
The traditional way of code reviews resorts to email or some bug tracking tool like ClearQuest. In traditional code review, the reviewers have to switch between emails and bug tracking and it is kind of time consuming as well as at times a nuisance.
In my team we use open source tool Review Board. Review board is web-based and helps reviewers collaborate. It provides interface to enter comments on the code and has a summary page which lists comments from all reviewers. In addition, it maintains a history of submitted code reviews — a tool worth exploring.
I have seen overall Agile development experience as well as productivity of scrum team improve over time by promoting code review as one of the essential attributes before a story can be marked complete/Done.
There are plenty of good resources on the web to help you and your team get started with code review.

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 5 6 7