TDWI STL 20140613 Agile - Paul Holway

NOTICE: Proprietary and Confidential

This material is proprietary to Centric Consulting, LLC. It contains trade secrets and information which is solely the property of Centric Consulting, LLC.

This material is solely for the Client’s internal use. This material shall not be used, reproduced, copied, disclosed, transmitted, in whole or in part, without

the express consent of Centric Consulting, LLC.

© 2014 Centric Consulting, LLC. All rights reserved

Agile Overview The Data Warehouse Institute – St. Louis

[email protected]

314-265-3403

Twitter: @paulholway

mailto:[email protected]

WHY GO AGILE?

5/28/2014 www.centricconsulting.com 1

Bluetooth enabled - Moxie Shower by Kohler

Why go Agile?

And

How does it relate to

the Business

Intelligence space?

Why is agile adoption rising?

Version One 2012 Survey of Agile Results:


The Real Reason

70%* of Business Intelligence Solutions industry-wide fail to

meet the business user expectations

Some cited reasons:

• Lack of business involvement

• Executives find it difficult to find information**

• Difference between insights and data

• Bias vs. fact


•Gartner: 2012 Business Intelligence still subject to non-technical challenges

•** Business Week Research Services

Data is coming from everywhere


Sensors invade and expand Big Data use

http://centricconsulting.com/sensors-bring-big-data-into-the-mainstream/

http://connectedco.com/

BUSINESS AND TECHNOLOGY ARE CHANGING AT AN INCREASINGLY RAPID PACE


http://connectedco.com/

Back to Basics


The Agile Mindset

Business involvement throughout the project Business participation on a daily basis helps ensure that business value is achieved by regularly prioritizing work based on business value,

by providing rapid ongoing feedback to the team on features as they are built, and by verifying that features provide the expected

functionality.

Empiricism and experimentation During the last 50 years of software development a lot of time has been spent upfront trying to figure out and lock down requirements,

design and test plans for an entire set of features. In agile development teams will become familiar with the agile concept that it’s better not

to think too deeply about each feature until it’s time to build them. In agile empiricism asserts that knowledge comes from experience and

making decisions based on what is known. In practice, this means that, as we build software, we also build experience so that we can

replace detailed up front planning and processes with just in time inspect and adapt cycles.

Build working software frequently within a short, fixed timeframe (i.e. timebox) Building working software means software that has been verified to work as it should in production. Teams will become familiar with the

agile concept of completing working software that doesn’t have all of the features envisioned but only those that can be completed during

the current timebox knowing that additional features will be developed during subsequent cycles.

Small team size As a general rule, smaller teams will tend to be more efficient and productive because communication overhead is reduced, there is less

unproductive waiting time and fewer handoffs. Within small teams, each team members skill-set will increase and broaden so that each

member can begin to be involved in more than one part of the software development process.

Transparency Open sharing of the state of the work will serve to encourage participation and to expose decisions, challenges and successes to the much

broader team. It means that decisions are made out in the open—subject to broader scrutiny, which in turn leads to better decisions and

more of a sense of ownership from team members. In addition, the transparency found in Agile practices will impart better visibility and a

greater sense of ownership to all stakeholders, encourage Close coordination and build mutual trust amongst stakeholders, and bring all

stakeholders on the ‘same page’ in terms of project progress and expectations


Agile is not only a development approach but also a mindset based on the principles of the agile

manifesto. To be successful with agile, there needs to be cultural a shift, not an imposed afterthought.

Below are just some of the paradigm shifts that take place when transitioning to agile.


Introduction: Agile vs. Traditional approaches

Agile Approach Traditional Approach

Leverage continual feedback to deliver business value as early and often as possible.

Invest in a detailed plan, and then execute on it.

Adapts to changing priorities through a continual feedback loop and iterative work planning.

Upfront analysis, requirements and design that “lock in” key designs early

Short, iterative design, development, testing, and deployment efforts.

Long delivery phases to develop and test software; working software is delivered at the end of a phase.

Project status is measured by the working software that is delivered.

Project status is measured against a detailed project plan.

Avoids painful change request situations by embracing new requirements as they emerge

Changes in requirements result in contentious change requests.

Established upfront cadence determines delivery date(s) and are based on consistent iteration and release schedules.

Upfront contract based on many unknown items specifies delivery date and project cost.

Architects the right solution – “end-to-end” development continually validates that a design supports the product’s features.

Long delivery cycles limit ability to introduce new functionality quickly as well as make architectural improvements.

Agile is not about IT or for the benefit of IT. Agile is about increasing competitive advantage for the business. Agile serves to address the needs of the customer impacted by ever-changing business climate, economic conditions and external regulations.


Components Of a Successful Agile Execution

