Thursday, September 03, 2015

A Cautionary Tale of Co-founder betrayal at Fosubo, a Silicon Valley Startup- 6 Lessons Learned

When we hear that "Co-founder Conflict" is one of the biggest reasons that startups fail, we think it won't happen to us, until it does! Yes, it happened to me. And finally I decided to share my story with you all. I hope this will help you if you are starting a venture with someone you have never worked with before. So here it goes:
The Back Story:
I met my co-founder Misa Chien through a colleague and friend back in August 2013. I was coming off of another startup in the process of shutdown for lack of subsequent funding after 2 years of existence. At the time Misa was also in the process of shutting down her previous small business (Food-truck called "Nom Nom").  She was brought onboard of Fosubo (our startup) as a CEO in July, 2013 by her then boyfriend Nico and Nico's friend Pato.
Fosubo was born out of a hackathon that Nico and Pato participated in Chile organized by AngelHack in May 2013, where Fosubo won. Fosubo was then invited to present at the AngelHack Global Demo Day in Silicon Valley on September 5, 2013. While Misa, with the help of Nico and Pato, were preparing for the demo day, she started talking to me about the possibility of joining as the co-founder and CTO. Both Nico and Pato were running their own startups back in Chile, and were not interested in seeing Fosubo through full-time (or so I was made to believe!).
My Fosubo Journey:
Our conversations led to forming a partnership (verbal) between Misa (as the CEO) and myself (as the CTO), while Nico and Pato stayed on as advisers. With that verbal commitment, I started working with Misa in early September as Fosubo had won the global demo day securing $25K investment from Right-side Capital. We were hard at work with our Pilot client (a T-Mobile franchisee) and preparing for the YC winter session 2014 application. We had not formed a formal company at the time. I had deferred all those business activities to Misa, while I focused feverishly on our product to make it work for our pilot client. We had rushed through all legal filings as we applied to YC, but we did not get in. Subsequently, we applied to 500 Startups and AlChemist, and got rejected by them as well. We also had participated in Women 2.0 in February 2014.  All these were in the first 6 months of our business!
While getting rejected from the accelerators, we were working hard as a team to learn and evolve our business model & product to make it work for T-Mobile franchisees to a point where we were able to convert our pilot client into a paid client by April 2014.  After a successful pilot, we were able to sign up couple more franchisees in quick succession. We knew then that we had found our product/market fit in the telecom retail space! During this time we also raised more money from angel investors to help us pay for our operation & customer development costs.
In May 2014, we decided to apply to YC for the second time. This time, to our surprise, we received an offer of acceptance contingent on us making a drastic change to our "CAP" table. YC did not like the fact that Nico and Pato had about 11% equity between them as advisers. They also did not like that Misa and I had unequal shares. They wanted us to bring my equity close to hers and remove Nico and Pato altogether. We desperately tried to figure out ways to accommodate what YC was looking for. However, ultimately we could not find a solution, and our YC hope had died with that (we were invited to apply for the next session if we could take care of the CAP structure issue). We were so close to be part of a great network that every entrepreneur hopes for these days, only for it to be taken away for something I had no control over! It was such a let down.
As we were preparing to scale to all T-Mobile franchises nationwide, we were struck by lightening again. One fine morning in June 2014, we get an email from one of our paid clients that T-Mobile Corporate had asked them to stop using Fosubo as it was not approved by them. Just like that we had lost all our clients overnight! We scrambled to contact T-Mobile through many different channels to convince them to allow their franchises to continue to use Fosubo. Our plea fell on deaf ears! Not ready to give up, we quickly switched gears, and looked into other telecom retailers like AT&T, Sprint, and Verizon. As luck would have it, we had learned that Verizon is not as hands-on with their franchises as other telecom operators are. In two months we were able to sign up couple of Verizon franchises, and were able to show similar positive results as we had shown to T-Mobile retailers. It seemed our fate had started to turn for the better by early September. We were able to line up a few potentially large Verizon franchises- a total of around 2000+ stores among them.
And then on a Friday in September (conveniently just a month before my first year vesting date), Misa broke the news that she no longer wanted to work with me. Caught by complete surprise, I was devastated, and frustrated. I found out that Misa with the help of her now Fiancé Nico (they got engaged in June 2014) removed all my access to our systems, email, and everything. I quickly reached out to some of our investors (as it turned out they did not know anything about it either) asking to mediate a reasonable solution. One of the investors agreed to help, but Misa quickly turned down the offer of help. All my attempts at finding a reasonable solution were met with refusal.
I had trusted Misa and Nico, worked my butt off during the most nascent time of Fosubo, had put everything on the line by depleting my savings in the process, only to be betrayed at the end! That's the ugly side of entrepreneurship that is not talked about as much. Sadly, if anything, we see Silicon Valley celebrates the get-to-success-by-any-means type of entrepreneurs, and unfortunately some wrongly interpret that as get-to-success-by-dishonesty!
Lessons Learned:
Here are a few things I have learned the hard way from all of this:
1) Do a reference check on your potential co-founder(s): This is something I did not do on Misa. Had I done this, I would not have worked with her. I took her Nom Nom story on the face value, and never thought about doing a fact check. As it turns out, when I reached out to her former business partner at Nom Nom, the story was much different. It is not about believing one story over the other. Instead, it would have at least cautioned me to not trust her blindly. The lesson here is to always do a reference check. Any red flag, think twice before partnering.
2) Hire your own lawyer: I trusted Misa to hire a lawyer that represented both of us equally. I signed all papers without really reading them thoroughly and verifying with a lawyer of my own. I had painfully learned later that the lawyer we (on the dime of Fosubo) hired did not protect my interests in Fosubo. I was not involved in hiring the lawyer, so I am not sure what the conversation was between Misa and the lawyer. Evidently they only protected her interests. The lesson here is make sure to get involved in engaging a lawyer, and / or  make sure to get your own lawyer to independently verify that you are protected.
3) Agree only to the same vesting schedule for all: I had naively agreed to a vesting schedule with a one-year cliff, while Misa, Nico, and Pato started to vest immediately. It did raise a concern in my mind at the time, then again I thought we would know in 3 to 6 months whether we can work together. It would become a moot point after a year. Boy was I wrong! The right thing to do is to have all founders on the same vesting schedule. It does not matter who came up with the idea, or who joined when. The standard vesting schedule seems to be 4 years with a one-year cliff. If your potential co-founder seems to think otherwise, run away from that venture!
4) Agree only to equal equity structure: I bet YC must have seen many startups fail because of uneven equity distribution. What was even more alarming at Fosubo, not only Misa and I had a substantial difference in equity, we had Nico and Pato holding a significant share for advisory roles (in their mind they thought they deserved those shares just because they did the hackathon).  We all know an idea or an early prototype is nothing but just that. Over the course of a startup's lifetime the idea and the product change fast and furious. And it did at Fosubo. Of all the things, this was my biggest issue in considering joining Fosubo, yet I had given in. It is not so much that I should have a bigger share, but it goes to show the mentality of the potential partners. The lesson here is that If you see similar mentality in your potential co-founder (that is an entitlement to larger share for any reason other than putting up dollars as an investor in addition to being a founder), run! Also, if there is any personal relationship between some of the founders (like Misa and Nico in my case), be weary of that. In my case, it played a huge role in motivating Misa to pull such a move on me!
5) Keep a personal record of your communications: I had all my communications with everyone in my emails and Google docs under my Fosubo account. When I was blocked from my accounts I lost everything. The lesson here is to always keep a copy of all communications and documents at a different location- in a personal Dropbox account. And do that periodically!
6) Get to know your investors and clients: When I was frantically looking for email/phone contacts of our investors I quickly realized that I did not have them. Even more importantly, most of them did not know me in person. I deferred the responsibility of fund raising to Misa, and did not think about building a personal relationship with them. The lesson here is that all founders should get to know all early investors and clients until the company starts to scale.

