Level

Practices Team collaboratively builds business domain model 1

NO Project Scope broken down into small functional Unit (User 1 Story) YES 1 User stories are fundamental unit of work used for planning YES User stories are fundamental unit of work used for project 1 progress tracking YES 1 User stories are fundamental unit of scheduling of work Team re-structures user stories into bussiness User 1 Scenarios YES NO

NO YES YES YES YES NO

Team has example of test data for each of the Business User 1 Scenarios NO If multiple teams are working on a single product, the work is organized according to business function rather 1 technology. YES Teams treat their Users/Business as a consumer--they solicit stories/requirement from customers and deliver software to them, but they don't involve their customers much more 1 than that. YES 1 Use Kanban to visulize the flow of Stories/work unit The team works collaboratively, making each other accountable, reducing misunderstanding and hand-off 1 delays. Project Managements knows when the team is building the wrong thing, or isnt making progress, and has the ability to 1 positively intervene. Teams regularly report what theyre working on and how its progressing from a business value perspective. 1 Is the team competent at quickly creating low and high1 fidelity prototypes to validate the solution feasibility? Is Release planning a joint effort between the product 1 manager/owner and the Team? Functional Unit grouped into Business Value Themes agreed by Stake holders 1 Stake Holders get Weekly status based on % functional unit progress for each Business Value Themes 1 Stake Holders redirects the Team if they find out team is not working on Top Prioroty Business Value Theme 1 YES

NO

YES

YES YES

YES

YES

Dont Know

YES

YES

YES

Dont Know NO

Dont Know YES

NO

NO

NO

NO

NO

NO

Team and Business/Users break down the project scope into many small releases based on business/market priority 2 Team models Functional Architecture which drives the Technical architecture NO YES

2 Team models non-functional requirement as user story in 2 the Product Baklog 2 Team keep track of Defect density Team has road-map to achieve testable architecture which would enable to put in place Automated Unit Test

NO

NO

NO NO

NO NO

NO

NO

Team has road-map to achieve testable architecture which would enable to put in place Automated Functional test (end 2 to end System testing) NO Team has road-map to achieve testable architecture which 2 would enable to put in place Automated Integration Test NO (Subsystem testing) Team has put in place continous integration with automated 2 build/deployment and test suit NO Team is able to replicate environment in automated matter 2 Teams produce very low-defect software and keep technical debt to a minimum, allowing them to have more time for 2 delivering features. NO Developers machines has isolated development environment (by stubbing the dependency)to get feedback 2 of feature developed or defect fix NO Developers machines can run automted sub-system test 2 cases NO Does the team assess potential customer impact prior to release, and do they work with product marketing or others 2 to communicate key changes? Dont Know

NO NO NO

NO

NO NO

Dont Know

Does team monitors time needed to run a full regression suite and determine if they can "release with confidence"? 2 3 Strong product manager/owner is full-time team member Product manager/Owner understand who the key stakeholders in the company are, and what their concerns 3 are Is the team skilled at using MVP(Minimum Viable Product) 3 testing techniques to validate quickly? Team have clearly defined business KPI's that they are 3 driving towards and measured against? NO NO

NO NO NO

NO NO NO NO

