My paper published for ICGSE 2011 conference in Helsinki

1. Keeping the spin – from idea to cash in 6 weeks.
Success story of Agile/Lean transformation
Jaroslav Prochazka, Marcin Kokott, Martin Chmelar and Jan Krchnak
Tieto
Ostrava, Czech Republic
e-mail: jaroslav.prochazka@tieto.com, marcin.kokott@tieto.com, martin.chmelar@tieto.com, jan.krchnak@tieto.com
Abstract— Lean and Agile courses we provided to our unit in
Netherlands encouraged our colleagues to start transformation II. TIETO AND OUR TEAM
of their business (IT Service provisioning). They decided to Tieto is Scandinavian IT service provider with the main
start with a distributed pilot project (including Indian delivery
focus on Scandinavian and Russian market, having now
site) and invited us to support the change. In six weeks we
managed to implement basic Agile practices. This increased
close to 17000 employees with up to 4000 in near and
motivation of people for continuous improvement and led to offshore delivery centers in Middle, Eastern Europe and
changes to working, staffing and contract models. This all Asia (India and China). Tieto net sales in 2009 was around
enabled more flexible value delivery to customer. We 1700 million EUR, EBIT was 75 million EUR.
conducted very rapid and intensive Agile Crash Course (on- Our team consists of 9 people working as Agile and Lean
job learning by doing with full-time support by skilled coaches) coaches supporting development, support & maintenance
based on principles of Lean Software Development. We and sales teams (focus on the whole value delivery chain) on
measured the progress using business driven approach daily basis. Our vision is to change people’s thinking and
(inspired by MCIF). In this presentation we would like to share attitude and teach them the way to uncover and solve
the story, the approach (improving the whole value chain problems. Part of this work is also identifying and removing
together with the customer, following Lean principles, delivery waste. More about our team and work can be found
respecting natural human behavior) and the challenges. in [3], [4], [5], [6], [7] and [8].
Keywords-component; Agile transformation; business driven III. DUTCH UNIT CHALLENGES
practice; global development model
Dutch unit has about 90 people located in city
I. INTRODUCTION Amersfoort. Customers of this unit come from
Lean and Agile courses we recently provided to our unit telecommunications, energy and financial sector.
in Netherlands encouraged our colleagues to start Dutch unit has great advantage in smaller size and
transformation of their business (IT Service provisioning). people’s attitude. Dutch attitude is open, straight forward
They decided to start with a distributed pilot project and curious. People are proactive and asking for the
(including Indian delivery site) and invited us as experts to rationale behind assigned tasks, for the goals and value. One
support the change. In six weeks we managed to implement of the activities building on top of this is regular monthly
basic Agile practices with only very short physical hands-on knowledge sharing session called “X-piration” session,
support. Steps conducted with the teams together with the where people can present various topics and lessons learnt
Dutch mentality increased the motivation for continuous from their daily work in a few streams. Topics presented
improvement and led to changes of the whole value chain, during the session we participated covered wide range of
starting with working and staffing model and ending with themes from Agile experience (presented by us), through
customer cooperation and contract model. This all enabled lessons from Indian visit to effective usage and setup of
more flexible value delivery to the customer. video meetings. Dutch attitude and ongoing activities helped
This paper explains how we achieved outlined us to setup right environment for the change.
improvements; what were the preconditions and what our Recently, Dutch unit started to implement Global
approach was. It covers mainly the following 3 aspects of Delivery Model (GDM) in selected projects to use skilled
Agile and Lean transformation: (1) focus on the whole value but cheaper engineers and also to be still competitive among
delivery chain improvement, (2) sustainable transition global players. Since the software development model of
approach respecting natural human behavior and (3) selected projects was based on traditional waterfall phases,
measuring and monitoring the change using business driven management decided to transfer only development phase
approach. activities to Tieto Indian Global Delivery Centre (IGDC).
Traditional way of working of Dutch unit was based on
waterfall approach and caused several problems. When