If you are thinking of starting a new venture with someone you did not work with before, I hope you find these tips helpful and start the relationship on the right foot.  I would say this though, I did not lose faith in people. I believe most of us are well intentioned and want to do the right thing. It is just that we get caught up in the short-term greed, and/or misinterpret what we read in the media.  Let's promise ourselves to celebrate the right kind of entrepreneurs, and encourage the right kind of behaviors. In the end, fail or succeed, it is the journey that matters more so than the results! We should be remembered for how we made each other and our customers feel more so than what we built!

Saturday, January 03, 2015

Three Common Struggles of Agile Teams

I have seen three common issues that many Agile teams struggle with. I will try and address them here for future references.

We need to increase our sprint length...

This usually comes up after a team has gone through a few months of sprinting. Most teams start with 2 weeks of sprint (you cannot go wrong with this choice for an established company/team). Some smaller teams, specially startups choose 1 week of sprint (highly recommend it for startups since product is usually in exploratory stage). However, most teams find themselves not being able to finish what they plan to deliver early on. While it is demoralizing, it is perfectly OK to find yourselves in this situation. Every team goes through this stage (if you hear otherwise, they are lying...:-)). A quick fix for this would seem to be increasing the duration of sprints, right? Wrong. Sprint length as the cause of the problem here is a red herring. The fallacy lies in the thinking that having more time would allow the team to finish everything they plan for. It is a classic fallacy as aptly captured by Parkinson's law- 

                           "work expands so as to fill the time available for its completion"

