Top Banner

Click here to load reader

Putting the Puzzle Together: Integrating Emerging Best Pracitces

Feb 07, 2017



Lean IT Association

Putting the Puzzle Together: Integrating Best Emerging Practices

Lean IT AssociationExecutive Webinar Series

Welcome everyone to this first LITA Executive Webinar SeriesBut, before we get started, I would like to check if everyone can hear me and see the slides.

Host and Moderator

Deborah BurtonMember Marketing TeamLean IT Association (LITA)

Hello and Welcome! My name is Deborah Burton and I am your host and moderator for today's LITA Executive Webinar. I am pleased to be joined today by Troy DuMoulin

Watch the webinar recordingWebinar Recording30-Minute Practical Use Case: Demonstrating Lean IT Leadership in Action

LITA - Pioneering a Global Standard for Lean IT Education & Certification

Lean IT Association (LITA) is a non-profit organization founded by three Accredited Training Organizations (ATOs) - ITpreneurs, Pink Elephant, Quint Wellington Redwood and three Examination Institutes (EIs) - APMG, EXIN, PEOPLECERT International Ltd. To realize its broader purpose LITA aims to provide:An industry-standard set of Lean IT reference materials and other resources for practitioner organizations to use;An certification scheme aimed at practitioner organizations looking to adopt Lean IT principles in the IT Service development and operations department as well as professionals that want to be certified in Lean IT on various levels.

What Lean IT Will Bring to Organizations?Organizations today need to be in control and optimize their daily business, but additionally they also need to innovate on their business models and technologies. Lean IT offers a strong, well-founded solution for both these challenges. Lean revolves around principles for operational excellence,for customer centricity, for strategy deployment, for management of change and transition, for team and individual behavior and motivation. It's about the value Lean will bring to organizations

These Executive Sessions are targeted to help you better understand the Lean IT Market and go to market quickly.

I am pleased to be joined by our guest presenter Troy DuMoulin.But before, I turn you over to Troy for his presentation, I would like to conduct a quick Poll. Can you let us know the following about yourselves.

I would really appreciate understanding your experience with Lean IT, so have another quick poll question for you.

Featured PresentationPutting the Puzzle Together

Putting the Puzzle Together

Troy DuMoulinVice President of Research and Product Development

Before I hand over the presentation to Troy Let me introduce him to those of you that may not know him.

Troy is a leading ITIL and IT governance authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITILs Planning To Implement IT Service Management and Continual Service Improvement.

Today he will guide your through Lean IT & ITSM to Enable Grass Roots Continual Service Improvement.

Over to you Troy!

The New Mantra Better, Faster, CheaperLean PracticesAgile Software Development & Project Mgmt.DevOps Principles & Practices


ObjectiveUnderstand how the new emerging practices of Lean IT, Agile and DevOps are being adopted to support accelerate and optimize IT Management practices. Agenda


The Risk Gap For Business Growth Goals9

Increasing DemandIncreasing number of products and servicesIncreasing rate of changeIncreasing complexity/data interdependencyIncreased speed and efficiencyIncreased speed to marketReduced costs

IT Process / Data / CapabilitiesSilo / Fragmented Data Sources/redundant processesLack of integration, automationLack of visibility


Operating as a mature IT Service Provider requires managing demand and efficient management processes and data across silos!

Better - Faster - Cheaper Mantra10


(c) Pink Elephant 2013. All rights Reserved.

New Language - New Balance11

11(c) Pink Elephant 2013. All rights Reserved.

The Evolution - The Accelerators12

IT Service Management / SDLC / Project Management

2001 Pink Elephant Inc. All rights reserved.12

Lean - Customer Value At the Center13

Assess if all the activities in the process add value in the eyes of the customer

Create continuous flow in production with the Just-in-Time approach and reduce peak and low volumes

Demand triggers the process chain in order to reduce stock

First time rightFocus on quality and prevention of defects

