CHANGE

Having over 150 million subscribers, Guangdong Mobile is one of the largest mobile telecommunication carriers in the world. A dedicated service delivery team from Huawei is located in Guangzhou to serve this client, developing, maintaining and evolving its BOSS system.

Following Huawei's traditional product design and development processes, this team encounters challenges. Having to accommodate to a much shorter delivery cycle in a much more turbulent environment, the team has challenges in quality of services and responsiveness. As a consequence, client satisfaction level is low.

In this report, the current problem is detailed. A thorough analysis is then conducted, covering organisation structure, measurement of operations performance, processes redesign options, and organisational support needed to implement new processes. Based on the analysis, more specific measurement metrics and change items are recommended. A phased action plan is then suggested.

Facing a more turbulent business environment shaped by new information and communication technologies, it is common that organisations find themselves fail to ensure quality of services and responsiveness as their clients requested. This research provides an example how Lean methodologies and techniques can be introduced to an organisation to drive improvements.

Problem Description

As the largest telecommunication equipment and solution provider, Huawei has over 100 thousand employees generating over ￥288 million annual revenue (Huawei.com, 2015). The organisation we are discussing is a service delivery team located in Guangzhou, focusing on development, maintenance and evolving of BOSS (Business Operation Supporting System) for Guangdong Mobile, a mobile telecommunication carrier with over 150 million subscribers. The team consists of about 80 members, most of which are software engineers and quality assurance engineers. A few system engineers and two project managers are facing clients and leading the team.

The service delivery process is a cyclic process. On a monthly base, the Business Support department of Guangdong Mobile collects requirements from all business departments, generates a requirement list, and sends it to the Huawei team, normally to one of project managers. Project managers then pass the requirement list to system engineers to analyse. System engineers analyse the requirements and map them into software development tasks. Those tasks are then passed to software engineers, who make changes to existing features or build new features upon a codebase with about 2 million lines of code. Quality assurance engineers then test the new changes, as well as features potentially affected by them. Once a month, software engineers put all their changes together into a shared codebase, merge all changes, resolve all syntax and function conflicts, double test the whole system, and deploy it to a production environment. By then new and modified features are available to business users of Guangdong Mobile.

There are multiple bottlenecks in this process identified:

System engineers spend days (sometimes even weeks) every month to clarify requirements with clients from Business Support department. Even though, misunderstanding still happens.
Misunderstanding between system engineers and software engineers is common. It often causes rework and delay of delivery.
Workload of quality assurance engineers is high. They must manually test the system multiple times to check if any feature is broken. Quality issues and defects normally are found late and causes hurry rework. It is not uncommon that serious defects are not found until it causes major damage in real production environment.
Apart from all other complaints, the average lead time requires to bring a requirement online is over 2 months. The lack of responsiveness makes it difficult to design innovative business models and packages.

These bottlenecks drive customer satisfaction low and operation cost high. A change plan is needed to improve the performance of the service delivery process.

Solution Analysis

Operations performance can be measured by quality, speed, dependability, flexibility and cost (Slack et al., 2014, p. 46). A change plan is needed to improve all the measurements.

Briefly speaking, the proposed change plan would be based on the current situation of the organisation, focused on improving quality of services and responsiveness. Analysis will be conducted in following aspects:

Organisation summarise. Current organisation structure will be introduced. Major constraints and pain points would be highlighted.
Measurement of operations performance. The first step of analysing a problem is to measure it. Relevant measurements would be examined to expose the problem quantitatively.
Processes redesign. Alternate processes would be considered in light of current situation and gap to the expectation.
Organisational support. Necessary organisational support required to implement the proposed change would be discussed.

Organisation Summarise

The team being discussed is organised as a U-form organisation, in which members are clustered by their functional purposes (Slack, Brandon-Jones & Johnston, 2014, p. 258). There are four groups of software engineers focusing on developing new features and maintaining existing ones, one group of quality assurance engineers testing the system before putting it online on a monthly base, a few system engineers and two project managers are facing clients and leading the team with requirements and plans.

Delivery cycle of this team (monthly) is significantly shorter than typical Huawei product teams (normally 6~12 months), which causes challenges to the team. Communication cost is high, with many misunderstanding and re-work. Software quality decays in such a turbulent environment. Responsiveness is lacking.

Measurement of Operations Performance