Today, few technology managers or developers will admit to not understanding agile. The Agile Manifesto* serves as an excellent foundation, but we know there’s more to delivering on budget, on schedule, and with real people. In our experience, you need 4 things:

Your agile approach needs

to be defined as a starting

point. What activities occur

during planning, Sprints,

deployment and feedback

cycles? Who is responsible

for what? What

mechanisms are in place to

help the team execute and

improve those processes?

Processes Technology

Practices

Organizational

Interfaces

Change

Management

The highly iterative nature of

agile development drives a

need for solid development

practices. Test driven

development, continuous

integration, and test

automation help an agile team

create and sustain a

consistent delivery pace.

What is required to convince

more than just the IT

organization to embrace

agile? (success ultimately

depends on this) What

techniques will you use?

If your entire company is

not Agile, how will you

create metrics and work

with more traditional IT

management functions like

PMOs, architecture boards,

and centralized support

organizations?

http://www.agilemanifesto.org

Technology

Practices

Organizational

Interfaces

Change

Management

5/28/2014 10 www.centricconsulting.com

Define Your Agile Process

Our project experience tells us a “one size fits all” approach to Agile does not work. Centric’s

approach to Agile is to methodically define the appropriate Agile process for the specific project and

project team.

Components of a Successful Agile Execution

Processes

In an agile project, the first thing to getting started is establishing a cadence.

• Prioritization

• Estimation

• Learning and Adapting

• Garnering Feedback

• Releasing

• Keeping in Sync.


Establishing Cadence

Often we receive so many ideas and requirements, because users are afraid of

missing the “Feature Bus”. They will not get your attention back again. By

establishing cadence, you effectively install more stops that they can get on/off.

Why is cadence is so important?


How The Cycle & Levels Work Together

The Centric agile approach model is defined by cycles of Plan, Execute, Feedback & Done that are repeated throughout

the Program, Release, Sprint, and Story levels of the work lifecycle. The Cycle and the Levels work together – the Cycle

runs on each Level. Each Level runs through a full Cycle, then passes control back up to the Level above.

• Plan: Planning and work breakdown, with appropriate detail for the Level

• Execute: Execute cadence for the Level + one or more full Cycles for the Level below

• Done: Verify work completed against Definition of Done for the Level

• Feedback: Implement feedback cycle appropriate for the Level, per Cadence

Plan E

xe

cu

te

Verify

Fe

ed

ba

ck


The Levels

The Levels provide us with constructs to facilitate talking about and managing work. We start by

treating work at a very high level, then gradually hone our way in over time until we are talking about

work at the level or detail needed to actually do it. This idea incorporates two key agile concepts:

Just in Time: Don’t think about the details of a work item until it is time to do that work.

Just Enough: Do the work in very small chunks.


A sample cadence

Key Decisions

1. Time required to deliver Release.

2. Breakdown of Work Into

Iterations

Governed By

Release Owner

Governed By

Product Owner

Governed By

Steering Committee

Key Decisions

1. User Stories, Epics or other imperatives to be included in the

next release.

2. Commitment of Release Owner.

Prioritization

The Steering Committee represents the business in

evaluating analytic needs. While most of these needs are

strategic in nature, some immediate demands may at times

be given precedence.

As the BI Team approaches completion of a Release the

Steering Committee will decide the next Release to be

delivered. They will also identify a Release Owner who will

oversee delivery.

Release

A Release Owner, having been assigned by the,

oversees the delivery of one or Steering

Committee more User Stories in a Release. They

are responsible for ensuring that the analysis truly

delivers the expected business capability.

The Release Owner will work with the BI Team to

plan all releases comprising the release. They will

also identify a Product Owner to represent the

business in a SME and advisory role.

Iteration

The BI Team will

implement a Release in

Iterations. The intent is

to frequently provide

business users with a

quality working

product, thereby

increasing feedback

frequency.

Portion of Release

delivered to business

users.

Challenges to the Release Date

Unlike traditional App Dev projects, BI teams must deal with uncontrollable

enterprise data and systems. This may occasionally introduce delays to a release.

• Source system data quality

• Source system up-time

• Unexpected data volatility

• Non-existent data.

• Information not persisted in data

• Unavailability of SMEs

Program Communication

Key Decisions

1. Develop the Release Charter with the BI Team

2. Commitment of Product Owner.

Key Decisions

1. Time required to deliver Release.

2. Breakdown of Work Into

Iterations

Daily Report

A Team driven activity focused

on how healthy the board is, and

how the team can help.

Stakeholder

Communication


THE BOARD

http://ketiljensen.wordpress.com/2009/10/31/kanban-the-next-step-in-the-agile-evolution/

A story should be

Independent

Negotiable

Valuable

Estimable

Small

Testable


The unit of work. Should strive to be the smallest possible chunk that provides business value.

The Story