The book Lean Thinking (Womack & Jones 1996) explains the Lean philosophy using 5 key elements.Identify ValueMap the Value StreamCreate Flow (use the example of the Relay Race focus on the baton not the runner) Continuous flow of the Baton. Every Process has a Work Unit)Initiate Pull (dont start the race until the whistle blows)Pursue Perfection (continually look at removing error from the system)

The 3 Ms Of WasteMuda Unnecessary, Non ValueMura Variation, VarianceMuri Over Burdened



Examples of IT Waste15

Multiple Service Desks all with their own tools and separate processesMassive amounts of wasted server capacity due to a lack of Capacity and Demand ManagementRedundant and duplicate IT Management tools being purchased by various IT departments in the same organizationRedundant IT groups and stealth data centers being built by independent parts of the businessA willingness to solve the same Incidents 1000s of times without looking at the root of the problemMultiple Change Management processes due to political boundariesLosing track of tens of thousands of dollars of IT assets due to poor tracking controls and inventory processesSupplier contracts expiring without knowledge until an Incident occursA willingness to supply multiple/duplicate versions of the same servicesThe loss of massive amounts of business productivity due to Incident tickets which disappear into the IT back office black hole until someone shouts loudly enoughThe total lack of ability to provide visibility into the cost of an IT serviceThe list goes on...

2001 Pink Elephant Inc. All rights reserved.15

Proactive Problem Solving

Reactive vs. Proactive Problem SolvingLean is not just about hunting down waste and reacting to the crisis of the day. Its goal is to move an organization to a desired state through relentless problem solving and incremental improvement.16

What Is Agile?17

Agile (adjective) Able to move quickly and easily; well-coordinated Able to think and understand quickly; able to solve problems and have new ideas

Agile enterprise a fast moving, flexible and robust company capable of rapid response to unexpected challenges, events and opportunitiesAgile software development a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Agile software development methods deliver working software in smaller and more frequent increments.

Key concepts:Mention that the examinable term is Agile software developmentSometimes agile is just a wordTerms such as agile enterprise and agile software development have a specific contextAgile enterprises are built on policies and processes that facilitate speed and changeAgile software development practices are an enabler of DevOpsEmphasize the red text mention that smaller more frequent increments reduce the risks associated with deploying more complex releasesAgile transformations within an organization involve an evolutionJust as you cant implement a framework like ITIL, adopting practices such as Scrum or Kanban does not make an organization agileFor a real transformation to occur, people have to start with where they are and question how things could be improvedNot all proposed solutions will achieve the desired resultsA PDCA approach where once a change is made the results are inspected (checked) is key

Agile Variation18

There are many different Agile Variations

What Is Agile Methodology?

The various agile Scrum methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. Here we have summarized a few of the main agile software development methodology contenders:

Agile Scrum MethodologyScrum is a lightweight agile project management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Scrum has garnered increasing popularity in the agile software development community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

With Scrum methodology, the Product Owner works closely with the team to identify and prioritize system functionality in form of a Product Backlog. The Product Backlog consists of features, bug fixes, non-functional requirements, etc. whatever needs to be done in order to successfully deliver a working software system. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver potentially shippable increments of software during successive Sprints, typically lasting 30 days. Once a Sprints Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of functionality is selected for the next Sprint.

Scrum methodology has been proven to scale to multiple teams across very large organizations with 800+ people. See how VersionOne supports Scrum Sprint Planning by making it easier to manage your Product Backlog.

Lean and Kanban Software DevelopmentLean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the Value Stream, the mechanisms that deliver that Value. The main principles of Lean methodology include:

Eliminating WasteAmplifying LearningDeciding as Late as PossibleDelivering as Fast as PossibleEmpowering the TeamBuilding Integrity InSeeing the Whole

Lean methodology eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being pulled via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.

The Kanban Method is used by organizations to manage the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

