agile business transformation

0 © Copyright 2014 Enfocus Solutions Inc. All Rights Reserved.

Title Here

John Parker, CEO Enfocus Solu5ons Inc.

Agile Business Transformation

May 15, 2014

http://EnfocusSolutions.com


Agenda •  Agile Transforma5on Challenges •  Scaled Agile Framework •  Business and SoAware Agility •  Transforming the PMO •  Stakeholder Engagement and

Collabora5on •  Discovery and Valida5on •  Business Change Management •  Agile PorIolio Management •  Agile Program Management •  Agile Team Management

•  Product Managers •  PMOs •  Organiza5onal Change Managers •  Project Managers •  PorIolio Mangers •  Product Owners •  Agile Teams

Audience

Agile Transformation


John E. Parker •  Chief Executive Officer of Enfocus Solutions Inc. •  Previous Positions

o  Chief Visionary Officer of Enfocus Solutions Inc o  EVP and CTO, MAXIMUS Inc. o  Outsourced CIO for HSHS (Large Healthcare System) o  EVP and Cofounder, Spectrum Consulting Group o  KPMG Partner

•  Expertise o  IT Strategic Planning o  Agile Development using Scrum and Kanban o  Agile Portfolio and Program Management o  Business Analysis o  Recovering Troubled and Challenged Projects o  Enterprise and Business Architecture o  Business Process Improvement, Reengineering, and

Management

Contact: •  http://enfocussolutions.com •  [email protected]


Why Agile?

•  The agile process is the universal remedy for software development project failure.

•  The secret is the trial and error and delivery of the iterative process. •  Software should be built in small, iterative steps with small, focused teams. •  The project team delivers functionality in small bites or steppingstones.

SoAware applica5ons developed through the agile process have three &mes the success rate of the tradi5onal waterfall method and a much lower percentage of &me and cost overruns.

Source: Standish Chaos Report 2011


Ken Schwaber is a so/ware developer, product manager and industry consultant. Ken worked with Jeff Sutherland to formulate the ini?al versions of the Scrum development process.


The Scaled Agile Framework (SAFe)

“The Scaled Agile Framework is a proven, publicly-‐facing framework for applying Lean and Agile prac?ces at enterprise scale”

•  The Scaled Agile Framework is well defined in books and on the web

• Works well with mul5ple teams in IT organiza5ons of 50 or more people

•  Has been scaled to hundreds of teams and thousands of people

•  Synchronizes vision, planning, interdependencies, and delivery of many teams


Scaled Agile Framework™ Big Picture


So7ware Agility does not equal Business Agility


What is Business Agility?

Agility is the ability of a business to react quickly to change. •  Quickly sensing problems and

opportunities and

•  Rapidly responding with Solutions that address business and customer needs

•  By efficiently changing processes, responsibilities, rules, data, and technology,

•  To Realize expected business and customer outcomes.


Business and Software Agility

Agile Por>olio Management

Agile Program Management

Agile Team Management

Stakeholder Engagement and Collabora&on

Business Change Management

Business Agility

So7ware Agility

Stories Sprints

Features Releases

Epics Outcomes

Impacts

Stakeholders

Discovery and Valida&on Features


Transforming Project Management to Agile


State of PMOs: It is Time for a Change

•  Most companies with high utilization of PMOs see materially higher IT costs while also failing to deliver projects with higher ROI or better on-time and on-budget performance. (Hackett Group Report, November 2013)

•  Since 2008, the correlated PMO implementation failure rate is over 50% (Gartner Project Manager 2014)

•  50% of project management offices close within 3 years (Association for Project Management)

•  Only a third of all projects were successfully completed on time and on budget over the past year (Standish Group’s CHAOS report)

•  68% of stakeholders perceive their PMOs to be bureaucratic (2013 Gartner PPM Summit)

•  Only 40% of projects met schedule, budget and quality goals (IBM Change Management Survey of 1,500 execs)


The Old Way The New Way Managing tasks and adhering to a rigid plan. Managing a value stream focusing on customer

engagement and sa5sfac5on.

Tight change management and control over amendments to the plan.

An5cipa5ng change and accommoda5ng changes as business needs change

Breaking down the project into phases, tasks, and steps

Breaking down the project into independent components called Features that can be built and delivered quickly.

Project success was determined based on whether the project was delivered on 5me and on budget.

Project success is determined based on achieving desired business and customer outcomes.

Focus was on managing tasks and resources. Focus is on managing collabora5on between team resources and stakeholders to achieve agreed upon objec5ves.

Focus is on tracking costs, 5me, and tasks. Focus is on maximizing the delivery of business value more quickly.

