sdec10 lean package implementation

35
Lean Package Implementation Lean/Agile Myth #12

Upload: terry-bunio

Post on 03-Jul-2015

307 views

Category:

Technology


4 download

TRANSCRIPT

Page 1: Sdec10 lean package implementation

Lean Package Implementation

Lean/Agile Myth #12

Page 2: Sdec10 lean package implementation

Lean/Agile Myth #12

• Lean and Agile Methodologies are only applicable for

greenfield opportunities

- Not applicable for brownfield

- Not applicable for Package Integration

- Not applicable for Application Maintenance Services (Yesterday)

Page 3: Sdec10 lean package implementation

Agenda

• What are Package Implementation Projects ?

• How are Package Implementation Project typically

done?

• What aspects of Package Implementation projects could

be done in a Lean Manner?

• Questions

Page 4: Sdec10 lean package implementation

• What are Package Implementation Projects ?

Page 5: Sdec10 lean package implementation

Package Implementation Projects

• Package Implementation Projects are projects that

typically involves a Commercial Off The Shelf(COTS)

product that needs to be integrated into the client

environment.

• These products involve more or less configuration and

customization depending on the product and fit to the

client’s requirements.

Page 6: Sdec10 lean package implementation

Audience Participation

• Question #1 – Why do companies choose COTS

products?

- Time to Market?

- Cost?

- Transfer of Risk?

- Shared Cost of Ownership?

- Available resources/capacity?

- Product fit to Requirements?

- Others?

Page 7: Sdec10 lean package implementation

Reasons for choosing COTS products

• Surprisingly, the two main reasons for selecting COTS

products to address a business problem are:

- Transfer of Risk

- Shared Cost of Ownership

• The one reason which should have greater importance

but usually is not taken into consideration:

- Product Fit to Requirements (read Cost)

- Rule of thumb is that an 80-90% fit is required to make a COTS

implementation cost effective. Otherwise possibly more money

would be spent customizing a COTS package than building new.

Page 8: Sdec10 lean package implementation

• How are Package Implementation Project typically

done?

Page 9: Sdec10 lean package implementation

Application Maintenance Services

Components

Painful Implementation

Painful Testing

Painful Specification

Painful Contracting

Page 10: Sdec10 lean package implementation

Contracting

• This is done is a very adversarial way to try and

anticipate all aspects of the relationship to ensure both

parties are covered.

• The contracts are very detailed and allow for very little

change and modification

• Most of the contract deals with how the companies will

interact and there is little to any mention of the business

problem being solved.

Page 11: Sdec10 lean package implementation

Specification

• Specification follows the contracting process and the

emphasis is to create extremely detailed specification

documents to define all the functionality required.

• Of course there are always items not thought of or not

detailed enough.

• Many time the product rationale is used to defend

functionality. (i.e. that is how the product works) This can

be initially accepted by the business but frequently

requires change later when reality hits.

Page 12: Sdec10 lean package implementation

Testing

• Testing of the COTS application is then problematic and

it builds upon the specification which was built upon the

contract.

• Testing then attempts to verify that the application works

as documented. Lost in this process is whether the

application is actually addressing the business problem.

Page 13: Sdec10 lean package implementation

Implementation

• Implementation is then built upon the testing which was

built upon the specification which was built upon the

contract and the question that is asked at

Implementation is not:

- Does this solve the business problem?

• Rather it is:

- Can you accept this solution and go live?

Page 14: Sdec10 lean package implementation

Where did it all go wrong?

Page 15: Sdec10 lean package implementation

Lean Principles Refresher

• Before we discuss how Package Implementation can be

done in a Lean manner, let’s do a Lean Principles

Refresher

Page 16: Sdec10 lean package implementation

Lean Software Development

• Lean Software development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. In contrast to traditional software development methods, lean developers liaise continuously with business clients.

• Their objective is to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirements in response to evolving business needs.

Page 17: Sdec10 lean package implementation

Lean Software Development

• The most crucial aspect of Lean is the execution of the project in iterations and quick feedback loops possible because of these iterations. It is essential to note that these iterations to not just apply to construction, they also apply to the following tasks: - Project Management and Planning

- Analysis

- Technical Design

- Testing

- Deployment

Page 18: Sdec10 lean package implementation

Lean Software Development

• Iteration planning is ‘the’ key planning initiative

- Iterations need to be planned in conjunction with the client to

accomplish the following:

• Deliver functionality to define the cadence and tempo of the project

• Deliver functionality to deliver real value to the client

• Deliver functionality to reduce and minimize risk for the entire project

• Lessons learned from one iteration must feed into subsequent iterations so

that we don’t execute the project in iterations with similar results, but that we

execute the project in iterations with better results.

- We execute better, smarter, and quicker

Page 19: Sdec10 lean package implementation

Lean Software Development Principles

• Eliminate Waste - The three biggest wastes in software development are:

- Extra Features

- Churn

- Crossing Boundaries

• Build Quality In - If you routinely find defects in your verification process, your process is defective.