The issue commonly lies in estimation. There are a few things that cause estimation issue in an Agile environment:

       a. Not being able to break stories. Right sizing stories is tricky and requires experience (trial & error).
       b. Not taking into account other regular commitments (production support, company activities, non-project meetings etc) by team members
       c. Bug fixes, ad-hoc requests

All these and other similar activities are most likely taking team's time away from actual project work and not getting reported/visibility for the planning. Team needs to identify those and plug those leaks.

However, not being able to finish what a team plans to deliver should not come as a surprise at the end of the sprint. This should become apparent thorough the effective use of "Daily Scrum." If it is not happening for your team, revisit how Daily Scrum is being conducted.

The most important aspect of a good Agile team is to be able to proactively manage expectation and eliminate surprises. 

I cannot  contribute to estimation as a non-developer (e.g., tester, analyst etc)....

Relative estimation can be confusing for people coming from traditional project management. Heck, it is still a conundrum for many of us doing Agile for a while. We understand the basic idea of it. But, probably not comfortable effectively using it in practice. A common question comes up usually from the non-developers on the team is -

                 "I'm not a developer so I don't know how long it will take for us to implement."

That is a fair concern. However, this concern stems from the assumption that we are estimating only the programming (programmers) aspect of the development.  That is partial view of the estimation. The correct way of looking at it is-

How would you size this story compared to a known story for all the work YOU (not others) need to do in your role (e.g. tester, designer, analyst etc.)? 

For example,

A 5-point story means it is going to take approx. 1.5 time more work for everyone involved compared to the known story estimated to be 3 points.

Another important distinction of relative estimation from absolute estimation is that we Do Not Add up Points estimated by each role or individuals. We just pick the agreed upon point. Now we could use some heuristics in picking the point estimate after discussing the differences in our estimations. Examples of such heuristics are-

   a. Pick the largest one (it is a safe play).

   b. Pick the majority one (common in practice).

   c. Pick the one based on the nature of the story- e.g., if a test heavy story, give precedence to the estimates by the testers. If it is a design/UI heavy story, e.g., give precedence to the estimates by the designers/front-end developers. You get the idea.

Couple things to remember about relative estimation:

  a. It is important to be consistent with regards to how you pick the point estimates.

  b. Over time, the team will get efficient with estimation. So, do not worry if it takes longer in the beginning!

I don't understand why we need to break our requirements into smaller stories when we know we need the whole thing...

Product owners new to Agile inevitably find it difficult as well as frustrating to be required to break feature sets into stories appropriately sized for implementation in a sprint. While describing requirements as stories is intuitive, breaking stories into smaller stories yet maintain meaningfulness from a user/business perspective is not. It requires practice by trial and error. However, sometimes the importance of breaking large stories into smaller ones are not apparent to the Product Owners. Here are few important advantages of breaking large requirements into smaller stories:

      a. Allows you to roll-out the most important part of the feature set early and get feedback and adjust accordingly.

      b. Allows you to address business risk, or technology risk first with just enough time & money commitment.

     c. Allows the team and the customer/sponsor to maintain a high level energy & momentum derived from the  satisfaction of making steady progress (very important, but often neglected aspect of team dynamics).

     d. Avoids implementing unnecessary features. It may not be apparent what parts of a feature set are *actually* necessary. The only way to figure out is by delivering and validating them in small chunks.

Still not convinced? Would love to hear your particular situation and discuss in the comments section.

Friday, August 23, 2013

