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
paul.holway@centricconsulting.com
314-265-3403
Twitter: @paulholway

WHY GO AGILE?
5/28/2014www.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://connectedco.com/
BUSINESS AND TECHNOLOGY ARE CHANGING AT AN INCREASINGLY RAPID PACE

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?

Technology
Practices
Organizational
Interfaces
Change
Management
5/28/2014 10www.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
ExecuteVerify
Feedback

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
• Unexpecteddata 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

TDWI STL 20140613 Agile - Paul Holway

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to TDWI STL 20140613 Agile - Paul Holway

Similar to TDWI STL 20140613 Agile - Paul Holway (20)

Recently uploaded

Recently uploaded (20)

TDWI STL 20140613 Agile - Paul Holway