1. January 13th, 2010
beWeeVee's Scenarios
Programming collaboratively in
geographically distributed teams
Sebastian Fernandez Quezada
CEO
seba@corvalius.com
Versión 1.0

2. Header Information
USER TECHNICAL BUYER ECONOMIC BUYER
 Developer  IT Department  Director
 Architect  Offshore Manager  CIO
A day in life (before)
Scene or situation: Focus on the moment of frustration. What is going on? What is the user
about to attempt?
Borys is the lead programmer of a mid-size offshore Development Company based on
Poland. He is currently working on the corporative payroll system of its main client who is
based on the United Kingdom. He spends one week a month at the client company at
London working along the client in planning new features and requirements. That week is
always very intense as the face to face communication makes it a very productive time.
Borys is a very skilled developer, he got the lead programmer job after his superior was
required by the client for another mission critical system just a couple of month ago. Before
that he was the developer of the Transacting engine, the one that execute online
transactions on behalf of the entire organization.
In one of those trips an urgent change request was added to the backlog by Ian from the
business analysis team. That left them 4 days to do the necessary changes in the
transacting engine, and the rest of the application.
Irena was a very clever developer at the Warsaw team, leaving her in charge of the 120K
lines of the Transacting engine code, had been a no brainer decision. However, she was
quite new to the job of extending it.
Desired Outcome: What is the user trying to accomplish? Why is it important?
The change request was in fact caused by a new requirement issued by the England Central
Bank, and it must be in effect by Monday morning, when the company would start the
payroll processes to all their providers and workers. If they didn’t comply most tra nsactions
would be rejected by the source and requiring the company to handle each one individually
beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 2

3. by a manual workflow; with the volume of transactions scheduled to occur that was
definitely an impossible task.
Attempted approach: Without the new product, how does the user go about the task?
Borys meet with Ian and Irena for 2 hours to understand the scope of the critical request.
Irena was at the phone from Poland, and she was able to understand the main problem.
After that Borys meet with her by phone to speak about the extensions that had to be
performed on the rules engine to handle the requirement of the Central Bank. Borys knew
that the rules engine was capable of doing it with some extensions that would require slight
architectural changes in the adapters and rules logic. Being the most knowledgeable person
on the transacting engine (it was his baby after all), he explain in detail Irena the solution. It
wouldn’t take him more that 1 day to solve the problem, which would leave the certification
team Friday to perform all the required tests to put it in production on Saturday.
He continued with his planned work while Irena was busy working along the plan they laid
out. At the end of the day they spoke again, she was a little behind, and had to take a
couple of decisions that Borys wasn’t confident about. He had his time booked until after
dinner, so he wouldn’t be of much use that day. She continues working around the clock
until 1AM.
The next day, they had the daily meeting Irena needed lots of help with the rules engine,
but no one was as skilled at it as him. They phone called each other every 2 hours to assess
the status. Lots of emails with questions went back and forth, Borys was worried. At the end
of the day he had to take the airplane to come back to Poland, and they were already
delayed.
He went to the office on Saturday and started to review the code, he found very important
mistaken assumptions; it wasn’t Irena's fault, which was the first time she extended the
rules engine. That part of the system had been in place without modifications for almost 6
months. He had a hard time remembering all the nitty gritty details on why he did some
things also. They pair programmed and redid the entire feature and finished by 2AM. On
Sunday the Certification team had to come to the office, they weren’t very thrilled at it.
Deployments where done on weekends so the production team had rotating personnel that
worked on weekends so they didn’t mind.
Errors where found and corrected by Borys and Irena, working around the clock they
decided that if there was a bug they wouldn’t correct it; there was no more time, they had
to put the changes in production right now. The production team finished by 5AM London
Time and was ready to roll by 7AM. Most transactions were executed with some exceptions
beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 3

