TDWI STL 20140613 Agile - Paul Holway


Published on

Paul Holway's presentation to TDWI St. Louis at the 2014-06-13 "Agile" meeting. For more information, see @paulholway on Twitter on LinkedIn (

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

TDWI STL 20140613 Agile - Paul Holway

  1. 1. 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 314-265-3403 Twitter: @paulholway
  2. 2. WHY GO AGILE? 5/28/ 1 Bluetooth enabled - Moxie Shower by Kohler Why go Agile? And How does it relate to the Business Intelligence space?
  3. 3. Why is agile adoption rising? Version One 2012 Survey of Agile Results: 5/27/ 2
  4. 4. 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 5/27/ 3 •Gartner: 2012 Business Intelligence still subject to non-technical challenges •** Business Week Research Services
  5. 5. Data is coming from everywhere 5/27/ 4 Sensors invade and expand Big Data use
  7. 7. Back to Basics 5/29/ 6
  8. 8. 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 5/27/ 7 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.
  9. 9. 5/27/ 8 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.
  10. 10. 5/27/ 9 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?
  11. 11. Technology Practices Organizational Interfaces Change Management 5/28/2014 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
  12. 12. 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. 5/29/2014 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?
  13. 13. 5/27/2014 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
  14. 14. 5/27/2014 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.
  15. 15. 5/27/2014 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
  16. 16. 5/27/ 15 THE BOARD
  17. 17. A story should be Independent Negotiable Valuable Estimable Small Testable 5/27/2014 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
  18. 18. 5/27/ 18 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.
  19. 19. 5/29/ 19 • 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
  20. 20. 5/28/ 20 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 Components of a Successful Agile Execution
  21. 21. 5/29/ 21 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
  22. 22. 5/27/ 22 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
  23. 23. 5/28/ 23 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 Components of a Successful Agile Execution Change Management
  24. 24. 5/27/ 24 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.
  25. 25. Technology Practices Change Management Processes Organizational Interfaces 5/28/ 25 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 a Successful Agile Execution
  26. 26. 5/28/ 26 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.
  27. 27. 5/29/ 27 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
  28. 28. 5/27/ 28