A meaningful measurement of operations performance is necessary to identify issues quantitatively and plan improvement correspondingly. Software quality has always been a major measurement of the team's performance. Florac (1992) stated that software quality has significant impact to other aspects of projects, so that simple quality indicators (amount of defects) can be used to manage cost and schedule as well.

In practice, quality is much more complex concept. Jørgensen (1999) pointed out that “high quality” does not only mean good quality factors, but also user satisfaction. Kitchenham and Pfleeger (1996) suggested that software quality can be measured from multiple views, including a user view and a value-based view, which also means quality measurement can have deep implication to overall operations performance.

Another important characteristic of modern IT teams is flexibility. As Roberts, Sarrazin and Sikes (2010) mentioned, IT is expected to be flexible and responsive in the current turbulent business environment. Highsmith (2013) named the ability to be flexible and responsive “adaptiveness”, which values short cycles and change tolerance.

There are external metrics representing operations performance visible to clients, as well as internal metrics representing quality and flexibility in the production processes. External metrics can be used for setting goals, while internal metrics is important for guiding process improvement.

Processes Redesign

Initialled from Japanese manufacturers, Lean is now applied to many other industries for shorter cycles, less waste and better customer experience (Duncan & Ritter, 2014). In IT industry, Poppendieck and Poppendieck (2003) applied Lean principles to software delivery, emphasising iterative delivery, full-stack teams, lightweight but highly collaborative communication approaches. Martin (2003) complemented the concept with further teamwork and technical practices.

The way to plan and control iterative delivery processes is vastly different from how waterfall processes are planned and controlled. Rather than record requirements with heavyweight documentation and try to build a comprehensive plan upfront, “Agile” processes prefer to record requirements with lightweight “user stories” which facilitates communication and collaboration (Cohn, 2004), estimate and plan them iteratively, so that plans are always updated according to latest knowledge (Cohn, 2005). However, such a lightweight planning approach might seem questionable to the client before they get used to it. Popli and Chauhan listed some common challenges of Agile estimation (2012), and proposed solutions to them (2014).

Lean methodologies have always emphasised quality management from its origin. Ōno (1988) introduced quality management principles in Toyota, such as “autonomation” and “get quality right from the first”, which still apply to software delivery processes nowadays. Vingrys (2008) detailed how various types of test can be implemented in Agile processes to ensure quality within software delivery process, rather than having “big bang testing” at the end of delivery process. Based on the existence of automated quality assurance mechanisms in all stages of software delivery, Humble and Farley (2010) proposed Continuous Delivery approach which allows defects be identified as early as possible without needing to cause real damage.

Cockburn (2006) called Agile software development “a cooperative game”, which requires layout adjustment to enable effective cooperation. Hallikainen (2011) suggested a “war room” layout with members seating around a common team table and sharing information via “radiators” such as whiteboards and flip charts. Preuss (2007) made similar suggestions on layout, along with other logistic considerations to build humane workspace. Hansen (2003) summarised place and space patterns of Agile software development facilitation, which are all focused to enable intensive communication and short feedback cycles.

As Hall (2004) recorded, visibility has always been a critical factor in Toyota production system. Visibility ensures common understanding and facilitates cooperation. Osterwalder and Pigneur (2010) introduced “Business Canvas” which can visualise business models when having conversations with clients. Kaner (2014) introduced facilitation techniques which can be used for more effective customer collaboration. Hiranabe (2007) introduced how to apply Kanban (a visual management tool widely used in Toyota factories and 4S stores) into software project management. Sibbet (2011) introduced some other graphic tools which can provide teams a common, visual language for high performance.

Organisational Support

As discussed above, the proposed processes redesign involves change to delivery processes, planning and control, quality management, office layout, and communication approaches. Such a redesign requires organisational support, particularly in human resource strategy and change management.

From a human resource perspective, the organisation needs to shift its focus from short-term delivery to longer-term capability and culture: it needs to emphasise learning and innovation in a long run, in order to provide high value-added service to the client. Watkins and Marsick (1992) introduced a model and design principles for human resource developers to create a learning organisation. Holt, Love and Li (2000) came up to a learning framework for co-operative organisations, which fits the relationship between Huawei and Guangdong Mobile. Xiong (2013) described an “innovation funnel” model which extracts ideas from day-to-day pain points and grow them into meaningful innovations.