Do the team keep track of the percentage of the ideas killed 3 each week in discovery? NO Based on the business metrics the team will generate alternative options to the business when they discover current direction its not producing enough value 3 NO Team validats ideas each week with actual users (before 3 they get too attached to the ideas NO Team validates ideas each week with business stakeholders 3 (before actually building)? NO Team competent at quickly creating low and high-fidelity 3 user prototypes? NO Does the team understand the difference between live-data prototypes and building production software 3 NO Does the team have an Live data testing infrastructure in 3 place? NO Is there some amount of real work put on the product 3 backlog every week NO Do all of the other developers and testers on the team feel able to contribute product ideas in discovery and share in 3 the learnings? NO At the end each week does the discovery team do a miniretrospective asking if they could have validated the solution feasibility ideas faster or cheaper? 3 NO At the end each week does the discovery team do a miniretrospective asking if they could have validated any of these 3 ideas faster or cheaper NO Is the team immediately reviewing the newly released software to evaluate how they impacted the scorecard KPIs 3 NO Are impediments identified and especially resolved quickly 3 (typically within 48 hours)? NO

NO NO NO NO

NO NO NO

NO

NO

NO

NO NO

Technique FDD/UML domain modelling User Story Planning Visualize work User Centered work breakdown Story Mapping workshop

NO YES YES YES YES NO

NO YES YES YES YES NO

NO YES YES YES YES NO

NO

NO

NO

Specification by Example User Centered work breakdown design

YES

YES

YES

YES YES

YES YES

YES YES

Short Validated learning loop Visualize work flow Daily/Regular standup meeting

YES

NA

NO

YES

YES

Dont Know

Information Radiator

YES

NA

NA

Iteration Review

Dont Know NO

YES NO

Dont Know

NO

NO

NO

NO

NO

NO

Spikes Requirement Workshop Business Value Centered Feature clustering Business Value Centered Feature clustering

NO

NO

NO

NO

NA

NO

Story Maps Use Case Driven Approach

NO

YES

NO

NO NO

NO NO

NO NO Techniques documented in the book "Working Effectively with Legacy Code"

NO

NO

NO

NO NO NO

NA YES NO

NA

NO

NO

NO

NO

NO NO

NO NO

NO NO

Dont Know

NA

Dont Know

NO

NO

NO

NO NO NO NO

NO NO NO NO

NO NO NO NO

NO NO NO NO

NO NO NO NO

NO NO NO NO

NO NO NO

NO NO NO

NO NO NO

NO

NO

NO

NO

NO

NO

NO

NO

NO

NO NO

NO NO

NO NO

Artifact UML domain/Entity model

Backlog Project Data Sheet Greenhopper Greenhopper Story Maps

Document that captures example as Specification

Greenhopper

Greenhopper

Greenhopper

Iteration Review card

Backlog

FDD Parking Lot Diagrams

FDD Parking Lot Diagrams part of weekly status report

FDD Parking Lot Diagrams part of weekly status report

Minimum Markateble Feature document documented in Project Datasheet Architecture documents to have this sections: Describes an architecture with three zones with dependencies going only one way, from the volatile parts towards the more stable parts: 1 - A Domain Model with the core business rules, the most stable and important part for the business, not depending on anything else. 2- Application Services for the use cases of the system which uses, and depends on, the domain model. 3- External Details, database, user interface, network, etc., that are less relevant for the business model. The most volatile part and depending on the other two.

Backlog modified to accommodate non-functional stories Defect Density part of QMS Road Map document based on row 21 and "Working Effectively with Legacy Code"

24 24 Build Scripts, Deployment Scripts and Automated Sub-system Test Scripts Integrated with Continous Integration tool Integrate Environment Set-up with Deployment Script

Integrate CodeCity tool to show Technical Debt Metrics

Stubs, Test Double to isolate external dependency 24

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle 1 week to 4 weeks "Build, Code, Measure, Data, Learn" cycle

FDD

Level

Benefit 1 Greater visibility into teams work; ability to redirect. Build data for forcasting estimates. Cut down communication overhead throughout project life cycle among team members. Establish shared language on the requirement therefore reducing defects due to misunderstanding of reqt read/understand info and redirect priority items

Investment Team development and work process design. Setting-up team protocols (e.g., exit/entry for hand-off of work) and work flow; acceptance test scenario in user reqmt doc, prioritized accdg to business value

2 Reduce deployment cost. Lowered productivity during Low defects in SIT, UAT and PRD technical skill development. and high productivity primarily by reducing and managing technical Infrastructure cost complexity arising from addition of features to existing system.

3 Higher value deliveries and better Social capital expended on product decisions. incorporating business expertise into team.

Assumptions/Limitations/Risks 1 wk - requirement analysis/breakdown into user stories can be achieved with existing analysis skills

Core Metric Team regularly reports progress from a business value perspective.

Time to achieve 2-6 months

new skills to be learned on: Team ships on market cadence.i.e. continuous integration, shipping the release at the rate market decomposing technical architecture will accept it. into decoupled functional architecture (functional subsystem). acceptance test-driven development, automated testing (unit/subsystem/end-to-end) independent/isolated DEV envt needed to lower debugging and defect fix turn around time

3-24 months

business commitment and Team provides concrete business metrics. 1-5 years involvement in brainstorming requirement feasibility in an iterative way together with project team end-to-end

Notes quantifiable benefits; more specific examples of activities to support investment required (existing activities working well and to be continued + new activities proposed) eReporting - 3 part-time days to breakdown reqts into user stories and set-up of JIRA workflow with resource having sufficient analysis skills and not necessarily w/ agile skills levels 1/2 are driven by agile practices but not fully implementing agile; level 3 can enable full implementation deliverables would need to further assessed for cmmi compliance need to factor-in buffer for learning curve in estimating model to incorporate agile techniques decoupling done so sub-system is established and automation can proceed as next step