4. that were performed by hand. The mission has been accomplished. Remaining defects
where squashed during the week for the next weekend deployment.
Interfering factors: What goes wrong? How and why does it go wrong?
Irena was a very clever developer but her knowledge of the inner working of the rules
engine was not as detailed at needed, even if Borys was pretty detailed in the
documentation. Borys wasn’t able to see what Irena was doing because IT rules at the client
company didn’t allow him to use screen sharing software (banking network restrictions are
a norm almost everywhere) so his communication bandwidth was limited and wasn’t able to
track her steps to guide her. The end result was to restart the entire work Irena has been
doing for 2 days adding to the project wasted effort.
Borys knew very well the inner working of the rules engine (as he has written it) but the last
time that part was modified she wasn’t on the job. Even Borys had trouble remembering
why he did something like performance tweak here and there. Those detailed inner working
reasons are not typically documented because they are not worth the effort (except in cases
like this one).
The certification team at London was not very happy to have to work on Saturday night and
Sunday when they were told that they would have the build by Friday. And the production
team had to work around the clock to have the system productively by 7AM without the
entire certification process done; at the time they were already complaining that if
something bad happened it wasn’t their fault.
The system worked but they were lucky, as the certification process couldn’t be performed
in it’s entirely; so they risked a lot to go into production.
Economic Consequences: So what? What is the impact of the user failing to accomplish the
task productively?
Failing to have the requirement changes by Monday would have been a huge problem for
the client company and for Borys boss too. Having to resort to the manual workflow would
have delayed the payments to providers for 2 to 4 days, delaying also the delivery of
important goods. Borys boss would have trouble billing the extra hours worked by Borys
and Irena, as the client wouldn’t be too thrilled of the inconvenient.
beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 4

5. A day in life (after)
New approach: With the new product how does the end user go about the task?
Borys and Irena would have the meeting with Ian. Irena and Borys would fire up Visual
Studio, and try to connect through the Windows Peer-Networking stack (a peer-to-peer
technology that can pass firewalls that enable IPv6 edge traversal). Sadly the IT department
does not allow IPv6 traffic, so Irena shared the solution through beWeeVee for Visual Studio
Saas Viewer, a Silverlight application that is able to give basic access to the solution on the
other end.
Borys and Irena discussed the detailed implementation right into the code, putting
comments and discussing key details of the inner working on the rules engine. At the end
of the 2 hours conference call they had already laid out a solution straight in the code. That
was possible because they would simultaneously write code while they discussed the
changes needed. Borys helped Irena also to write the tests that would define the interface
and behavior of the rules engine changes.
Irena worked on her side, and once in a while Borys connected to the Saas Viewer to see a
fast playback of the changes that Irena is working on; in the event he discover something
that he was not confident it can work, he annotate the information in Irena 's code and sent
her an small review project tweet for her to notice that he was around.
Irena finishes by 4AM and by Friday morning, the build was sent to the certification that
took the entire day and Saturday morning. By Saturday midday the build was re ady to be put
in production.
Enabling factors: What is it about the new approach that allows the user to get unstuck and
be productive?
The live collaboration straight into the code that beWeeVee added to Visual Studio allowed
Borys and Irena a very efficient communication and collaborative workflow. The use of the
beWeeVee for Visual Studio SaaS Viewer gave Borys the ability to access Irena's solution
code in a split second from a web source, even if the typical workflow was disrupted for
security reasons inside the bank.
Furthermore, the ability to replay all changes that Irena made to the code was an invaluable
aid to let Borys understand in a quick glance the state of advance. Even more, being able to
beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 5

6. review some rule engine key changes months ago using the playback feature aided Borys to
remember key details that were invaluable at the time of communicating the solution to
Irena.
Economic rewards: What are the costs avoided or benefits gained?
One of the biggest benefits of beWeeVee for Visual Studio is that the communication
bandwidth is enhanced by working directly with the subject matter, not in an abstract way.
In that way, the mental model mismatch between Borys and Irena get narrower, diminishing
the rework, accelerating the time it takes to accomplish the task. The solution obtained
diminished the needs of redesign and refactoring after production because the entire team
was more efficient.
Under the same assumptions, an alternative solution to diminish the risk identified after the
first day would have involved Borys to depart Thursday noon to Warsaw to join Irena on
Friday. Even in that case, they couldn't have been able to release the build for certification
on Friday mid-day.
Under a different set of assumptions the IT department would have permitted the use of a
remote desktop solution. That could make a slight difference on the communication (the
first 2 hours information exchange between Borys and Irena), however it wouldn't made
much difference on the efficiency of being able to write code simultaneously and the ability
to use the playback ability. So the efficiency would have been still much lower under those
assumptions. Moreover, as beWeeVee for Visual Studio is embedded in the native
development environment, the development workflow is not altered; something that would
have happened using other alternative software likes Etherpad or beWeeVee Web.
beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 6

7. Corvalius | Useful Change
info@corvalius.com | www.corvalius.com