When organisational philosophy changes, it is necessary to change the way that employees are motivated, evaluated and rewarded. Pink (2011) pointed out that autonomous, purposeful employees who master their own expertise are indispensable to organisations relying on knowledge work. McHugh, Conboy and Lang (2012) found that trust to team members is a critical enabler of Agile practices. It will be a challenge for this team to encourage autonomy, purpose and mastery before high level human resource strategy of Huawei changes.

All the changes suggested above need to be implemented systematically. Kotter's 8-Step Change Model (Kotter, 1995) is a basic change management framework. Rising and Manns (2004) provided useful techniques for effective change implementation. Both are valuable resource for leaders and consultants to manage changes in this team.

Action Recommendations

Without needing much effort, data from external metrics measuring quality and responsiveness can be collected to demonstrate current status of the organisation.

Amount of defects happened in production can be used to measure quality of software. In the past months before the improvement programme started, the client reported in average 17 production defects every month. In the last month, there happened a critical failure in production system, and this failure directly caused the improvement programme to start.
Lead time of request can be used to measure responsiveness of the software delivery team. In average, lead time to bring a requested feature online is 50 working days. In some cases, the long lead time caused seasonal marketing campaigns (such as a campaign specifically designed for students in Winter holidays) became inviable.

There are main internal metrics can demonstrate process status which have impact to final external result. These metrics are not directly visible, but installing mechanism to measure them is critical to the improvement programme.

Effort needed to make a change. The harder it is to make changes to the system, the more likely to introduce error.
Effort needed to uncover a defect. The harder it is to uncover defects, the more likely they are left to production.
Rework. The more rework, the less responsive.
Inventory. The more work in progress (WIP), the less responsive.

According to previous analysis, following change items are recommended, which presumably will have impact to these measurements:

Automate software building process, which allows frequent build of the system, and prevents human failures in building process from happening (Ciordia, 2004).
Create automated test suites which uncovers defects if they break existing features (Crispin & Gregory, 2009).
Establish continuous integration pipeline to provide instant feedback regarding quality (Duvall, Matyas & Glover, 2007).
Manage infrastructure as code, to automate environment provisioning and software deployment processes, and eliminate human failures in deployment processes (Hüttermann, 2012).
Introduce Test Driven Development to ensure new features and modifications are covered by automated test cases (Beck, 2003).
Perform prioritisation with clients, to ensure delivery plans align with business priorities.
Manage project with Kanban techniques to increase visibility and eliminate waste (Hiranabe, 2007).
Introduce SCRUM practices to enhance teamwork and enable continuous improvement (Kniberg, 2007).
Introduce visualisation techniques to improve communication internally and externally (Sibbet, 2011).

Presumably, the recommended change items would have impact to main internal metrics:

	Effort needed to make a change	Effort needed to uncover a defect	Rework	Inventory
Automated building process	√	√	√
Automated test	√	√	√
Continuous Integration	√	√
Infrastructure as code	√		√
Test Driven Development		√
Prioritisation				√
Kanban			√	√
SCRUM			√	√
Visualisation			√	√

Table 1: Impact of change items to internal metrics (“√” means “can cause significant improvement to”)

By implementing recommended change items, it is expected to achieve following results:

· Reduce production error to less than 5 every month.

· Eliminate critical failure in production.

· Reduce average lead time of new feature to 15 working days.

· Reduce average lead time of urgent request to 10 working days.

Furthermore, the organisation should consider building Lean thinking into its culture, continuously improve its processes to shorten lead time and reduce waste (Womack & Jones, 2010).

Action Plan

Based on the analysis in previous sections, the Huawei service delivery team located in Guangzhou is facing challenges from a turbulent environment. Operations improvement is needed for this organisation to offer better quality of service and responsiveness.

An action plan is proposed based on Kotter's 8-Step Change Model (Kotter, 1995). In brief, the proposed operations improvement needs to be done in 3 main phases (Webster, 2012):

Phase 1: Creating a Climate for Change. Urgency of change needs to be called out. A guiding team needs to be built. A clear vision needs to be composed.
Phase 2: Engaging and Enabling the Organisation. The vision of change needs to be communicated to all stakeholders. A pilot team needs to be empowered to implement changes. Short-term wins need to be achieved and broadcasted.
Phase 3: Implementing and Sustaining Change. Changes proven in pilot team need to be implemented in the whole organisation as instituted processes and practices. Corporate culture and human resource philosophy needs to be changed to enable long-term and sustainable change.

