leveraging tfs for driving process improvement using lean principles

27
Leveraging TFS for Driving Process Improvement using Lean Principles Lean and Agile Learning Network – Chicago April 28, 2015 Chandra Mohan Srini Kadiam

Upload: srini-kadiam

Post on 25-Jan-2017

494 views

Category:

Documents


0 download

TRANSCRIPT

Leveraging TFS for Driving Process Improvement using Lean Principles

Lean and Agile Learning Network – ChicagoApril 28, 2015

Chandra MohanSrini Kadiam

Introductions

Mohan Ganesan- Passionate About

• Process Improvements

• Building Automation Tools to enable Sustainable Process Improvements

Srini Kadiam- Passionate About

• Teams and Building High-Performance Teams

• Agile Engineering & Delivery Practices Adoption

Overview

• Experience report in using TFS to process improvements

• Time period: Jan, 2014 to March, 2015

• Organization: At an organization that provides services to the healthcare providers

Context

- Transitioning to Scaled Agile Framework

- Team size increased by 3 times in 6 to 8 months

- Distributed Teams

- Portfolio and Program Teams in US and Project Teams in India

- Investments in New Products

- Focus on stabilizing the existing Platform

Summary

Problem Statement- No shared understanding of

workflow

- No proper tools to support Agile processes

- Lack of measurement for the Flow

- Release Quality is not great and not consistent

Our Approach- Dedicated ALM Team

- TFS as not only Version Control Tool

- Maximize TFS Usage

- Set up TFS Test Environment

- Collaboration and Training

- Customize TFS to support workflow

- Applying lean and Kanban principles

- Augmenting with custom tool

Applications- Scrum Framework

- Release Workflow

- Business Process Workflow

Lean and Kanban – Guiding Principles

Lean 1 Kanban 2

Eliminate waste Visualize the workflow

Amplify learning Limit Work in Progress (WIP)

Decide as late as possible Manage flow

Deliver as fast as possible Make process policies explicit

Empower the team Improve collaboratively

Build integrity in

See the whole

1. Lean Software Development - http://en.wikipedia.org/wiki/Lean_software_development2. Kanban Development: http://en.wikipedia.org/wiki/Kanban_(development)

Green: Focus Areas

Visualize - SAFe

Visibility at Portfolio and Program Level. Support for SAFe

Visualize Process – ALM, Take 1

• ALM in Kanban board

• Customizable board per team

• Great for small team

• Limited support for complicated workflow

• Limited support for multi-team workflow visualization

• We FAILED

• We pivoted our approach

Visualize Process – ALM Team Collaboration

ALM team Collaborated with ScrumMasters- Workshop for training on TFS- Understand each team’s specific needs- Learning from each other- Requirements for standardized reporting- Empower ScrumMaster as champions for driving improvements- Building the backlog

Standardized Visual Reporting (no customizations)- Blockers / Impediments- WIP / completed tasks- Reporting on daily scrum standup questions

Result- All teams are on the same page- Standardization and removing variances

Visualize Entire ProcessMeeting Operational, Support and other dev teams to

- Understand their workflow- Educate on TFS- Migrated version control to TFS- Created a workflow for their teams

Customize Workflow / Business Process for each team

- Adding custom fields- Explicit policies for each state

We have most of the teams using TFS now

Manage the Flow

Portals For Each Team- Information radiators

- Collaboration and communication

- Brings team together

- Explicit rules for each state

Entire ALM is Managed Through TFS- Real-time data. No emails

- Better metrics

- Team has data and time to make the right decisions

Building on TFS – Bridging the Gap

- Limited and rigid reporting capability in TFS

- Custom Tool to report and automate manual tasks

- Features of this tool• Self-serviced

• Real-time

• All data is from TFS

Benefits – Business Process Automation

- Automated creation of DOD tasks

- Code review reports

- Deployment reports

- Agility reports

- Story life cycle reports - Cycle time between states

- Capacity utilization reports - By developers

- Branch comparison reports

- Post-Release Issues

Improvements – Summary (1)Activity Before After Result

Code reviews Inconsistent Not-verifiable 100% feedback not possible

Real time Verifiable Built into workflow < 5 min to generate

Time Savings Eliminate waste Improved Quality Transparent Accessible to SM

Creating Story Definition of Done Tasks

Manual Inconsistent

Managed by SM < 5mins to generate

Time Savings Eliminate waste Standardization Consistency among teams

TFS Customizations Was not done due to lack of Test Environment

Lack of confidence

TFS Test Environment allowed to test, validate and improve

Build in-house expertise

Rapid customizations Playground for teams to

experiment

DLL Versioning through TFS Build

Basic Configuration is missing Troubleshooting Deployment

issues is not reliable Too many teams are involved in

troubleshooting Lacking in verification step for

deployment validation

DLLs are versions based on the release branch and build number

Easy to troubleshootdeployment issues

Visibility to version info on servers helps to identify potential issues

Improvements – Summary (2)Activity Before After Result

Basic Sprint Reports

Inconsistences among the teams v Consolidated reports are difficult to

create due to variations

Standardized reportsfrom tool

< 5mins to generate

Consistency among teams Variations are eliminated Time Saving

Utilization Reports Inconsistences among the teams in report creation

Incomplete data Unable to complete due to data

limitations

Standardization among teams

Real time < 5mins to generate

resulting in early feedback

Self-service reports. Any one create reports

Better data leads to learning Better resource utilization

usage

Advanced SprintCommitment Reports

Difficulty in creating reports. Each report can take up to 4hours to create manually

Inconsistences among the teams in report creation

Standardization Real time reports < 5mins to create

advanced time

Team members can create these reports leaving Scrum Master focus on helping reams

Reports are self-service. No waiting

QA Story TestingReports