2. GDM was introduced, these issues were multiplied and support being physically with the team in Netherland,
became more visible. It was one of the triggers for the possibly in India as well. To nurture local change agent was
change and resulted in people themselves asking for help. the second key aspect of our planned approach.
Request for our Agile training sessions was one of the steps. Because of vast amount of existing case studies and
Issues our colleagues experienced were following (source: approaches related to Agile and Lean transformation we
interviews with team members): analysed also similar work and case studies. We investigated
• Chaotic communication, mostly visible in context of namely the work of Vilkki [15], Rico [13] and Taipale [18]
GDM. to cover the whole chain and affect the whole organization.
• Lack of coordination of team activities causing For this purpose we insisted on business driven approach
delays and rework on both sites (Dutch as well as inspired by IBM’s MCIF® [9], SEI approach [10] and Krebs
Indians). [19]. Sustainability of Dutch team change when we get back
to our office was the second analysed topic. We had built on
• Uncertainties about defining and allocating tasks and
top of our experience [3], [4], [6], [7], [8], but had inspired
micro-managed Indian colleagues.
by Howard [14] and Shrinivasavadhani [17] as well to name
• Low team commitment as result of previous issues. a few. The question of very time limited physical presence of
• Lack of project’s progress visibility. mentors helped us to answer also Sutherland [16], [20],
• Low customer satisfaction with the quality of Howard [14] and our competitors from WIPRO [17].
delivered results.
B. Training Sessions
IV. OUR APPROACH Our cooperation started by conducting 3 training courses
In this chapter we will focus on the approach taken and related to the Agile way of working for selected people from
also on key aspects and actions driving and contributing to Netherlands unit. Indian colleagues were not involved at this
the organizational change. Current status of our face to face time. We were asked to conduct Agile Introduction course
mentoring process based on our experience consists of four (called What Everybody ought to know about
phases [8] ensuring that we focus on right things and Agile/Scrum/XP/Tieto-Agile), Agile workshop for Sales
continue with the cooperation only if necessary and finally Global Delivery Awareness (GDA). What
preconditions are satisfied. The phases and their focus are started as standard training sessions very quickly evolved in
following [8]: highly customized workshops with the participants (we
• Mapping phase – collecting relevant information, apply lean and agile principles also in our daily work). This
identifying stakeholders, establishing relationships, evolution was caused by open and curious Dutch mentality.
conduct interviews, map value delivery flow. People wanted to see lessons learnt from transitions we were
• Setup phase – defining steering and cooperation part of. They asked how others did the change, what were
model and measurements; visualize work in progress the challenges, problems, how we overcame them and what
of improvements, conduct initial Agile and Lean solutions we applied.
trainings.
• Mentoring phase – day to day mentoring work
(implementation of selected practices), mostly hands
on support of the team; we also serve as early
warning mechanism and gather data from
established measurements.
• Independence phase – gathering of measures, on
demand consultancy, questions and answers.
In this case it was not possible to follow our standard
mentoring approach because of distance and distribution of
the team and our office. In such cases we usually search for
local change agent to support the change locally and stay in
touch with us. There was none local experienced coach
either in this case. Thus we did thorough analysis of existing
approaches inside and outside our company to follow the
most suitable approach fitting existing constraints and
conditions. Figure 1. Teamwork during our agile game.
A. Related Work Analysis We started the week with one simple exercise to
Based on our 5 years experience with coaching in challenge people’s mindset and stimulate out-of-the-box
distributed environment in Tieto, we knew that we would thinking. This exercise was based on one simple question:
start with some sort of kick-off workshop, training and “Why we want to improve?” Identification of common goal
motivation session followed by specific amount of hands-on is important first starting point. If people do not share or do