The action plan is to be detailed in following sections.

Create Urgency

Urgency of change can be called out with an external perspective. Negative feedback from customers and non-optimistic monetary result are both clear signs of low quality of service (Kitchenham & Pfleeger, 1996). As an industrial trend, the need for flexibility and responsiveness becomes an imperative to IT companies (Roberts, Sarrazin & Sikes, 2010). As a first step to create urgency, leaders of the organisation need to share these context to all employees.

With help of consultants, detailed internal metrics to measure quality and responsiveness can be designed and installed in the current processes to generate internal, quantitative indicators (Zhang, 2013), which create continuous urgency during the whole change process.

Form a Powerful Coalition

Support of leaders is critical to change implementation. The “Operations Improvement Committee” needs to be headed by department manager, the top management of this team. Leaders of all functions, as well as core members of pilot team, are also members of the committee. The committee should also include “evangelists” who support Lean/Agile autonomously, and “gurus” who know best of the context (Rising & Manns, 2004). With such an arrangement, the pilot team can get support from the whole organisation.

There are remote managers who are less interested to the details of change, but have high power to impact the change. The committee needs to ensure these stakeholders are kept satisfied (Mendelow, 1987).

Consultants should play facilitators and coaches in the committee. They need to enable the committee (and other members of the organisation) to make changes happen, rather than implement changes by themselves.

Create a Vision for Change

In order to shorten cycle time, reduce waste and improve customer experience, Lean methodology will be applied to the organisation (Duncan & Ritter, 2014). More specifically, iterative delivery, full-stack teams, and highly collaborative communication approaches (Poppendieck & Poppendieck, 2003) will be implemented in the organisation – firstly starting from a pilot team, then spread to other teams.

Unlike traditional strategic visions in Huawei (which normally are written in sophisticated text), the vision of change programme needs to be expressed in a way more intuitive and easy to understand. Tools such as Elevator Pitch (Parsons, 2012) and Business Model Canvas (Osterwalder & Pigneur, 2010) should be used for discussing, documenting, and communicating of the vision.

Communicate the Vision

Vision of change needs to be announced in a meeting involving all employees. However, “communicating the vision” is much more than that. The vision needs to be elaborated in detail and communicated through the formal management structure. The improvement committee needs to facilitate these communication and provide content for them.

Trainings are necessary for employees to understand the upcoming change. In order to minimise impact to people's workload and to create a collaborative atmosphere, informal training sessions such as “Brown Bag” learning lunches (Rising & Manns, 2004) are preferable.

For important individuals, including a lead system engineer, technical leads, a few other impactful employees, and a few resisters, one on one conversations are needed to ensure their support to the change programme.

Leaders need to lead by example (Gardner et al., 2005). The committee should manage change initiatives using Lean tools such as Kanban and Value Stream Mapping, to show the team that these new concepts can really benefit their daily work.

Remove Obstacles

New processes and practices will be proven in a pilot team before being spread to the whole team. Potential obstacles can be identified and removed in pilot phase. Based on previous experience of organisational change, potential obstacles are:

Clients are not collaborative. Lean processes require quick and frequent feedback from the clients, which might be seen as a burden at the beginning.
Employees are not engaged. Adopting new processes and new practices require significant learning. Employees might resist change because it takes effort and incurs uncertainty.
Technical challenges. Various software delivery tasks, especially quality assurance activities and infrastructure management activities, need to be automated to enable short feedback cycles. Necessary expertise of automation is lack in the current team.

Leaders need convince clients and employees to “give it a try”, and introduce external expertise on Continuous Delivery (Humble & Farley, 2010) to overcome technical challenges.

Create Short-Term Wins

Among all potential change initiatives, three of them should be done at first to gain quick wins, and establish a foundation for further change initiatives:

Automate quality assurance activities, especially functional tests, to reduce effort spent on manual test and amount of defects.
Introduce visual tools (Sibbet, 2011) and facilitation skills (Kaner, 2014) into discussion with clients, to build common understanding and trust.
Prioritise requirements together with clients. Plan and manage iterative delivery using Kanban (Hiranabe, 2007), to shorten delivery cycle and enhance visibility.

With help of external consultants, some “quick wins” can be get in 1~3 months. The change programme per se can be also managed in an iterative manner. Showcases and retrospectives need to be held after each fortnightly iteration, to build confidence and make necessary adjustments. Both achievements and failures should be celebrated, because the team can learn from both.