Refactoring is the hardest skill to master
I see a lot of discussions around how to spot a great software developer from an average one. Mind that I did not say rookie vs. experienced. I hear many criteria. Years of experience should not be one of the criteria for many reasons. Based on many recent job postings by many hot startups, it seems someone who can whip up solutions to complicated algorithmic problems (a specialist skill), does test-driven development (might show discipline), creates/contributes to open source projects on Github (shows initiatives), active on Stackoverflow (shows initiative and willingness to help besides experience with similar issues), and has a blog (shows initiative and willingness to share) is seen as a great programmer. While I understand the thinking behind them, but I recently realized that a great programmer is someone who is proficient at refactoring.
It is relatively easy to write something from scratch. But it is really hard to incrementally make an existing codebase better while adding new functionality or modifying existing ones. Everyone wants to write new codes for exactly this reason. Let’s face it, we developers never like working on even our own codes written a while back, let alone someone else’s codes. Not only we have to overcome this huge mental block of working with existing codes, but also muster up the courage to deal with the unknowns that come with such efforts- breaking something else, uncovering unpleasant traps, reverse engineering business logic, or writing missing test codes etc. Refactoring requires great design skill, aptitude for quick learning, forensic-style debugging, and discipline as well as patience and grace.
If you are looking to hire a programmer, why not just ask the potential hire to refactor an existing code that he/she is going to work on anyways, if hired. And observe not only what he does, but also how he does it, and ask why he did the way he did.

Wednesday, September 14, 2011

Game mechanics in the Enterprise software

It boggles my mind how we still tolerate all the incredibly stupid apps (B2B or Enterprise software in general) that we use at our workplace everyday. While consumer apps have shown us what Web apps should look like in the 21st century, enterprise software, even the ones that are currently being built (might I say in the process of re-platforming- from Mainframe to Java / .Net), are still in the dark ages. There are a few reasons for these,

1. Strict adherence to specification, hence no room for innovation,
2. Strict focus on correctness of features rather than usability & user engagement,
3. Fear of challenging status quo,
3. Generational gap (not in literal sense) between the people (developers) who work on enterprise apps vs who work on consumer apps.

Recently I came across a few posts by Brad Feld on the same topic dubbed as Enterprise 2.0. These posts are a bit dated (in 2007/2008). It is now almost the end of 2011. I guess Enterprise is not quite social yet. I would still agree with Brad that the Enterprise software is ripe for disruption more now than ever before. However, I would look at this disruption from a different perspective- usability and engagement than social. In consumer space, apps became social (interaction with friends) first before they became usable and engaging (through game mechanics). While making the enterprise software social (interaction with colleagues; see what I mean here) may seem interesting, I contend that it is not as beneficial as making these apps highly usable and engaging in and of itself using game mechanics.

Here are few trends in usability that enterprise software can easily adopt. Applying game mechanics on the other hand could be tricky and will require analysis of the domain as well as business goals. Nevertheless badges, points, voting,  recommendations, check-ins coupled with clever data visualization can be put together in a way to foster right collaboration and coopetition among employees (in other words encourage right behavior) to achieve business goals faster. In fact, enterprises can tweak these elements in a way to encourage a work culture that is unique, and thereby gain competitive advantage.

Are you using any application at your workplace that has these features already? Or are you currently working on a project where you are going to implement / experiment with some of these features? Or, I would love to hear how you would incorporate game mechanics in the apps you use at your workplace.

Friday, August 19, 2011

A simple guide to effective logging

One of my coding pet peeves is lack of useful log messages. While logging is the simplest, yet effective tool in a developer's arsenal, it is often the most neglected one. We developers do not take the time to think through what and where we should add log messages in our codes.