3. not see common goal, any next step is useless. Fortunately, We presented Hofstede’s 5D model and explained on
this was not the case and the exercise was just a discussion many examples what do these differences mean in practice
opener and audience synchronization point. Introduction and explained the root cause of issues mentioned above
training was very interactive, full of discussions and we had (misunderstandings and late deliveries). GDA became also
a lot of fun. People really enjoyed our game explaining interactive workshop after this introduction session.
Agile principles in practice, mostly:
• Agile estimations,
• Two-level planning,
• Tracking the progress using story points and burn-
down chart,
• Definition of done,
• Customer definition of quality,
• The power of regular demonstration and feedback
from the customer,
• Cooperation and team work when preparing the
estimates, plans, lessons.
Based on the flow and topics mentioned by participants,
we changed training structure and incorporated two case
studies (success stories) from our previous involvement.
Presented case studies convinced people about possibility of
the change even in more complex and traditional
environment (Energy sector, see [4]).
Next days we continued with Sales workshop with
slightly changed audience. Audience shared a story that
opened their eyes recently. They visited customer premises
and saw people doing the job that resulted in huge list of
improvements (about 90 items). We discussed Go and See
principle more often that day. Another issue uncovered
during this workshop was whole value delivery stream
focus. People realized that customer involvement was Figure 2. Difference between Dutch and Indian culture according the
important if they wanted to change their way of working. Hoffstede’s 5D model.
Vendor’s role in this case is to conduct training, answer
risen questions and propose solutions. People knew about Part of our involvement during this week was a lot of
delays caused by waiting for customer approvals for every side discussion with project and department managers
single document. Of course, one of the problems mentioned regarding the change, our experience, their problems, root
was how to secure the business. These inputs triggered the causes and solutions. People really cared and tried to get
discussion about Agile contracts. from us as much information as possible.
What was surprising and drive Global Delivery
Awareness (GDA) was no knowledge of cultural differences After the week we returned back to our home office, but
in the audience. They experienced many issues with Indian stayed in touch with our colleagues. They informed us about
colleagues, but many of them were caused by different the change of way of working in chosen pilot based on
cultures, way of thinking and also by not very efficient Agile practices learnt during training sessions. They started
cooperation model (only implementation phase transferred a project kick-off with the whole development team
to India). Typical problems rooted in culture were (1) not including Indian colleagues. The kick-off was led as
stated expectations causing clashes and misunderstandings interactive workshop focused on project objectives and
and (2) not filled commitments, not delivered results on time. scope clarification. At that time, team created all-day Live-
The reason is: meeting to facilitate the communication with colleagues
• Indian colleagues do not say NO even they know from India. The main change was involvement of Indian
they are not able to process the task. They try to do team in project initiation phase. This involvement helped
their best to avoid conflicts, so they rather say “we them to understand customer needs as well as project
will try”. background.
• Schedule and deadlines are understood by Indians as Other good practices placed from the start where regular
guideline only. Dutch people silently take them as daily meetings to boost the communication between the
strong commitment. distributed teams, placing the whole Dutch team in one big
room which has also helped in involving every critical role

4. in discussions about solutions and design w which could meet
the customer expectations and provide bigge value.
est After arriving on stage, we learn that the environment
ned
But at the same moment the team has started to struggle and set-up required change of th priorities of selected
he
with some areas due to lack of experi ience with agile practices. Based on our experience we decided to start with
transition. They have realized that the theore
etical foundations Iterative development, Two-level planning, Whole team
are not enough when applying in su uch a complex concept and User stories. Thanks to IBM MCIF® approach
o
environment and they also failed with two initial iterations. we could change the practices to contribute to the business
c
As the result we have received the request f help in further
for goal even more.
implementation of agile practices.
C. One Week Crash Course
Due to the fact that the project was ongo
oing and had one
week iteration pace, we needed to come up with some
e
approach that could serve this reason. We needed to plan,
e
implement, measure but also sustain the cha ange in one week
only. At the same moment we wanted to nurture potential
change agent that could keep the spin of imp provements. This
was the only option from our experience tha could guarantee
at
the success of the pilot project. These consttraints required a
lot of out-of-the-box thinking from our team
m.
Based on our experience and the analysi of related work
is
(see chapter 4.1), namely Sutherland [16], [2 Howard [14]
20],
and WIPRO [17], we came up with the prop posal of the Agile
Crash Course – 1 week, intensive in-h house workshop
consisting of facilitation, mentoring and guuiding production Figure 3. Agile dashboard used by team
d
team using our experience and knowledge. The course was
.
led by two coaches from our team because we practice pair- The first change we started wit on the very first day,
th,
working. was the Agile dashboard (coming from Agile and Lean
g
Before the Crash course we had co onducted several thinking practice of visualizing the workflow [2], see Figure
teleconference discussions to elaborate more issues
e 3). It gave team the opportunity to monitor current status and
m
uncovered during training sessions (to find the root causes), incorporate whole team thinking by assuring that the teams
y
these were: (both local and India) know the situ uation and care about the
result. The power of visualization resulted in changed team
r
• Inefficient communication i
in distributed
behavior. Team members were imm mediately able to identify
environment,
issues, uncover the root cause and propose and implement
d
• Unclear roles and responsibilities in cross-functional
n improvement to their current way of working. It was not only
f
distributed project, visible for us but was also menti ioned by team members
• Measurements of practices to be implemented in during the summary of Crash course e.
distributed environment, During the very first day, we ha gathered and clarified
ave
• Cooperation model with the custome er, the expectations from each person from the team. The goal
• Project management in Global Deliv very Model using was to connect all the actions an changes not only to
nd
the sprints (iterations). business goals but also to personal needs. This was the driver
n
for action prioritization as well.
Based on quick analysis we agreed on project business The schedule for all days was following:
goals helping us to identify potential practices to be • In the morning we started with synchronization with
w
implemented. Business driven approach co onnects practices local change agents and proj leader about the plan
oject
and business goals [1], [9] and [10]. We had to choose
e for day (30 minutes).
limited amount of practices, that would con ntribute to agreed • Until the noon we tried to ta with the people while
alk
business goal and that we could successfu implement in
ully implementing the changes in respected areas. We
one week. Agreed business goals accordin [9], [10] were
ng participated in every team meeting and if needed, we
m
“Increase innovation” and “Reduce Time- -to-Market”. The facilitated it (first two days) just to show to the team
)
practices that would bring the biggest value to business goals the direction.
according IBM MCIF® [9] were: • In the afternoon we provid hands-on support and
ded
• Iterative development, were answering all the quest tions.
• Two-level planning, • We ended up the day with 30 minute retrospective
h
• Whole team concept, and summary with the who team, and if possible
ole
• Test driven development, communicated the progress to all stakeholders.
• Continuous Integration, • After official end of day we stayed in office to be
w
• User Stories. available for additional qu uestions and to talk to