Build on the Change

When short-term quick wins are achieved in pilot team, proven practices then should be spread to the whole organisation. Systematic training on Agile and Lean should be given to all employees. New processes and practices should be institutionalised. Visual posters and other information radiators (Cockburn, 2008) should be designed to emphasise these new processes and practices in an intuitive manner.

Meanwhile, improvement to the processes and practices should be still encouraged. Gemba Kaizen – means “continuous improvement on the field” (Imai, 1997) – should be introduced. Long term change goals and milestones should be set. Improvement management approaches such as A3 thinking and PDCA (Sobek II & Smalley, 2011) should be used as regular management tools.

Anchor the Changes

It normally takes 12 months or longer to shift such a delivery team from traditional “waterfall” processes to Agile/Lean processes. While changes are happening, the improvement committee need start changing the culture of the organisation, as well as people's mindset.

For all members in the organisation, they must realise that today's organisations have to be open to continuous innovation, and change happens in all different angles – not only in technology and product, but also in organisational structure and people (Daft, 2012, p. 432). An innovative organisation needs to be built, in which pain points are recognised as sources of innovation, and “mad ideas” are nurtured into meaningful innovation (Xiong, 2013).

Performance assessment criteria should be changed to award innovative change makers, rather than risk averters. It takes at least 2~3 years to change the organisational culture, and support from higher level executives is necessary.

References

Beck, K. (2003). Test-driven development: by example. Addison-Wesley Professional.

Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Pearson Education.

Ciordia, I. (2004). Ant: automating the process of building applications. IEEE software, (6), 89-91.

Cockburn, A. (2006). Agile software development: the cooperative game. Pearson Education.

Cockburn, A. (2008). Information radiator. [online] Alistair.cockburn.us. Available at: http://alistair.cockburn.us/Information+radiator [Accessed 29 Jun. 2015].

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.

Cohn, M. (2005). Agile estimating and planning. Pearson Education.

Daft, R. L. (2012). Organization Theory and Design, 11th Edition [VitalSource Bookshelf version]. Retrieved from http://online.vitalsource.com/books/9781285011707

Duncan, E., & Ritter, R. (2014). Next frontiers for lean. McKinsey Quarterly, 2, 82-89.

Duvall, P. M., Matyas, S., & Glover, A. (2007). Continuous integration: improving software quality and reducing risk. Pearson Education.

Florac, W. A. (1992). Software quality measurement: A framework for counting problems and defects (No. CMU/SEI-92-TR-22). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.

Gardner, W.L., Avolio, B.J., Luthans, F., May, D.R. and Walumbwa, F. (2005) ‘Can you see the real me? A self-based model of authentic leader and follower development’, Leadership Quarterly, 16 (3): 343–72.

Hall, R. (2004). Lean and the Toyota production system. Target, 20(3), 22-7.

Hallikainen, M. (2011). Experiences on agile seating, facilities and solutions: multisite environment. In Global Software Engineering (ICGSE), 2011 6th IEEE International Conference on (pp. 119-123). IEEE.

Hansen, K. M. (2003). Agile Environments–Some Patterns for Agile Software Development Facilitation. In First Nordic Conference on Pattern Languages of Programs (p. 259).

Highsmith, J. (2013). Adaptive software development: a collaborative approach to managing complex systems. Addison-Wesley.

Hiranabe, K. (2007). Visualizing Agile Projects using Kanban Boards. [online] InfoQ. Available at: http://www.infoq.com/articles/agile-kanban-boards [Accessed 12 Jun. 2015].

Holt, G. D., Love, P. E., & Li, H. (2000). The learning organisation: toward a paradigm for mutually beneficial strategic construction alliances. International journal of project management, 18(6), 415-421.

Huawei.com, (2015). Annual Report 2014. [online] Available at: http://www.huawei.com/en/about-huawei/corporate-info/annual-report/2014/index.htm [Accessed 31 May 2015].

Humble, J., & Farley, D. (2010). Continuous delivery: reliable software releases through build, test, and deployment automation. Pearson Education.

Hüttermann, M. (2012). Infrastructure as Code. In DevOps for Developers (pp. 135-156). Apress.

Imai, M. (1997). Gemba Kaizen: A Commonsense, Low-Cost Approach to Management. McGraw Hill Professional.