As a <role>

I can <activity>

So that <business value>

As a financial analyst, I want

to see profit by customer

account per order so that I can

view the profitability of order

types while making forecast

decisions for August budget

cycle.

As a Consumer, I want

to be able to see my

daily energy usage so

that I can lower my

energy costs and usage


CREATING OUR BACKLOG – TASKS, EPICS, and STORIES

Role Analysis Capability

Impact

Criteria

What is the perspective

of the user?

What analysis do they

want to perform? What business

capability is being

delivered (business

process, decision,

etc.)

How does it

strategically impact

the organization?

What are the criteria for

this capability to be

successfully delivered?

As a campaign manager, I need to assess our members’

engagement level within individual campaigns so that I can measure

the efficacy of the campaign. This allows me to determine how

engaged members were so that we can predict the campaign's

impact related to gaps in care and other factors. Strategically, this

enables our company to articulate the effectiveness of campaigns

and identify which campaigns are successful and which ones are not.

In order to be successful, this analysis must include our entire

historical set of data. We must also have project metadata (start

date, end date, campaign type, population demographics, etc.)

incorporated into the analysis.


• As a team create a list of what went well, what did not go well, and what suggestions for improvements.

• The list should be team focused, not externally focused.

• The list should be kept running across iterations.

• The list should be prioritized by the team in each retrospective.

Create a process and mechanism to continually improve

2 Categorize

3 Disposition

4 Assign

1 Retrospective

TOPICS BACKLOG

5 Measure

and

Feedback

Stop

Start

Keep

XX to do YY by ZZ

Pick the top 2-

3 topics


Centric's Agile Approach – Agile Technology Practices

Many Agile transformations focus solely on the Agile process. But the technologies used to execute successful Agile delivery are equally important. Early Sprints need to define the technologies and the extent to which they will be used. Do not attempt to do this on the fly!

Organizational

Interfaces

Change

Management

Processes Technology

Practices



Beyond Process

A new process alone will not yield a truly agile organization. Depending on your organization and culture, several items about the way your technical team works will need to change.

- A focus away from component perfection into business unit value

- Embrace refactoring

- Move toward evolutionary design patterns

- Build Quality In

- Automate everything


Agile does not mean faster or with less quality. In fact, quality takes a larger role in agile.

-Quality is a first class citizen in the conversation. -Testing is included in the iteration

-Is this testable? How?

How will we perform regression as time goes by? The push for automation. Lack of automation is a major source of agile failure.

Build Quality In


Centric’s Agile Approach – Organizational Change Management

Agile is very different than traditional development approaches – different roles, different interactions, different

reporting structures. We see similar concerns on across many different engagements when taking on an Agile

approach. Types of concerns and reasons for them differ by role.

Technology

Practices

Organizational

Interfaces

Processes


Change

Management


Centric’s Agile Approach – Organizational Change Management

Managers Non-managers

Loss of power and control Lack of understanding around the vision and need for change

Overload of current tasks, pressures of daily activities and

limited resources

Comfort with the status quo and fear of the unknown

Lack of skills and experience needed to manage the change

effectively

Corporate history and culture

Fear of job loss Opposition to the new technologies, requirements and

processes introduced by the change

Disagreement with the new way or skepticism about the need

for change

Fear of job loss

Common reasons for being concerned about moving to an agile development approach.

Role Concerns About Agile

Business Analyst "A big requirements document is no longer my focus, what is?”

Developer "Agile changes how projects are planned, but shouldn't impact how I write code, right?”

Quality Analyst "Why do I need to be involved so early in the process? What do I do?”

Resource Manager "If developers are fully allocated to a single team and are self-organizing to tasks, what role do I

play?”

"Do performance evaluations need to be different now?”

PMO Lead “Why shouldn't we have agile teams follow the same phase gates as the other projects?”

Stakeholder "They have new questions for me every other day. Why not spend a week at the start of the project

and talk all of this out?”

Common concerns when going from a traditional approach to an agile approach.

Technology

Practices

Change

Management

Processes

Organizational

Interfaces


Centric’s Agile Approach – Organizational Interfaces

During an Agile transformation it is critical that Agile Teams provide information and feedback outside of their team in order to support other organization needs. Our approach recognizes these needs, and provides thinking and tools to support.



Components Of Successful Agile Execution – Organizational Interfaces

During an Agile transformation it is critical that Agile Teams provide information and feedback outside of their team in order to support other organization needs. Recognize these needs, and provide the thinking and tools to support.


What to do next?

Do not:

• Focus on Process only

• Let the simplicity of the philosophy be misintepreted

• Say, “we do that”

Do:

• Get an experienced coach

• Pick a pilot team/project and learn what works for your org

• Start bottom-up, not top-down

• Invest in testing

• Run retrospectives