Transform the PMO from Bureaucracy to Key Enabler of Agile and Business Value


Manage Data Not Paper •  Collocation of Teams is very important for Agile;

however collocation of business stakeholders and users is simply not practical.

•  When agile scales, the amount of interaction between teams and other stakeholders grows exponentially creating significant challenges for organizations.

•  Paper documentation is anti-agile; distribution and version control of paper documents is burdensome and slow.

•  As organizations scale, they will need an automated collaboration and knowledge repository to manage the various enterprise components of Agile such as:

o  Portfolio and Program Backlogs o  Feature discovery and validation information o  Conversation between developers and users o  Inspect and Adapt information o  Impacts of changes in business strategy


•  Achieved a 55% ROI •  Increased production throughput by 26% •  Consolidated applications from 29 to 11 •  Achieved a total savings of $14 million in 9 months

Business Outcomes

Project Managers must focus on Delivering Business Outcomes instead of Managing Tasks.

The Triple Constraints of On-‐Time, On-‐Budget, and On-‐Scope goes away with Agile.


Business and Software Agility






Business Agility

So7ware Agility

Stories Sprints

Features Releases

Epics Outcomes

Impacts

Stakeholders

Discovery and Valida&on Features



Lack of User

Involvement is

#1 Cause of

Project Failu

re for both

Waterfall and

Agile Projec

ts


Engaging Stakeholders •  In Agile, the focus is on “Engaging

Stakeholders” rather than on Managing Stakeholders.

•  Stakeholders are involved at the Portfolio, Program, and Team Level.

•  Stakeholder engagement requires transparency and visibility into what is important to them. o  Stakeholders need to understand why,

who, what, and when. o  Keep stakeholders informed on progress

and major events or ceremonies. •  Stakeholders need to participate and be

held accountable for necessary business changes.

•  It is usually impractical to collocate stakeholders; a tool is needed to provide transparency and get engagement.


Stakeholder Engagement

Stakeholders are usually not collocated with the Team. S5cky note boards simply do not work. Email is too slow and inefficient. An automated collabora5ve tool is needed to effec5vely engage stakeholders.


There are three levels of backlogs with Stakeholders involved in each level.

Backlogs


Stakeholder Managers


Stakeholder Engagement should be Measured and Discussed at Each Retrospective


Transparency

Transparency Shows all work being done at the Por>olio, Program and Team Level Makes everything visible between team and among teams Coordinates agile business ac&vi&es with development team ac&vi&es Knowing all impacts significantly reduces the risk


Signoffs and Approvals

For Agile, it is impera5ve to move away from a tradi5onal “Review and Approve” process to an “Inspect and Adapt” process. To do this requires:

•  Transparency

•  Stakeholder Engagement

•  Efficient Inspect and Adapt Methods


Discovery and Valida&on


Agile is an effec&ve delivery process!

Agile is not effec&ve for discovering what to build.


Source: Jim Johnson, Chairman of Standish Group, quoted in 2006 in: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

The Problem: 64% of Func&onality is Rarely or Never Used

The Cause: Poor Discovery and Valida&on

The Result: Higher Costs, Lower Value, Longer Cycle Times


So7ware Po

rIolio

Program

Team

Epics

Epics

Feature

Feature

Feature

Story

Story

Story

Story

Story

Discovery and Validation

Business Customer User Product

Business Model

Customer Assump5ons

User Personas

Conversa5on

Product Vision

Use Cases

MVPs Buyer Personas

Business Outcomes

Customer Outcomes

Prototypes

Capability Gaps

Business Processes

User Assump5ons

Hypothesis

Assump5ons Business Case

Scenarios Customer Needs

Impact Analysis

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Conversa5on

Feature


Business Case for Better Discovery •  Better Discovery will ensure business and stakeholder needs are

understood and will result in better business outcomes.

•  Better validation practices will eliminate working on Features that provide little or no value.

•  Savings will result from more cost effective validation: using code to validate ideas is very expensive.

•  Savings will result from capturing defects much earlier in the process.

•  Savings will result from less rework and less development iterations.

•  Better utilization of resources: Designers and analysts skills are more aligned to discovery than delivery.

•  Increases velocity of delivery team through having better defined user stories and spending less time grooming the backlog.

•  Provides efficient method to validate assumptions about the market, customers, and the business model before building the product.


Identify What Business Changes Are Needed

Define Impacts. Address what the needed changes will impact.

What needs to change to solve the problem?

•  People. Which people or organizations will be impacted by the project?

•  Processes. What business processes will be impacted?

•  Governance. What rules constrain the project?

•  Data. What data and knowledge is needed?

•  Technology. What IT services and technologies will be impacted?