Jørgensen, M. (1999). Software quality measurement. Advances in engineering software, 30(12), 907-912.

Kaner, S. (2014). Facilitator's guide to participatory decision-making. John Wiley & Sons.

Kitchenham, B., & Pfleeger, S. L. (1996). Software quality: The elusive target. IEEE software, (1), 12-21.

Kniberg, H. (2007). Scrum and XP from the Trenches: How we do Scrum. Lulu. com.

Kotter, J. P. (1995). Leading change: Why transformation efforts fail. Harvard business review, 73(2), 59-67.

Martin, R. C. (2003). Agile software development: principles, patterns, and practices. Prentice Hall PTR.

McHugh, O., Conboy, K., & Lang, M. (2012). Agile practices: The impact on trust in software project teams. Software, IEEE, 29(3), 71-76.

Mendelow, A. L. (1987). Stakeholder analysis for strategic planning and implementation. Strategic planning and management handbook, 176-191.

Ōno, T. (1988). Toyota production system: beyond large-scale production. Productivity press.

Osterwalder, A., & Pigneur, Y. (2010). Business model generation: a handbook for visionaries, game changers, and challengers. John Wiley & Sons.

Parsons, N. (2012). The 7 Key Components of a Perfect Elevator Pitch. [online] Bplans Blog. Available at: http://articles.bplans.com/the-7-key-components-of-a-perfect-elevator-pitch/ [Accessed 26 Jun. 2015].

Pink, D. H. (2011). Drive: The surprising truth about what motivates us. Penguin.

Popli, R., & Chauhan, N. (2012). Research Challenges of Agile Estimation. Journal of Intelligent Computing and Applications (July-Dec 2012).

Popli, R., & Chauhan, N. (2014). Cost and effort estimation in agile software development. In Optimization, Reliability, and Information Technology (ICROIT), 2014 International Conference on (pp. 57-61). IEEE.

Poppendieck, M., & Poppendieck, T. (2003). Lean software development: an agile toolkit. Addison-Wesley Professional.

Preuss, D. (2007). Designing Collaborative Spaces for Productivity. [online] InfoQ. Available at: http://www.infoq.com/articles/agile-team-room-wishlist [Accessed 12 Jun. 2015].

Rising, L., & Manns, M. L. (2004). Fearless change: patterns for introducing new ideas. Pearson Education.

Roberts, R., Sarrazin, H., & Sikes, J. (2010). Reshaping IT management for turbulent times. McKinsey Quarterly, December.

Sibbet, D. (2011). Visual Teams: Graphic Tools for Commitment, Innovation, and High Performance. John Wiley & Sons.

Slack, N., Brandon-Jones, A., Johnston, R. (2014). Operations Management, 7th Edition [VitalSource Bookshelf version]. Retrieved from http://online.vitalsource.com/books/9781269887137

Sobek II, D. K., & Smalley, A. (2011). Understanding A3 thinking: a critical component of Toyota's PDCA management system. CRC Press.

Vingrys, K. (2008). Agile vs. Waterfall Testing for Enterprise Web Apps. In: ThoughtWorks Inc. (ed.), ThoughtWorks Anthology, 1st ed. Pragmatic Bookshelf.

Watkins, K. E., & Marsick, V. J. (1992). Building the learning organisation: a new role for human resource developers. Studies in continuing education, 14(2), 115-129.

Webster, M. (2012). Successful Change Management — Kotter’s 8-Step Change Model. [online] Leadership Thoughts. Available at: http://www.leadershipthoughts.com/kotters-8-step-change-model/ [Accessed 26 Jun. 2015].

Womack, J. P., & Jones, D. T. (2010). Lean thinking: banish waste and create wealth in your corporation. Simon and Schuster.

Xiong, J. (2013). Building Innovative Organizations with Lean Thinking. [online] InfoQ. Available at: http://www.infoq.com/articles/building-innovative-organisations [Accessed 12 Jun. 2015].

Zhang, S. (2013). Lean Software Measurement: Observation and thinking of practitioners. Beijing: Posts & Telecom Press.

Business Articles

Search This Blog

Saturday, February 13, 2016

Implementing Lean in a Software Services Organization

CHANGE

FOR

QUALITY AND AGILITY

Implementing Lean In A Software Services Organisation

Table of Contents

Executive Summary