Tracked manually Incorrect and data is prone to errors Too much time to consolidate and report

Tracked within TFS Real time report

Transparency Better change control

documentation Waste eliminated

Improvements – Summary (3)Activity Before After Result

Impediments Tracking Done Manually Lack of visibility

Tracked within TFS Quick removal of impediments Historical data is preserved for further

analysis

Tracking Regression Testing

Done manually Lack of visibility People are waiting for

information

Data is available in TFS Wait time is removed Visibility to all stakeholders

Release Scope Tracking Done in TFS but not reported across all teams

Managed using Excel

Reporting is now based on all teams

Better resource planning for Release Candidate

Better resource planning

Redeployment Requests

Communicated via emails Done via PULL system Reduce the noise Data for further analysis

Redeployment Report Time consuming to create Take up to 4 hours to

create

< 5 min to create Real time

Identify stories which have gap in gap in understanding. Teams can learn from it and improve further

Leading indicators for potential issues. Team can take pro-active steps to mitigate issues

Improvements – Summary (4)Activity Before After Result

Business Approvers Testing and Approval

Done manually via email Approval tracking is time

consuming Takes up to several days for

follow-up and tracking

Tracked via TFS Dashboard < 5 min for status < 15 for follow-up Business Approvers use

PULL system for identifying stories for testing

Early visibility to resources needed Real time data Capturing state changes Conversation and tracking approval

Tracking Post-Releases Tracked in Excel and in Emails

Lack of correlation to actual changes

Tracked in TFS and transparent

< 5mins to generate the post-release issues report

Can be tied to actual changes Valuable information to learn from

and improve upon

Branch Variance Detection

Done manually Done late

Done daily using automated process

Avoiding late code merges Better code quality and prevent

regressions

Single Source of Truth Data is dispersed in too many places

Most of the data is in TFS System behavior can be measure and adjusted

Visibility to the Process Limited visibility to the whole process

Process is not transparent

End to End Release Process is transparent

All other systems have to be configured to use TFS as single source of Truth

Improvements – Summary (5)Activity Before After Result

Alerts on State Changes

Not Available Done via emails

Being piloted in small teams

Real time notifications

Workflow for Operational Teams

Tracked in Excel TFS Workflow being is used

Capacity Planning Transparency Time saving

Portfolio and Program Level Tracking

Done in Manually Tracked used TFS SAFe capabilities

Transparency Real time information

Project Management Tracking

Done in MS Project TFS is being pilot to represent

Saving in license costs Real time integration with work

being done

Release Status Updates

Done in emails No emails. Real time information

Tremendous saving in time. Lot of noise eliminated

Release Go / No GoDecision

Subjective Based on data in TFS Transparent Repeatable

Key TakeawaysProcess alone is not sufficient for improvements

- Augment with tools to measure, learn and improve

TFS can be used- As a process improvement tool. Beyond Version control and Agile PM

- By stakeholders. Beyond Dev Teams. Microsoft has freed licenses to be used stakeholders

- Implement workflow. Business can easily be implemented

Invest in tools- As a learning tool

- Standardize and remove variations

- Self-serving

- Scaling

Setup TFS Test Environment- Learn, Fail-fast and Fail-Safe

Most Important - Put Right People, Connect Passion and Strengths to Organization Goals, Empower, Trust and Support Them

Sample ALM ReportsLean and Agile Learning Network - Chicago

Sprint Story Status Report

• Snapshot of the Stories in any Sprint for any team

• Story Status from different team’s perspective

• Used by Product Leads, Scrum Masters, Team Leaders and other stake holders

• Purpose: Bring visibility to stories that have potential for slippage or not getting into Release

Sprint & Date Story ID and Description Story Points Tags/ Comment Story Owner Dev Story Owner QA Test Case Status Development Status QA Satus PO Story Signoff Story Delivery Date to QA

Story 1 8 N/A Developer 1 N/A N/A In Progress To Do To Do

Sprint 1 - 1/1/2015 Story 2 5 N/A Developer 2 QA 1 Done In Progress To Do N/A

Story 3 8 N/A Developer 3 QA 2 Done In Progress To Do To Do

Story 4 0 N/A N/A N/A N/A N/A N/A N/A

Committed vs Delivered Report

• Committed vs Delivered Report across all the teams

• Purpose: Ease of generation. One report covering all the teams. Consistent way to determine what is “Done” across the teams

Committed Vs Delivered Report

Team Iteration Path Committed Delivered Ratio: Committed Vs Delivered

Team A Release Path 50 50 100

Process Metrics Report

• Summary of # of Stories and Points Completed in a Sprint

Process Metrics Report

Team Sprint Story Committed Story Completed Story Point Committed Velocity Story Spike Story Stretch

Test A Sprint 10 33 9 101 31 2 2

Story Report by Task & HoursSprint High Level Analysis Report

Sprint# StoryId Title Story Points Story CommittedStory Completed Hours Estimated Hours Spent

Deployment (Hrs) Design (Hrs) Development (Hrs) Testing (Hrs) Requirements (Hrs) Documentation (Hrs)

Sprint 12100 Story 1 5 Yes Yes 53 51 0 0 35 16 0 0

101 Story 2 1 Yes Yes 20 20 0 0 5 15 0 0

102 Story 3 1 Yes Yes 14 12 0 0 6 6 0 0

103 Story 4 2 Yes Yes 25 28 0 0 14 14 0 0

• Reporting Tasks and Hours for each story

• Provides insight into story activities and discipline in the delivery

Release Metrics

• Release Status By Team

• Deployment Reports• Readiness by Team

• Completed by Team

• Business Owner Signoff Status

Testing Status Reports

• UAT Testing Status. More of pull model

• Summary of Testing by Teams

• Similar Reports for Business Owner for Sign-offs

• All data is captured