•  Projects. What other projects will be impacted by the project?


SoAware

PorIolio

Program

Team

Epics

Epics

Feature

Feature

Feature

Story

Story

Story

Story

Story

So7ware Delivery

Value Discovery

Investment Funding

People Process Technology Data Rules

Impact

Business Change

Impact

Impact Impact Impact

Impact

Impact

Impact

Impact Impact

Impact

Impact

Impact

Impact

Impact

Impact Impact

Impact

Impact Impact

Impact Impact


Capacity and Conflicts

Task

Task

Task

Task

Task

Task

Task

Features are Used for Managing Software Impacts are Used for Managing Business Change


Business Change Impacts: People

•  Assign impacts to organiza5onal change professionals or super users within the organiza5ons.

•  Engaging stakeholders like this can significantly improve outcomes and decrease risk.


Business Change Impacts: Processes

•  It is very important to define and manage needed changes to business processes before star5ng on soAware development.

•  Not doing this will result in soAware that supports an problem business process and require significant rework to fix.

•  Assigning this responsibility to business stakeholders takes a load off of the team and helps ensure that the new solu5on addresses the To-‐Be process versus AS-‐IS workflow significantly reducing the amount of rework.


•  Since 2008, there has been a high rate of PMO startup activity with an implementation failure rate of more than 50%.

•  Even though program and portfolio management (PPM) is a growing area of need for many organizations, the results it delivers often don't live up to expectations.

•  Organizations must consider moving beyond traditional IT portfolio management to align with mission critical business objectives.

•  The focus of PPM needs to must shift to be able to adapt to changing strategies to create maximum business value for minimum cost, quickly.

•  Enterprise Portfolio Management Offices are beginning to emerge. The key driver is the need to merge technology and business projects under the same organization.

•  “Don’t start a PMO unless it focuses on demonstrable results and business value vs. process and administrative burden.”

Gartner’s View of Por>olio Management

Source: Gartner Group – Project Manager 2013

Effec5ve porIolio management requires managing strategy, people, processes, and technology and focuses on delivering business value,

not crea5ng an addi5onal process or administra5ve burden.


Portfolio Management The Old Way and New Way

The Old Way The New Way Focused on funding and priori5za5on of technology projects.

Focuses on enabling business change through people, process, and technology.

Primary emphasis is on enforcing compliance to process.

Primary focus is delivering business value and becer business outcomes.

Burdening the organiza5on with administra5on and process.

Allowing the organiza5on to move faster.

User adop5on never considered as part of porIolio management process.

Extensive focus on user adop5on.

Focus is tracking costs, 5me, and tasks. Focus is on maximizing the delivery of business value more quickly.

Alloca5ng resources to projects Enabling business change faster using business architecture, cloud services, and selec5ve sourcing.

Documen5ng the train wreck. Accountability involves direct execu5on of strategic program.

Gartner Predic5on 2014: “PPM Leaders Must Prepare for Extreme Transforma5on or Prepare New Resumes.”


Procure to Pay Service

Order to Cash Service

Hire to Re5re Service

Service Por>olio Services Suppor&ng Business Capabili&es

Product Por>olio

Accounts Payable Purchasing

Purchase Data

Warehouse

Vendor Data Management

Accounts Receivable

Customer Rela5onship Management

Order Management

Sales Data Warehouse

Payroll Human Resources

Employee Master Data

Sales Data Warehouse

Storage Servers Network Database Management Security

Agile Portfolio

Applica&on So7ware Teams

DevOps Teams


•  Budget and plans are completed efficiently and on 5me. •  Budgets and opera5ng plans accurately es5mate financial outcomes. •  Investments are directed at strategic priori5es.

Business Outcomes

Business Processes •  Develop Capital Budget (CAPEX) •  Develop Opera5ng Budget (OPEX)

•  OPEX Budget Development •  CAPEX Budget Development •  Budget Review and Approval •  Budget Reports •  Budget Dashboard and Monitoring •  Support Services

Service Components

•  Budget Applica5on •  SAP ERP Interface and Integra5on •  BI Analy5cs Applica5on •  Service Desk Support •  Infrastructure Services (Servers, Network and Storage)

Provide all the technology, informa5on and IT service support needed by finance and business unit to prepare and manage capital budgets and annual opera5ng plans

Service Assets

End-‐to-‐End Service

Example of an IT Service Provided to the Business


Agile Portfolio Management Transformation

•  PMOs must make significant changes to support an Agile Organization – Old rigid bureaucratic control and governance structures must go away

•  PPM goes from managing projects to managing value and change (Gartner)

•  Transition from IT PMOs to Enterprise PMOs (EPMO) (Gartner) •  The P in PMO changes to Portfolio or Program instead of Project