We tend to use only "error" and "debug" level log messages. We use "debug" messages to help test our codes during development stage. But we add these debug messages on an ad hoc basis. And, our applications usually do not have debug level turned on in production (and we don't want to). The only other time we log messages is when there is an error or exception. This is partly because traditionally developers are not required to provide operational support for the software they write. They are usually removed from production support by 1 or 2 levels- a support team in the client's organization and then another in their own organization. With SaaS model, this separation is going away to some extent, but the issue persists. Well thought out log messages can save a lot of time & frustration with debuging production issues.

Here is a set of rules I use when I write codes,
  1. Use a good mix of 4 levels of log messages- error, warn, info, and debug.
  2. Usually "info" to "debug" ratio is 30%.
  3. "Info" is the most important log level from operations perspective, yet the most neglected and misunderstood one. Systems should run at info level. I see it as the "system's heart beat." At any point in time, anyone should be able to say how the system is doing by reviewing info messages. The trick is to achieve that using the minimum number of messages with just enough useful information.
  4. Use "info" message to trace high level application flow.
  5. Use "debug" message to trace detailed level application flow. Never use "system.out" messages.
  6. Use "warn" level messages when system can recover from a failure. Also use warn when a user is doing anything unusual, i.e. multiple attempt to login, or trying to access functions that they are not supposed to etc. This is specifically useful in the SaaS systems. "Warn" messages can serve as an early warning signal.
  7. Send email when an "error" message is logged. Do not use "error" level if you do not want to receive an email about it.
  8. Be vigilant about what data you write out in a log message. Only enough data to help track activities, but never any security sensitive data (in the context of the domain).
  9. Add context to the log messages. For example, date & time, line#, class name, method name, session id, user id etc. Logging frameworks available in most languages now-a-days are designed after "log4j," one of the most well-designed framework by Ceki Gülcü. Log4j and similar frameworks make it easy to automatically add this context to all messages. 
  10. Format log messages in a way so that it is easy to plop them into a tool like Excel for easier analysis. Here is an example of a good formatted log message,
[ DEBUG] | 110817 21:28:58 | pid-609 | user 2 | session 12345 | controller | effective_logging.rb:17:in `descope_multiple' | wi 12 descoped
Here is an example code showing a good mix of log messages used:

What guideline do you follow for logging?

Wednesday, August 10, 2011

7 usability guidelines for developers

Over last year, as we worked on improving the usability of ScrumPad, we learned a few things that are not so obvious to us "Developers." The conventional wisdom is that usability is something developers don't understand, or should defer to interaction designers. Some aspects of interaction design probably require specialist skills. But, here are seven things that we developers could easily do to improve usability by an order of magnitude.
1) Choose an appropriate default behavior.
Most applications have a default use case. This is usually implemented through some parameters with some default values. But, we do not take time to carefully analyze and understand this default use case. It is an after-thought or an ad hoc decision most of the times. Worse, we defer this to users by making them go through an elaborate setup process to pick the default values. We feel that users would feel empowered if we make them explicitly set these values themselves. As it turns out, most users want to get up and running right away and expect the application to just work. Customization, if necessary, should be "as and when" needed, and should be presented to the users in the context of their actions (and not as a separate action). We call it "on-demand incremental context-sensitive customization." For example, in ScrumPad, users can create a project with 2 weeks sprint as a default (they don't have to do anything extra). When they define sprints, the system would set the end date 2 weeks apart from a given start date. We even help pick the start date based on the last sprint / current date. We also pick the name of the sprint as "Sprint#count." However, users can change the length of a particular sprint by changing the pre-populated dates, or they can change the name of the sprint, if they want to, when creating the sprint. It may seem trivial, and it is, but this little thought about default behavior can greatly enhances the user experience.

2) Minimize required information.
Most applications have forms to collect different data. Some of the elements on these forms are required and some are not. We tend to make more data required than we ought to. What we found is that most of the time we over think what we should make mandatory when we collect data from users. We should really question our assumptions about what we think are really necessary. We need to allow users to move forward with the minimum information and let them provide rest of the information "as and when" necessary.  We call it "on-demand incremental context-sensitive data collection." Amazon does it really well. You can start shopping without needing to login. You are prompted for login at the last possible moment. We see this also in signup process for most of the new breed of Web applications. In ScrumPad, we used to force users to pick tags when adding stories. We thought we were helping the users by forcing them to think about themes / grouping for their stories at the time of creation. Our users did not see it that way, instead they found it annoying / limiting. We changed our mind and now it is an optional element, and the users are happy!

3) Trust users, not constrain them.
We tend to design our applications around the idea that our users, if allowed, would do things that they are not supposed to. If somehow we prevent them from doing "not allowed" things through different roles, we would help them. This Also gives us a false sense of satisfaction that our applications would become more secured. This was the case with ScrumPad when we initially designed it. Scrum promotes three roles- Scrum Master, Product Owner, and the team members. As any purist would do, we segregated these roles very strictly. As a result, we were forcing our users to fit into these straight jackets and made their lives difficult. As we faced with different real world situations, we started to relax some of these constraints by allowing users to be in multiple roles. Still with that, it felt like it was a work-around rather than natural. We started to question our assumption that we need to prevent one role from doing things that usually is expected of from another role. We came up with two reasons why we do this. One, we are afraid that we won't be able to track who did what. We could easily address this concern by implementing tracking "change history." Second, we are afraid that people will be confused about what a role entails. If this is the case, then we have a bigger issue than what a tool allows us to do. However, we are certainly not suggesting that we should allow everyone to do everything. Of course, we need to draw some lines among different roles, but we should minimize them to improve user experience with our system.

4) Mange the context.
All user actions have contexts. The context depends on what action was taken just before, what role a user is in, the location a user is coming from, what time of the day it is now, etc. etc. among many other things. Most applications don't do a good job of taking all these into account and making it easier for users to perform the action. For example, if you go to "Groupon" site for the first time, it forces you to choose a city or login/signup before you can see the current deals, whereas if you go to "Livingsocial" site, it recognizes your location, and allows you to go the current deals page for that location. Which one do you think is more user-friendly? Manging the context is becoming easier and richer (with location and other contextual inputs from other connected apps- i.e. social networks) now-a-days. It is in fact expected of applications to manage the context more intelligently.

5) Personalize interactions.
Personalization has become popular among applications now-a-days. We see this commonly implemented as "My page/data/tasks," popularized by "iGoogle" type personal Web portal sites. However, it is more static in nature, and requires the users to set it up. We can harness the power of personalization even more by making this more dynamic in nature. For example, what it means in ScrumPad is keeping track of report / search queries recently run, or the projects/stories recently viewed, or discussions recently participated in, or even better, organizing menus based on the usage pattern.

6) Don't interrupt, allow "undo".
Traditionally we have designed applications with many little interruptions in the form our pop-up prompts. This form of interaction design has been popularized by Microsoft. Here is a good illustration of this by Joel Spolsky in his Business of Software conference talk. The most common and popular of such interruptions is a "delete prompt"- asking user to confirm their intent to delete something. The thought behind it is users might accidentally clicked "delete," when he did not mean to. We know these situations are rare. We are interrupting all users most of the time for those rare occasions. Google has shown how we could avoid these type of interruptions by implementing "undo." We don't have to implement/support "undo" for all users actions. Given the context and domain of the applications, we could pick and choose actions that could benefit from "undo."

7) Learn and accommodate.
We are just starting to see more and more applications are designed to learn user behaviors and adjust accordingly. An example of this is Gmail. Gmail recently introduced tracking important emails. It tries to determine whether an email is important based on the context and the past actions by the users- whether the user opens an email from a certain user or with certain subject line for example. Also the users can explicitly tell Gmail which emails are important. Overtime, Gmail gets better at isolating important emails from regular. Recommendation engine (i.e., friend recommendation, content recommendation etc.) is another example where "learning" is applied. I'll use Zynga as an example to illustrate where an application could implement "learning mechanics." We all played Zynga's one of many popular games. One thing they encourage is to post status messages from time to time to Facebook. While I understand the motivation behind this, but it provides poor experiences to users who always choose to skip posting such messages. A better thing to do would be to learn the behavior of individual users and stop prompting for posting messages for the users that always/most of the time skip such actions. Instead, Zynga could provide a visible action button to post a message, just in case these users do feel to brag once in a while.

We can summarize these 7 usability rules into just one as Jared Spool would put it- "increase goal time, reduce tool time." In other words, we should do everything we could to not require users spend time in learning & using the tool (tool time) so that they can have more time doing things that they actually want to do (goal time).

The ultimate test of usability lies in how much training users need (in-person training, or help screen casts, or help FAQs) to start using a product. "A perfectly usable product" would not need any user manual, or training, or FAQs.

Do you have any insights for improving user experience?

Monday, July 18, 2011

Using Scrum of Scrum (SoS) as an early warning system

Typically we use Scrum of Scrum (SoS) as a platform to address issues between teams on a multi-team agile projects. Mike Cohen has a good post on the basics of SoS. SoS (as the acronym aptly captures this intent) is a good way to synchronize teams and resolve issues as they arise. However, it is a reactive approach. A better approach would be to turn SoS into an early warning platform so that teams can be proactive about imminent issues and prevent them from becoming real issues. In the process save everyone "valuable" times, and probably frustrations.

With that intent in mind, I suggested the teams of a distributed Agile project that I'm coaching now to use these questions:
                         1.  Is anything slowing my team down or getting in my team's way?
                         2. Is my team about to put something in another team’s way (DB changes, interface changes, UI changes etc.)?
                         3. What stories or bugs have been completed by my team since we last met?

Question 2 primarily, and question 3 to some extent serve as the sources of early warning. However, I quickly realized that teams would not knowingly report that they are putting anything that would impede other teams. So, I changed the question to be more explicit about the intent:

                  2. Is my team going to make changes to any shared resources (DB changes, interface changes, UI changes etc.), or checking in significant codes by the end of today?

This seemed to have helped. The Scrum Masters now need to listen in their daily scrum meeting more carefully to understand and be able to answer questions 2 and 3. Additionally, the teams are also tracking any inter-team requests at the SoS meetings.

How do you use SoS on your project?