5. people to establish and strengthen social requirement and user stories selected for sprints) and ran
relationships and trust. quick workshop that resulted in rewriting almost whole
scope using the improved user stories format.
The morning and afternoon coaching meetings were the The open window approach (bi-directional whole day
only overhead meetings in place. All the other actions were video connection) allowed even for informal discussions
implemented hands-on by performing real tasks in the with remote team-mates. This helped to maintain social and
project. personal relationships established during project kick-off.
We also discussed issues perceived by different roles in
the project during that week. Coaching the project manager The key success of the approach was based on many
was focused on his current challenge, namely how to manage factors. Some of them where more critical like:
rapidly changing environment with highly self-directed team. • Trust from the team (built already during the training
Testers’ issues were related to understanding they way sessions and face-to-face discussions).
he/she can work with the team. Key question was: “How to • Adaptive re-planning (based on the results of the
support the high speed development when functionality was day, feedback from the team and visible signals of
developed in less than couple of hours or days”. From the issues/opportunities).
first failed sprints he got the understanding of importance to • Cross-functional teams in distributed environment
test all functionalities in the same sprint where they were which are able to take decisions about course of
developed. This led to strong understanding of term called development.
“Done-Done” (tested parts of functionality that can be • Using the Business driven approach to check the
possibly delivered as working part of the solution and brings adoption of the practices [9], [10] and being able to
value to the customer at the same time) [16], [20]. Stating change the selected practices (based on the
Done-Done attributes was also beneficial for offshore team. experience and real insight) without losing the
This helped to visualize not said assumptions of Dutch team overall high level goal agreed with all stakeholders
to Indian colleagues. (business goals).
Very interesting was also the role Functional designer
(business consultant). During the sprint, he was the most
active person describing and explaining to the team the real Iterative Development Results
need of the customer and end-user. It was more and more
Time-boxed
obvious that he has the most detail knowledge and Iterations
understanding of the domain from the point of view of user. 5.0
Soon enough the team started to understand that he is serving Micro- Working
Increments Increment
the role of Product Owner for the team by spreading the 2.5
knowledge about the domain. Thanks for being with the
team he was able to adjust the scope with functionality which Retrospective 0.0 Feedback Used
would best fit the environment of the customer and which
would bring most value for him.
This approach was replicated to communication with Just-In-Time Estimation /
offshore team. Functional designer explained the need and Detailed Plan Velocity
context behind the functionality to offshore team during Prioritized
sprint planning and during sprint itself. He also served as Backlog
Single Point of Contact for local and remote team.
Whole team practice was supported by emotional
Figure 4. Example of practice adoption measure using business driven
seismograph designed by the team. This visualized the mood approach.
of team members in tangible form, so that we were able to
see how people perceive the change and how they react. From the coaching perspective, we started the week with
During the week we focused on build-in team directive coaching style (advising) and through guidance and
improvement mechanism to achieve sustainability of the hands-on support to non directive coaching style by asking
changes. Learning mechanism consisted of teaching how to the questions to show the direction.
capture the issues, find the root cause and plan the long term We have achieved what was originally planned and due
actions with concrete short term solutions resulting in to the team mood, increased motivation and Dutch mentality
improvement ideas (not just for team’s way of working but we achieved even more. What surprised us was the fact that
also for the organization). Providing enough responsibility we have achieved that in two week sessions only (set of
and authority to the team (letting them came up with the training sessions, Crash course) and all the journey started
solutions and actions – so called autonomy [11]) caused huge only with a motivation of the team to try new approach.
motivation boost and resulted in success of the week with
even achieving more than expected. Last day we went D. Effort and Results
through existing issue (unclear value described by user Effort invested in the improvement was not really big. It
stories) to find the root causes (not enough experience and was five man-weeks (three mentors conducting the training
lack of connection between high level functionality sessions in one week, two supporting one week Agile Crash

6. course) from our side, what is approximately 6000 EUR We measured also practice level implementation to
including all our travelling costs. Investment from team side ensure that we can achieve stated business goals (Increase
was 30 man-days (ten people participating three days of innovation, Reduce Time-to-Market). The result of Iterative
training sessions). Development practice implementation is depicted in diagram
The only overhead for the team during the Crash Course in Figure 4. It shows the result of team self-assessment and
week was the introduction and summary meeting (both 30 basically means teams’ independence.
minutes), and additional one hours for internal coaches. All
other activities needed for change implementation were part
of team’s daily production tasks. V. LESSONS LEARNT FROM OUR NEW APPROACH
Results of the pilot project were interesting. Traditional Lessons learnt for the readers that can be applied in
measures gathered in each Tieto project showed following different GDM projects are following:
numbers: • Plan project kick-off with the whole team (all the
• Keeping the schedule (how well the original project locations), people will know the context, customer
plan was kept) was 32.7%. and its needs and can create personal relationships
• Keeping workload (how well was the team utilized) and social connections.
46.2%. • Focus on the whole value delivery stream (involve
• PAI (Project Accuracy Index, combination of both also customer) and cover the whole team (sales
previous measures) was 49.0%. people, managers, testers, developers, etc.), it creates
shared need [2], [11].
Based on these traditional measurements we could state • Focus on value for the customer and close
that the project has failed. But at the same time customer collaboration rather than keeping the contract
could regularly (during demonstrations at the end of sprint) agreement (if possible).
see the progress and working functionality and discuss • Conduct different role-based trainings to raise
changes required by business. Regular demonstrations awareness, involve also managers to get
helped also team members to learn more about the customer management support.
needs and led to the change of the project target user group • Mention expectations you have explicitly, write
(doubled the number of targeted end users). Of course, this them as part of Definition of Done to overcome
changed the original agreed scope, timescale and effort but in misunderstandings and surprises.
the same moment produced bigger value for the customer. • Establish micro-increments for remote teams as part
Thus our traditional measures do not capture the value for of iterations to ensure you can deliver.
the customer. • Start with mentor, coach to speed up the change
The measures (mostly indirect) evaluating the project as (share from other projects) and not to reinvent the
success was feedback from the customer, team and project wheel in every project.
owner. The customer proposed new project that would be • Nurture local change agent, he/she can sustain the
run in the same Agile way as pilot was. Customer change and continue internally with coaching role.
Satisfaction Survey (CSS) was above four out of five. Also
• Visualization and Go and See principle [12] help to
the team satisfaction was above 90%. All team members
uncover issues and their root causes (face to face
mentioned this project as the best they have ever worked in.
feedback, physical presence, visibility of the
Stakeholders commented:
situation, team mood chart).
• „New way of working contributed to higher CSS
• 1-2 practices per time are sustainable change.
(higher than 4) and Team satisfaction and resulted
in new business we got from the customer. Financial • Short iterations in the beginning help with quick
results show that margin will be always coming from learning (quick feedback, retrospectives,
the way how the contract was sold.” (Service impediments handling, coach synchronization),
Account Manager) • Measure the change from business perspective (what
• „As a result of our cooperation with the customer does this bring to customer and our business, how it
was implementation of the product to other retail helps) [9], [10] and have definition of done.
departments. That means doubled amount of • Autonomy of the team boosts motivation.
business users from 400 to 800 users.” (Business
Consultant) From the project perspective was interesting usage of
• „We now use the functionalities which we didn’t several tools and practices. We organized local and remote
figure out in the beginning of the project. We team around the architecture (components) with agreed
removed functionalities which we thought we interfaces but only after the architecture and way of working
needed. We have seen weekly progress which helped were stable. Communication issue was supported by cultural
us to think with the users instead of thinking for the differences training, personal presence of remote team during
users. We were apart of the solution and feel proud project kick-off and finally by the whole day video-
of the result.” (Customer representative) conference window. Whole team concept was supported also
by Agile dashboard and Mood chart.

7. This change cannot happen and sustain if we do not have [7] Prochazka, J., Experience From Agile Adoption In Distributed
management support and already motivated people (by Environment. In Software Development Conference 2008. VSB-TU
Ostrava, pp. 156-163, 2008.
mentality and training sessions).
[8] Chmelar, M., Agile coaching of distributed deliveries using Rational
Agile way of working start-up was supported by skilled Team Concert. IBM Innovate 2010 conference, Orlando, Florida,
and experienced mentors and was mentioned as critical 2010.
aspect by team members. [9] Kroll, P. and Cantor, M., Software and system development with the
From the Business perspective was important the IBM Measured Capability Improvement Framework. IBM Rational
connection of implemented practices with the project white paper. 2009.
business goals. Agile practices contribute to business goals [10] SEI, Goal Driven Software Measurement. CMU/SEI-96-HB-002.
of project and also to business goals of the whole 1996.
organization. [11] Poppendieck, M., Poppendieck, T., Leading Lean Software
Development. Addison-Wesley, 2009.
[12] Liker, J., The Toyota way. McGraw-Hill, 2003.
REFERENCES [13] Rico, D. F., Lean and Agile Project Management: For Large-Scale
Programs and Projects. In LESS 2010 conference. LNBIP, vol. 65, pp.
[1] Kroll, P., MacIsaac, B., Agility and Discipline Made Easy: Practices
37-43
from OpenUP and RUP, Addison-Wesley Professional, 2006.
[14] Howard, K., R., The Covert Agilist. In Agile Conference 2009,
[2] Poppendieck, M., Poppendieck, T., Implementing Lean Software
pp.131-134
Development: From Concept to Cash. Addison-Wesley Professional.
Boston. 2006. [15] Vilkki, K., When agile is not enough. In LESS 2010 conference.
LNBIP, vol. 65, pp. 44-47
[3] Prochazka, J., Agile Support and Maintenance of IT Services. In ISD
2010 conference. Prague. [16] Sutherland, J., Downey, S., Granvik, B., Shock Therapy: A Bootstrap
for Hyper-Productive Scrum. In Agile 2009 Conference, pp.69-73
[4] Turecek, T., Smirak, R., Malik, T., Bohacek, P., Energy project story,
from waterfall to distributed Agile. Experience Report, In: XP 2010 [17] Shrinivasavadhani, J., Panicker, V., Remote Mentoring a Distributed
Conference. LNBIP, vol. 48, pp. 362-371 Agile Team. In AGILE 2008, Toronto, pp. 322 - 326
[5] Smirak, R., Koivuluoma, M., Case Study: Orchestrating the Process [18] Taipale, M., Huitale – A Story of a Finnish Lean Startup. In LESS
Development and Governance with IBM(R) Rational(R) Method 2010 conference. LNBIP, vol. 65, pp. 111-114
Composer and IBM Rational Jazz. IBM Rational Software [19] Krebs, W., Turning the Knobs: A Coaching Pattern for XP through
Development Conference, Orlando, 2008. Agile Metrics. In XP/Agile Universe 2002, LNCS 2418, pp. 60–69
[6] Prochazka, J., Smirak, R., Using IBM Jazz in Support of an Agile [20] Sutherland, J., Schoonheim, G., Rijk, M. Fully Distributed Scrum:
Way of Software Development. Orlando, Florida, IBM Rational The Secret Sauce for Hyperproductive Offshored Development
Software Development Conference, Orlando, 2009. Teams. In Agile 2008, Toronto, 2008.