Kanban is based on 3 basic principles:Visualize what you do today (workflow): seeing all the items in context of each other can be very informativeLimit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don t start and commit to too much work at onceEnhance flow: when something is finished, the next highest thing from the backlog is pulled into playKanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow. See how VersionOne supports Kanban software development.

Extreme Programming (XP)XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. The original XP recipe is based on four simple values simplicity, communication, feedback, and courage and twelve supporting practices:

Planning GameSmall ReleasesCustomer Acceptance TestsSimple DesignPair ProgrammingTest-Driven DevelopmentRefactoringContinuous IntegrationCollective Code OwnershipCoding StandardsMetaphorSustainable PaceDon Wells has depicted the XP process in a popular diagram.

In XP, the Customer works very closely with the development team to define and prioritize granular units of functionality referred to as User Stories. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

CrystalThe Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project s unique characteristics.Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Alistair Cockburn, the originator of Crystal, has released a book, Crystal Clear: A Human-Powered Methodology for Small Teams.

Dynamic Systems Development Method (DSDM)DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990 s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994 with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile process and iterative software development projects.

DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out fitness for business purpose as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:

M Must have requirementsS Should have if at all possibleC Could have but not criticalW Won t have this time, but potentially later

All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule. The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

Feature-Driven Development (FDD)The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week design by feature, build by feature iterations. The features are small, useful in the eyes of the client results. FDD designs the rest of the development process around feature delivery using the following eight practices:

Domain Object ModelingDeveloping by FeatureComponent/Class OwnershipFeature TeamsInspectionsConfiguration ManagementRegular BuildsVisibility of progress and results

FDD recommends specific programmer practices such as Regular Builds and Component/Class Ownership. FDDs proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work, which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

The notion of Domain Object Modeling is increasingly interesting outside the FDD community, following the success of Eric Evans book Domain-Driven Design.

Agile Vs. WaterfallIts an ongoing debate which methodology for managing software design and development projects is better, agile or waterfall?AgileIterativeIncrementalDecisions are made based on observation and experimentation rather than on detailed upfront planning

WaterfallLinearSequentialPhased approachMove to next phase only when previous phase is complete


Key concepts:Compare and contrast agile and waterfall development practices (note that concepts relative to both are examinable)Emphasize that one of the downsides of waterfall is how long it takes to get feedback

Instructor resource:

19(c) Pink Elephant 2013. All rights Reserved.

Velocity Vs. Agility (Systems Thinking)20

Velocity = Speed With Direction!

Traditional vs. Agile21

21Participant Notes:Working in a traditional manner involves large upfront planning (in an ever changing environment) and investment in an idea on which there is no visibility needed in order to test a hypothesis. Investment is made upfront, while no value is returned to your investor throughout the process of establishing the product. Product development and the underlying investment are based upon a hypothesis. One can set a deadline and an idea, but without feedback from the customer on whether the product/idea is wanted and without feedback from the team regarding how fast the team can deliver, risk remains high throughout the project.

Agile is about using feedback in your product development cycle, be it feedback related to the product, team velocity, budget, situation in the market, or even the situation in the world. This feedback allows the team to swiftly react to any of these topics. When working in an Agile manner, the product is shaped along the way, using feedback from the end-user. It is similar to sketch a painting. One would start with first laying out a sketch, evaluate the outline and maybe adjust the outline along the way. When the contours are to the painters (and customers) liking, the coloring and further detailing of the painting begins. Throughout the process of painting the picture, the painter, learners, and even customers provide feedback to complete the painting to its perfected end-state. Throughout the process, the product itself is accessible to stakeholders.

The Agile way of working has many advantages, some of which are hard to quantify. Topics, such as team dynamics, customer involvement and the feeling of product ownership are not easy to measure. However, from a business point of view, few things can be measured:

Visibility: As the Product Owner and business are involved with product development on a regular basis, for instance by attending the Sprintly demo (or by launching new shippable features on a regular basis), visibility of what to be delivered is far higher than is the case with traditional development methods. Parts of the product are delivered on a regular basis.Risk: Optimization of product visibility lowers the risk, as it becomes clear early in the process whether the team is moving into the right direction and building the right things. It is all about feedback and using this feedback to lower risk.Business Value: By delivering a shippable product at the end of each Sprint, the product can actually be used to generate business value throughout the product development cycle. Features are prevented from getting stuck in the development cycle and are shipped straight away. This approach works in contradiction to the traditional way of working, where the product is shipped only near the end of the project (preventing the team to used valuable feedback from your end-customer through the software development cycle).

From a security perspective, one can imagine that having the ability to deliver in a continuous manner will also have a positive effect on security-related topics, as defects and vulnerabilities will be fixed faster than is the case in a traditional quarterly release cycle. Also, as we are finally building just the functionality that is actually used by the customer, the risk-surface-area (typically the code amounting to functionalities seldom or even never used), will be kept to a minimum. Also, since team members are focused on delivery of a product as opposed to performing activities which in itself have no meaning, the team will work more coherently towards securing quality aspects of the product.

(c) Pink Elephant 2013. All rights Reserved.

SCRUM: Agile Product Development


EstimatesProduct OwnerProduct BacklogTime BoxedSprintsRelease BacklogUser StoriesVelocityBurn Down ChartScrum MasterShip-Ready Feature SetRetrospectiveDaily

Problems Between Dev & Ops23

Instructor Notes:The slide lists some of the problems between the Development and the Operations teams due to the traditional way of developing applications.

Participant Notes:Some of the problems with the traditional Development and Operations teams include:Organizational Silos: The two teams work in isolation and it does not allow them to understand each others problems and perspectives.Different Mindsets: The Development team always wants to incorporate every new technique/feature to do their work efficiently. On the other hand, changes are not at all acceptable by the Operations team because changes results in instability. Therefore, change is the biggest enemy of the Operations team.Different Implementations: The different implementations to perform the same work by the teams results in incompatibility and leads to various bugs in the QA and the Production environments.Different Tools: The different tools used by the two teams lead to various errors and bugs in the Production environment.Lack of Interest in Learning Other Tools: Each team considers its tool or style of working to be the best and does not want to learn a new tool.Different Environments: The different environments, such as Development, Production and Testing, is one of the biggest causes of various errors and bugs raised by the different teams.Loss of Work: The various errors and bugs results in the loss of valuable efforts.Blame Game: A lot of differences between the teams and environments force the teams to pass on the blame of delayed delivery or build rollback on each other.Build Rollback: Many times the builds rollback for various reasons, such as incorrect client requirements, an incorrect database (DB) in the QA or Production environment, incompatible tools and others.Disintegrated Processes: Development processes do not integrate well with operations processes.No Feedback Loop: Lack of a continuous feedback loop in development and operational processes causes gaps.

DevOps Principles - C.A.L.M.S.



Practices of DevOps


ITIL Service Lifecycle Process26

SERVICE DESIGNDesign CoordinationService Level Management Service Catalog ManagementSupplier Management Availability ManagementCapacity Management IT Service Continuity ManagementInformation Security Management

SERVICE TRANSITIONTransition Planning & SupportChange ManagementService Asset & Configuration ManagementRelease & Deployment ManagementService Validation & TestingChange EvaluationKnowledge Management

SERVICE OPERATIONEvent ManagementIncident ManagementRequest FulfillmentProblem Management Access Management

Functions:Service DeskTechnical ManagementApplication ManagementIT Operations Management

SERVICE STRATEGYStrategy Management For IT ServicesService Portfolio ManagementBusiness Relationship ManagementFinancial Management For IT ServicesDemand Management




Or follow us on

Please contact us at or followus on LinkedIn.

Watch the webinar recordingWebinar Recording30-Minute Practical Use Case: Demonstrating Lean IT Leadership in Action

Lean IT AssociationThank You!

Let me thank you all for joining me today.

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.