(Gartner) •  Organizational change and business analysis become key skills for the

EPMO •  Service Portfolio Management with emphasis on delivering business

capabilities becomes key strategy for EPMOs. •  Business Architecture will become necessary ingredient for making

portfolio management decisions •  Big projects must go away and be broken into a set of independently

delivered features (Standish Group) •  Lean Startup methods will be applied to portfolio management using what

Gartner calls a “Fail-Forward-Fast” approach •  Transparency will be essential for tomorrow’s PMO



2. Facilita&ng So7ware Delivery •  Send Approved Features to Delivery Teams

•  Manage Scrum of Scrums •  Par5cipate in Demos and Retrospec5ves

•  Inspect and Adapt •  Define NFRs •  Plan and manage Release Trains

3. Enabling Business Change •  Define needed changes using impacts •  Assign impacts to accountable technical and business stakeholders

•  Monitor stakeholder engagement •  Assess business and customer outcomes •  Inspect and Adapt

1. Discovering Business Needs •  Define program objec5ves and expected outcomes •  Define Features that can be delivered independently •  Validate Features using MVPs and other Lean Methods •  Priori5ze and Eliminate Features that Provide Licle or No Value •  Perform Roadmap Planning


Two Core Concepts for Successful Projects From 2013 CHAOS Manifesto Report

1.  Break down projects into small components

2.  Eliminate components that provide little or no value


Breaking Down Projects Into Small Components

•  The Standish Group flatly state that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.”

•  It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project.

•  Small projects deliver a valuable result that is actually used to create a return on investment (ROI).

•  The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle.

Source 2013 CHAOS Manifesto Report, Standish Group

Think Big, Act Small


Reducing and Managing Solution Scope

•  Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently.

•  Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.

•  Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one.

Think Big, Act Small

Source 2013 CHAOS Manifesto Report, Standish Group


Iteration (Sprint)"

Agile ReleaseTrain"

is to team!

is to program!

as!

Agile Program Management: Releases


Inspect and Adapt for Continuous Improvement

•  Agile approaches are based on an empirical process — a process of making decisions based on the what has actually occurred.

•  An empirical process is very important for software projects and is used for both new product development and enhancement and upgrade of existing products.

•  The team's ability to inspect and adapt has a major impact on a project’s success or failure. In fact, some surveys show that ineffective use of retrospective is the number one reason Agile adoptions fail.

•  Empirical control requires: o  Transparency: Everyone involved on an agile project

knows what is going on and how the project is progressing.

o  Frequent inspection: Team members and stakeholders regularly evaluate the product and process.

o  Adaptation: Adjustments are made quickly after a problem has been identified.


Scrum or Kanban?

Scrum

Kanban

Kanban is a con5nuous flow process: items enter the queue and then get “pulled” through a series of steps in the development process. Kanban is oAen visualized on a Kanban board and each step is represented by a column.

Scrum is a simple yet incredibly powerful set of principles and prac5ces that help teams deliver products in short cycles, enabling fast feedback, con5nual improvement, and rapid adapta5on to change. As the leading Agile development framework, Scrum has predominantly been used for soAware development, but it is also proving to be effec5ve in efforts far beyond.


DevOps

Development Wants Rapid Change

Measured by Amount of Valuable So/ware Delivered

Opera&ons Wants Stability

Over 80% of Outages are caused on Change.

The Business Wants Both Features are Needed for increased

revenues and growth. Outages cost the business significant dollars


Enfocus Solutions Complete Support for Agile Portfolio and Program Management

•  Stakeholder Engagement and Collaboration •  Provide efficient methods for Stakeholder Engagement and Collaboration •  Provide complete Transparency to Agile Teams and Stakeholders

•  Discovery and Validation •  Define Project Vision, Objectives, Constraints, and Business Case •  Gain understanding of customer and their needs using Personas and

Scenarios •  Define Customer and Business Outcomes using Objectives •  Breaking Down Project or Epics into Features •  Review and Validate and Prioritize Features •  Define and Manage Needed Business Changes using Impacts

•  Mange Inspect and Adapt Activities •  Manage Retrospectives •  Inspect Features, Stories, Releases, and Impacts •  Use action items needed for adaptation

•  Team Integration •  Define User Stories In Our Software or through Integration with backend Agile

Team Tools such as JIRA. •  Define Transition Requirements for Release Management •  Define Nonfunctional Requirements for software development


Thank You Please provide comments what you liked or didn’t like or topics for other webinars to the email below. [email protected]

agile business transformation

Business

scaled agile

business change

porgt

business outcomes

soaware development

collaboraamp

viamp

validaamp