- Mistake-Proof Code with Test-Driven Development

- Stop Building Legacy Code

- The Big Bang is Obsolete

Page 20: Sdec10 lean package implementation

Lean Software Development Principles

• Create Knowledge - Planning is useful. Learning is essential.

- Use the Scientific Method

- Standards Exist to be Challenged and Improved

- Predictable Performance is Driven by Feedback

• Defer Commitment - Abolish the idea that it is a good idea to start development with a complete

specification.

- Break Dependencies

- Maintain Options

- Schedule Irreversible Decisions at the Last Responsible Moment

Page 21: Sdec10 lean package implementation

Lean Software Development Principles

• Deliver Fast - Lists and queues are buffers between organizations that simply slow things

down.

- Rapid Delivery, High Quality, and Low Cost are Fully Compatible

- Queuing Theory Applies to Development, not Just Servers

- Limit Work to Capacity

• Respect People - Engaged, thinking people provide the most sustainable competitive advantage.

- Teams Thrive on Pride, Commitment, Trust, and Applause

- Provide Effective Leadership

- Respect Partners

• Optimize the Whole - Brilliant products emerge from a unique combination of opportunity and

technology.

- Focus on the Entire Value Stream

- Deliver a Complete Product

- Measure UP

Page 22: Sdec10 lean package implementation

• What aspects of Package Implementation projects could

be done in a Lean Manner?

Page 23: Sdec10 lean package implementation

Audience Participation

• Question #2 – How could we implement an COTS

application in a Lean Manner?

- Visual Project Management?

• i.e. dashboards/Ticket Boards

- Iterations?

- Requirement Management?

- Implementation?

- Logistics?

- Lean Project Management?

• i.e. Daily Stand ups

Page 24: Sdec10 lean package implementation

Requirements Management

• Requirements Management is key to any successful

project. For Package Implementation projects it becomes

even more important to ensure everyone understands

the requirements.

• Frequently Use Cases are the traditional way of

documenting requirements.

• A much better way of defining requirements are:

- User Stories

- Test Cases

Page 25: Sdec10 lean package implementation

User Stories

• A user story of one or more sentences in the everyday

or business language of the user that captures what the

user wants to achieve.

• They are typically in the following format:

- "As a <role>, I want <goal/desire> so that <benefit>"

• User Stories are much more concise that Use Cases and

provide this extra communication and detail required

when dealing with an external and somewhat unknown

COTS product.

• These User Stories can then be collected together to

define features of the system.

Page 26: Sdec10 lean package implementation

User Stories

• One challenge with User Stories is the ability to

document batch on non end user processes

• Honestly we need to address this on all Lean project

Page 27: Sdec10 lean package implementation

Test Cases

• Traditionally Test Cases are not used for Requirements

Management but rather for the testing process itself.

• Ultimately, there are no better requirements than to list

the test cases that will confirm the requirement has been

met or not met.

• These Test Cases should be defined at the start of the

project and with User Stories will define the system

requirements.

Page 28: Sdec10 lean package implementation

Iterations

• Traditionally, Package Implementations follow a Big

Bang approach. All the functionality is analyzed,

designed, coded, tested, and implemented at once.

• This does not take advantage of one of the main tenets

of Lean to execute better as we progress through the

project.

• It is highly recommended that Package Implementations

also be implemented in iterations. These iterations

should go right through to production.

Page 29: Sdec10 lean package implementation

Iterations

• It is important to remember that these iterations are not

just for development and testing, but for all phases of the

project including testing and implementation.

• Sometimes critical items are left out of iterations like

Reporting and Data Conversion. This is not

recommended. An iteration must be able to stand on it’s

own.

Page 30: Sdec10 lean package implementation

Iteration Schedule

• Agreement on scope and schedule

• Execution of required scope

• Demonstration of iteration scope

- This is more than a simple project led demonstration

- The business execute all of the User Stories and Test cases to

ensure the expected outcome occur

• Feedback is then solicited for new User Stories or test

cases that should be added to future iterations

• Clients are then asked to sign off that iteration

Page 31: Sdec10 lean package implementation

Implementation

• For some unknown reason the bulk of Package

Implementations still implement using the Big Bang

approach

• Very rarely are they implemented using the parallel or

pilot approach

• This adds a great amount of risk to the projects.

Page 32: Sdec10 lean package implementation

Contractual

• Include Contractual incentives

- profit sharing for finishing early

- Cost sharing for finishing late

- Ability and incentive to add additional business value

• Concept of trading User Stories

Page 33: Sdec10 lean package implementation

Logistics

• Lean Software Development recommends having the

project team and business co-located.

• For Package Implementations, I would also recommend

that the vendor should also be co-located.

Page 34: Sdec10 lean package implementation

Conclusion

• The principles of Lean Software Development are

applicable to all types of projects

• They are some areas of Package Implementation

projects that can benefit greatly. These are:

- Requirements Management

- Iterations

- Implementation

- Contractual

- Logistics

Page 35: Sdec10 lean package implementation

Questions?