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: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.orgAbstract— Lean and Agile courses we provided to our unit inNetherlands encouraged our colleagues to start transformation II. TIETO AND OUR TEAMof their business (IT Service provisioning). They decided to Tieto is Scandinavian IT service provider with the mainstart with a distributed pilot project (including Indian delivery focus on Scandinavian and Russian market, having nowsite) and invited us to support the change. In six weeks wemanaged to implement basic Agile practices. This increased close to 17000 employees with up to 4000 in near andmotivation of people for continuous improvement and led to offshore delivery centers in Middle, Eastern Europe andchanges to working, staffing and contract models. This all Asia (India and China). Tieto net sales in 2009 was aroundenabled 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 Leanjob learning by doing with full-time support by skilled coaches) coaches supporting development, support & maintenancebased on principles of Lean Software Development. We and sales teams (focus on the whole value delivery chain) onmeasured 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 solvethe story, the approach (improving the whole value chain problems. Part of this work is also identifying and removingtogether with the customer, following Lean principles, delivery waste. More about our team and work can be foundrespecting natural human behavior) and the challenges. in , , , ,  and . Keywords-component; Agile transformation; business driven III. DUTCH UNIT CHALLENGESpractice; 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 andtransformation of their business (IT Service provisioning). people’s attitude. Dutch attitude is open, straight forwardThey 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. Onesupport the change. In six weeks we managed to implement of the activities building on top of this is regular monthlybasic 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 learntDutch mentality increased the motivation for continuous from their daily work in a few streams. Topics presentedimprovement and led to changes of the whole value chain, during the session we participated covered wide range ofstarting with working and staffing model and ending with themes from Agile experience (presented by us), throughcustomer cooperation and contract model. This all enabled lessons from Indian visit to effective usage and setup ofmore 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 Globalapproach was. It covers mainly the following 3 aspects of Delivery Model (GDM) in selected projects to use skilledAgile and Lean transformation: (1) focus on the whole value but cheaper engineers and also to be still competitive amongdelivery chain improvement, (2) sustainable transition global players. Since the software development model ofapproach 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 phaseapproach. 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
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 waschange 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 andIssues our colleagues experienced were following (source: approaches related to Agile and Lean transformation weinterviews with team members): analysed also similar work and case studies. We investigated • Chaotic communication, mostly visible in context of namely the work of Vilkki , Rico  and Taipale  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® , SEI approach  and Krebs Indians). . 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 , , , , , but had inspired micro-managed Indian colleagues. by Howard  and Shrinivasavadhani  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 , , • Low customer satisfaction with the quality of Howard  and our competitors from WIPRO . 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 fromalso on key aspects and actions driving and contributing to Netherlands unit. Indian colleagues were not involved at thisthe organizational change. Current status of our face to face time. We were asked to conduct Agile Introduction coursementoring process based on our experience consists of four (called What Everybody ought to know aboutphases  ensuring that we focus on right things and Agile/Scrum/XP/Tieto-Agile), Agile workshop for Salescontinue with the cooperation only if necessary and finally Global Delivery Awareness (GDA). Whatpreconditions are satisfied. The phases and their focus are started as standard training sessions very quickly evolved infollowing : 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 standardmentoring approach because of distance and distribution ofthe team and our office. In such cases we usually search forlocal change agent to support the change locally and stay intouch with us. There was none local experienced coacheither in this case. Thus we did thorough analysis of existingapproaches inside and outside our company to follow themost suitable approach fitting existing constraints andconditions. 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-boxdistributed 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 goalmotivation session followed by specific amount of hands-on is important first starting point. If people do not share or do
not see common goal, any next step is useless. Fortunately, We presented Hofstede’s 5D model and explained onthis was not the case and the exercise was just a discussion many examples what do these differences mean in practiceopener and audience synchronization point. Introduction and explained the root cause of issues mentioned abovetraining was very interactive, full of discussions and we had (misunderstandings and late deliveries). GDA became alsoa 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 casestudies (success stories) from our previous involvement.Presented case studies convinced people about possibility ofthe change even in more complex and traditionalenvironment (Energy sector, see ). Next days we continued with Sales workshop withslightly changed audience. Audience shared a story thatopened their eyes recently. They visited customer premisesand saw people doing the job that resulted in huge list ofimprovements (about 90 items). We discussed Go and Seeprinciple more often that day. Another issue uncoveredduring this workshop was whole value delivery streamfocus. People realized that customer involvement was Figure 2. Difference between Dutch and Indian culture according theimportant if they wanted to change their way of working. Hoffstede’s 5D model.Vendor’s role in this case is to conduct training, answerrisen questions and propose solutions. People knew about Part of our involvement during this week was a lot ofdelays caused by waiting for customer approvals for every side discussion with project and department managerssingle document. Of course, one of the problems mentioned regarding the change, our experience, their problems, rootwas how to secure the business. These inputs triggered the causes and solutions. People really cared and tried to getdiscussion about Agile contracts. from us as much information as possible. What was surprising and drive Global DeliveryAwareness (GDA) was no knowledge of cultural differences After the week we returned back to our home office, butin the audience. They experienced many issues with Indian stayed in touch with our colleagues. They informed us aboutcolleagues, but many of them were caused by different the change of way of working in chosen pilot based oncultures, way of thinking and also by not very efficient Agile practices learnt during training sessions. They startedcooperation model (only implementation phase transferred a project kick-off with the whole development teamto India). Typical problems rooted in culture were (1) not including Indian colleagues. The kick-off was led asstated expectations causing clashes and misunderstandings interactive workshop focused on project objectives andand (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
in discussions about solutions and design w which could meetthe 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 hewith some areas due to lack of experi ience with agile practices. Based on our experience we decided to start withtransition. They have realized that the theore etical foundations Iterative development, Two-level planning, Whole teamare not enough when applying in su uch a complex concept and User stories. Thanks to IBM MCIF® approach oenvironment and they also failed with two initial iterations. we could change the practices to contribute to the business cAs 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 oneweek iteration pace, we needed to come up with some eapproach that could serve this reason. We needed to plan, eimplement, measure but also sustain the cha ange in one weekonly. At the same moment we wanted to nurture potentialchange agent that could keep the spin of imp provements. Thiswas the only option from our experience tha could guarantee atthe success of the pilot project. These consttraints required alot 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 , [2 Howard  20],and WIPRO , we came up with the prop posal of the AgileCrash Course – 1 week, intensive in-h house workshopconsisting of facilitation, mentoring and guuiding production Figure 3. Agile dashboard used by team dteam 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 , see Figureteleconference discussions to elaborate more issues e 3). It gave team the opportunity to monitor current status and muncovered during training sessions (to find the root causes), incorporate whole team thinking by assuring that the teams ythese 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 wimplemented. Business driven approach co onnects practices local change agents and proj leader about the plan ojectand business goals ,  and . 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 alkbusiness goal and that we could successfu implement in ully implementing the changes in respected areas. Weone week. Agreed business goals accordin ,  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®  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
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 dayonly overhead meetings in place. All the other actions were video connection) allowed even for informal discussionsimplemented hands-on by performing real tasks in the with remote team-mates. This helped to maintain social andproject. personal relationships established during project kick-off. We also discussed issues perceived by different roles inthe project during that week. Coaching the project manager The key success of the approach was based on manywas 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 thesupport the high speed development when functionality was day, feedback from the team and visible signals ofdeveloped 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 environmenttest all functionalities in the same sprint where they were which are able to take decisions about course ofdeveloped. 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 thepossibly delivered as working part of the solution and brings adoption of the practices ,  and being able tovalue to the customer at the same time) , . Stating change the selected practices (based on theDone-Done attributes was also beneficial for offshore team. experience and real insight) without losing theThis helped to visualize not said assumptions of Dutch team overall high level goal agreed with all stakeholdersto Indian colleagues. (business goals). Very interesting was also the role Functional designer(business consultant). During the sprint, he was the mostactive person describing and explaining to the team the real Iterative Development Resultsneed of the customer and end-user. It was more and more Time-boxedobvious that he has the most detail knowledge and Iterationsunderstanding of the domain from the point of view of user. 5.0Soon enough the team started to understand that he is serving Micro- Working Increments Incrementthe role of Product Owner for the team by spreading the 2.5knowledge about the domain. Thanks for being with theteam he was able to adjust the scope with functionality which Retrospective 0.0 Feedback Usedwould best fit the environment of the customer and whichwould 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 Velocitycontext behind the functionality to offshore team during Prioritizedsprint planning and during sprint itself. He also served as BacklogSingle Point of Contact for local and remote team. Whole team practice was supported by emotional Figure 4. Example of practice adoption measure using business drivenseismograph designed by the team. This visualized the mood approach.of team members in tangible form, so that we were able tosee 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 andimprovement mechanism to achieve sustainability of the hands-on support to non directive coaching style by askingchanges. 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 dueactions with concrete short term solutions resulting in to the team mood, increased motivation and Dutch mentalityimprovement ideas (not just for team’s way of working but we achieved even more. What surprised us was the fact thatalso for the organization). Providing enough responsibility we have achieved that in two week sessions only (set ofand authority to the team (letting them came up with the training sessions, Crash course) and all the journey startedsolutions and actions – so called autonomy ) caused huge only with a motivation of the team to try new approach.motivation boost and resulted in success of the week witheven achieving more than expected. Last day we went D. Effort and Resultsthrough existing issue (unclear value described by user Effort invested in the improvement was not really big. Itstories) to find the root causes (not enough experience and was five man-weeks (three mentors conducting the traininglack of connection between high level functionality sessions in one week, two supporting one week Agile Crash
course) from our side, what is approximately 6000 EUR We measured also practice level implementation toincluding all our travelling costs. Investment from team side ensure that we can achieve stated business goals (Increasewas 30 man-days (ten people participating three days of innovation, Reduce Time-to-Market). The result of Iterativetraining 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 andweek was the introduction and summary meeting (both 30 basically means teams’ independence.minutes), and additional one hours for internal coaches. Allother activities needed for change implementation were partof 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 inmeasures 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 , . Based on these traditional measurements we could state • Focus on value for the customer and closethat the project has failed. But at the same time customer collaboration rather than keeping the contractcould 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 raisechanges required by business. Regular demonstrations awareness, involve also managers to gethelped 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 overcomechanged 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 partThus 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 thesuccess 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 therun 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  help tothe team satisfaction was above 90%. All team members uncover issues and their root causes (face to facementioned this project as the best they have ever worked in. feedback, physical presence, visibility of theStakeholders 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) ,  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.
This change cannot happen and sustain if we do not have  Prochazka, J., Experience From Agile Adoption In Distributedmanagement support and already motivated people (by Environment. In Software Development Conference 2008. VSB-TU Ostrava, pp. 156-163, 2008.mentality and training sessions).  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.  Kroll, P. and Cantor, M., Software and system development with the From the Business perspective was important the IBM Measured Capability Improvement Framework. IBM Rationalconnection of implemented practices with the project white paper. 2009.business goals. Agile practices contribute to business goals  SEI, Goal Driven Software Measurement. CMU/SEI-96-HB-002.of project and also to business goals of the whole 1996.organization.  Poppendieck, M., Poppendieck, T., Leading Lean Software Development. Addison-Wesley, 2009.  Liker, J., The Toyota way. McGraw-Hill, 2003. REFERENCES  Rico, D. F., Lean and Agile Project Management: For Large-Scale Programs and Projects. In LESS 2010 conference. LNBIP, vol. 65, pp. Kroll, P., MacIsaac, B., Agility and Discipline Made Easy: Practices 37-43 from OpenUP and RUP, Addison-Wesley Professional, 2006.  Howard, K., R., The Covert Agilist. In Agile Conference 2009, Poppendieck, M., Poppendieck, T., Implementing Lean Software pp.131-134 Development: From Concept to Cash. Addison-Wesley Professional. Boston. 2006.  Vilkki, K., When agile is not enough. In LESS 2010 conference. LNBIP, vol. 65, pp. 44-47 Prochazka, J., Agile Support and Maintenance of IT Services. In ISD 2010 conference. Prague.  Sutherland, J., Downey, S., Granvik, B., Shock Therapy: A Bootstrap for Hyper-Productive Scrum. In Agile 2009 Conference, pp.69-73 Turecek, T., Smirak, R., Malik, T., Bohacek, P., Energy project story, from waterfall to distributed Agile. Experience Report, In: XP 2010  Shrinivasavadhani, J., Panicker, V., Remote Mentoring a Distributed Conference. LNBIP, vol. 48, pp. 362-371 Agile Team. In AGILE 2008, Toronto, pp. 322 - 326 Smirak, R., Koivuluoma, M., Case Study: Orchestrating the Process  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  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 Prochazka, J., Smirak, R., Using IBM Jazz in Support of an Agile  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.