| |
| |
| List of Figures | |
| |
| |
| List of Tables | |
| |
| |
| Preface | |
| |
| |
| Author's Bio | |
| |
| |
| |
| An Introduction to Iterative Development | |
| |
| |
| |
| What Is Agile Data Warehousing? | |
| |
| |
| A quick peek at an agile method | |
| |
| |
| The "disappointment cycle" of many traditional projects | |
| |
| |
| The waterfall method was, in fact, a mistake | |
| |
| |
| Agile's iterative and incremental delivery alternative | |
| |
| |
| Agile as an answer to waterfall's problems | |
| |
| |
| Agile methods provide better results | |
| |
| |
| Agile for data warehousing | |
| |
| |
| Data warehousing entails a "breadth of complexity" | |
| |
| |
| Adapted scrum handles the breadth of data warehousing well | |
| |
| |
| Managing data warehousing's "depth of complexity" | |
| |
| |
| Guide to this book and other materials | |
| |
| |
| Simplified treatment of data architecture for book 1 | |
| |
| |
| Companion web site | |
| |
| |
| Where to be cautious with agile data warehousing | |
| |
| |
| Summary | |
| |
| |
| |
| Iterative Development in a Nutshell | |
| |
| |
| Starter concepts | |
| |
| |
| Three nested cycles | |
| |
| |
| The release cycle | |
| |
| |
| Development and daily cycles | |
| |
| |
| Shippable code and the definition of done | |
| |
| |
| Time-boxed development | |
| |
| |
| Caves and commons | |
| |
| |
| Product owners and scrum masters | |
| |
| |
| Improved role for the project manager | |
| |
| |
| Might a project manager serve as a scrum master? | |
| |
| |
| User stories and backlogs | |
| |
| |
| Estimating user stories in story points | |
| |
| |
| Iteration phase 1: story conferences | |
| |
| |
| Iteration phase 2: task planning | |
| |
| |
| Basis of estimate cards to escape repeating hard thinking | |
| |
| |
| Task planning doublechecks story planning | |
| |
| |
| Iteration phase 3: development phase | |
| |
| |
| Self-organization | |
| |
| |
| Daily scrums | |
| |
| |
| Accelerated programming | |
| |
| |
| Test-driven development | |
| |
| |
| Architectural compliance and "tech debt" | |
| |
| |
| Iteration phase 4: user demo | |
| |
| |
| Iteration phase 5: sprint retrospectives | |
| |
| |
| Retrospectives are vital | |
| |
| |
| Close collaboration is essential | |
| |
| |
| Selecting the optimal iteration length | |
| |
| |
| Nonstandard sprints | |
| |
| |
| Sprint 0 | |
| |
| |
| Where did scrum come from? | |
| |
| |
| Distant history | |
| |
| |
| Scram emerges | |
| |
| |
| Summary | |
| |
| |
| |
| Streamlining Project Management | |
| |
| |
| Highly transparent task boards | |
| |
| |
| Task boards amplify project quality | |
| |
| |
| Task boards naturally integrate team efforts | |
| |
| |
| Scrum masters must monitor the task board | |
| |
| |
| Burndown charts reveal the team aggregate progress | |
| |
| |
| Detecting trouble with burndown charts | |
| |
| |
| Developers are not the burndown chart's victims | |
| |
| |
| Calculating velocity from burndown charts | |
| |
| |
| Common variations on burndown charts | |
| |
| |
| Setting capacity when the team delivers early | |
| |
| |
| Managing tech debt | |
| |
| |
| Managing miditeration scope creep | |
| |
| |
| Diagnosing problems with burndown chart patterns | |
| |
| |
| An early hill to climb | |
| |
| |
| Shallow glide paths | |
| |
| |
| Persistent inflation | |
| |
| |
| Should you extend a sprint if running late? | |
| |
| |
| Extending iterations is generally a bad idea | |
| |
| |
| Two instances where a changing time box might help | |
| |
| |
| Should teams track actual hours during a sprint? | |
| |
| |
| Eliminating hour estimation altogether | |
| |
| |
| Managing geographically distributed teams | |
| |
| |
| Consider whether fully capable subteams are possible | |
| |
| |
| Visualize the problem in terms of communication | |
| |
| |
| Choose geographical divisions to minimize the challenge | |
| |
| |
| Invest in a solid esprit de corp | |
| |
| |
| Provide repeated booster shots of colocation for individuals | |
| |
| |
| Invest in high-quality telepresence equipment | |
| |
| |
| Provide agile team group ware | |
| |
| |
| Summary | |
| |
| |
| |
| Defining Data Warehousing Projects for Iterative Development | |
| |
| |
| |
| Authoring Better User Stories | |
| |
| |
| Traditional requirements gathering and its discontents | |
| |
| |
| Big, careful requirements not a solution | |
| |
| |
| A step in the right direction | |
| |
| |
| Agile's idea of "user stories" | |
| |
| |
| Advantages of user stories | |
| |
| |
| Identifying rather than documenting the requirements | |
| |
| |
| User story definition fundamentals | |
| |
| |
| Quick test for actionable user stories | |
| |
| |
| How small is small? | |
| |
| |
| Epics, themes, and stories | |
| |
| |
| Common techniques for writing good user stories | |
| |
| |
| Keep story writing simple | |
| |
| |
| Use stories to manage uncertainty | |
| |
| |
| Reverse story components | |
| |
| |
| Focus on understanding "who" | |
| |
| |
| Focus on understanding "what" | |
| |
| |
| Focus on understanding "why" | |
| |
| |
| Be wary of the remaining w's | |
| |
| |
| Add acceptance criteria to the story-writing conversations | |
| |
| |
| Summary | |
| |
| |
| |
| Deriving Initial Project Backlogs | |
| |
| |
| Value of the initial backlog | |
| |
| |
| Sketch of the sample project | |
| |
| |
| Fitting initial backlog work into a release cycle | |
| |
| |
| The handoff between enterprise and project architects | |
| |
| |
| Key observations | |
| |
| |
| User role modeling results | |
| |
| |
| Key persona definitions | |
| |
| |
| Carla in carp strategy | |
| |
| |
| Franklin in finance | |
| |
| |
| An example of an initial backlog interview | |
| |
| |
| Framing the project | |
| |
| |
| Finance is upstream | |
| |
| |
| Finance categorizes source data | |
| |
| |
| Customer segmentation | |
| |
| |
| Consolidated product hierarchies | |
| |
| |
| Sales channel | |
| |
| |
| Unit reporting | |
| |
| |
| Geographies | |
| |
| |
| Product usage | |
| |
| |
| Observations regarding initial backlog sessions | |
| |
| |
| Sometimes a lengthy process | |
| |
| |
| Detecting backlog components | |
| |
| |
| Managing user story components on the backlog | |
| |
| |
| Prioritizing stories | |
| |
| |
| Summary | |
| |
| |
| |
| Developer Stories for Data Integration | |
| |
| |
| Why developer stories are needed | |
| |
| |
| Introducing the "developer story" | |
| |
| |
| Format of the developer story | |
| |
| |
| Developer stories in the agile requirements management scheme | |
| |
| |
| Agile purists do not like developer stories | |
| |
| |
| Initial developer story workshops | |
| |
| |
| Developers workshop within software engineering cycles | |
| |
| |
| Data warehousing/business intelligence reference data architecture | |
| |
| |
| Forming backlogs with developer stories | |
| |
| |
| Evaluating good developer stories: DILBERT'S test | |
| |
| |
| Demonstrable | |
| |
| |
| Independent | |
| |
| |
| Layered | |
| |
| |
| Business valued | |
| |
| |
| Estimable | |
| |
| |
| Refinable | |
| |
| |
| Testable | |
| |
| |
| Small | |
| |
| |
| Secondary techniques when developer stories are still too large | |
| |
| |
| Decomposition by rows | |
| |
| |
| Decomposition by column sets | |
| |
| |
| Decomposition by column type | |
| |
| |
| Decomposition by tables | |
| |
| |
| Theoretical advantages of "small" | |
| |
| |
| Summary | |
| |
| |
| |
| Estimating and Segmenting Projects | |
| |
| |
| Failure of traditional estimation techniques | |
| |
| |
| Traditional estimating strategies | |
| |
| |
| Why waterfall teams underestimate | |
| |
| |
| Criteria for a better estimating approach | |
| |
| |
| An agile estimation approach | |
| |
| |
| Estimating within the iteration | |
| |
| |
| Estimating the overall project | |
| |
| |
| Quick story points via "estimation poker" | |
| |
| |
| Story points and ideal time | |
| |
| |
| Story points defined | |
| |
| |
| Ideal time defined | |
| |
| |
| The advantage of story points | |
| |
| |
| Estimation accuracy as an indicator of team performance | |
| |
| |
| Value pointing user stories | |
| |
| |
| Packaging stories into iterations and project plans | |
| |
| |
| Criteria for better story prioritization | |
| |
| |
| Segmenting projects into business-valued releases | |
| |
| |
| The data architectural process supporting project segmentation | |
| |
| |
| Artifacts employed for project segmentation | |
| |
| |
| Project Segmentation technique 1: dividing the star schema | |
| |
| |
| Project Segmentation technique 2: dividing the tiered integration model | |
| |
| |
| Project Segmentation technique 3: grouping waypoints on the categorized services model | |
| |
| |
| Embracing rework when it pays | |
| |
| |
| Summary | |
| |
| |
| |
| Adapting Iterative Development for Data Warehousing Projects | |
| |
| |
| |
| Adapting Agile for Data Warehousing | |
| |
| |
| The context as development begins | |
| |
| |
| Data warehousing/business intelligence-specific team roles | |
| |
| |
| Project architect | |
| |
| |
| Data architect | |
| |
| |
| Systems analyst | |
| |
| |
| Systems tester | |
| |
| |
| The leadership subteam | |
| |
| |
| Resident and visiting "resources" | |
| |
| |
| New agile characteristics required | |
| |
| |
| Avoiding data churn within sprints | |
| |
| |
| Pipeline delivery for a sustainable pace | |
| |
| |
| New meaning for iteration 0 and iteration -1 | |
| |
| |
| Pipeline requires two-step user demos | |
| |
| |
| Keeping pipelines from delaying defect correction | |
| |
| |
| Resolving pipelining's task board issues | |
| |
| |
| Pipelining as a buffer-based process | |
| |
| |
| Pipelining is controversial | |
| |
| |
| Continuous and automated integration testing | |
| |
| |
| High quality is a necessity | |
| |
| |
| Agile warehousing testing requirements | |
| |
| |
| The need for automation | |
| |
| |
| Requirements for a warehouse test engine | |
| |
| |
| Automated testing for front-end applications | |
| |
| |
| Evolutionary target schemas-the hard way | |
| |
| |
| Summary | |
| |
| |
| |
| Starting and Scaling Agile Data Warehousing | |
| |
| |
| Starting a scrum team | |
| |
| |
| Stage 1: time box and story points | |
| |
| |
| Stage 2: pipelined delivery | |
| |
| |
| Stage 3: developer stories and current estimates | |
| |
| |
| Stage 4: managed development data and test-driven development | |
| |
| |
| Stage 5: automatic and continuous integration testing | |
| |
| |
| Stage 6: pull-based collaboration | |
| |
| |
| Scaling agile | |
| |
| |
| Application complexity | |
| |
| |
| Geographical distribution | |
| |
| |
| Team size | |
| |
| |
| Compliance requirements | |
| |
| |
| Information technology governance | |
| |
| |
| Organizational culture | |
| |
| |
| Organizational distribution | |
| |
| |
| Coordinating multiple scrum teams | |
| |
| |
| Coordinating1 through scrum of scrums | |
| |
| |
| Matching milestones | |
| |
| |
| Balancing work between teams with earned-value reporting | |
| |
| |
| What is agile data warehousing? | |
| |
| |
| Communicating success | |
| |
| |
| Handoff quality | |
| |
| |
| Quality of estimates | |
| |
| |
| Defects by iteration | |
| |
| |
| Burn-up charts | |
| |
| |
| Cross-method comparison projects | |
| |
| |
| Cycle times and story point distribution | |
| |
| |
| Moving to pull-driven systems | |
| |
| |
| A glimpse at a pull-based approach | |
| |
| |
| Kanban advantages | |
| |
| |
| A more cautious view | |
| |
| |
| Stages of scrumban | |
| |
| |
| Summary | |
| |
| |
| References | |
| |
| |
| Index | |