- Idea
Everything stats with an idea! It could be an idea for a new product/service offering, or it could be a new market opportunity that you want to pursue, or it could be that you want to fix all the ‘holes’ in your existing product in order to gain better market share. Bottom line is that it all starts with a seed that we call Idea! - Visioning
Remember, you are not alone working on this idea! You will have teams working on this idea to drive it towards (becoming) a reality. You should be able to convey your vision about the product/service. We use this special format to describe your vision. - Story mapping / brainstorming
Now, armed with your Vision statement, you can start pulling all the right parties, the stake holders into conversation. You can lead a brainstorming session to uncover, unearth the work that needs to be completed in order to make this vision a reality. Don’t overwhelm yourself with lot of details. Key here is to stay at 50K ft and capture high level (slices of) work that would need to be completed (don’t worry about how, when, who does it. For now, the focus is on WHAT. - Roadmap
Now that we know what work needs to be completed (based on the Story mapping exercise), we can start putting them together on a roadmap that will help us make the product a reality. At this point, we want to focus on next 6 to 12 months, and create a product road map; what features would be built, and when we would like to release them to the market. As we do this, stay focused on creating value with each product increment that we push to market. - Release Plan
With the roadmap in place, we can start pulling in all the teams that would be working on them. Complete some dependency analysis, identify all the teams, and get them into release planning session. Here, we are focusing on next two to three months, and what product increment we can work on and get it out to market. All the teams can discuss these features and functionalities, what it will take (effort) for them to make it a reality, what are the dependencies, and how they may impact the “Push to Production” effort. At the end of this session, these teams come out with an intended plan of HOW they will build this product increment. - Sprints / Iterations
Based on the intended plan that came out of the release planning session, teams go into individual sprints, get into more details as to what tasks needs to be completed. Here, we focus on next two to three weeks at a time.
Based on the history, make up of the teams, and what is needed in the functionality, the Chief Product Owner (CPO) may decided to pre-assign some of the work slices (open for discussion and negotiations with the team later on).
Read More- Identifying the data elements and sources for that data
- Coming up with logical data model that will support the business’s analytical needs
- Often, getting this logical model; or as technical teams would say LDM (Logical data model) approved through some governance body in the organization
- Getting the physical data structures, PDM (Physical data model) created
- Extracting and transforming data from various sources to load into the physical data structures
Typical workflow for a Data Warehouse build out [Please note that we will be modifying this as we discuss the topic further] |
- We build the data warehouse in increments
- Delivering Potential shippable increment (PSI) of the data warehouse at a regular frequency [and not have customers waiting to get the data warehouse as one big-bang delivery]
- Involving customers through the build process
- Understanding customers, and their needs – what are the business reasons for them to request this data warehouse
- Focus on creating customer value incrementally, and not the technologies or the implementation of it. Shift your focus from technology (and data elements, data structures, primary key, foreign key, etc.) to customers needs.
Often times data folks are so focused on their tables and primary keys that they start driving the build out from that vantage point only 🙁
- Identifying the data elements and sources for that data
- Coming up with logical data model that will support the business’s analytical needs
- Often, getting this logical model; or as technical teams would say LDM (Logical data model) approved through some governance body in the organization
- Getting the physical data structures, PDM (Physical data model) created
- Extracting and transforming data from various sources to load into the physical data structures
Typical workflow for a Data Warehouse build out [Please note that we will be modifying this as we discuss the topic further] |
- We build the data warehouse in increments
- Delivering Potential shippable increment (PSI) of the data warehouse at a regular frequency [and not have customers waiting to get the data warehouse as one big-bang delivery]
- Involving customers through the build process
- Understanding customers, and their needs – what are the business reasons for them to request this data warehouse
- Focus on creating customer value incrementally, and not the technologies or the implementation of it. Shift your focus from technology (and data elements, data structures, primary key, foreign key, etc.) to customers needs.
Often times data folks are so focused on their tables and primary keys that they start driving the build out from that vantage point only 🙁
I have been involved in agile transformation at a Fortune 100 company, specifically in their EDS division. EDS being a central steward of all the data warehouse the company uses, it has been a challenge to rollout agile in this centralized group. In a series of articles, I will talk about my experience of agile rollout in EDS and data warehouse build out, the challenges we faced, and the ‘model’ that could be used. My hope is this series of articles will help you get a ‘head start’ when you have to work in such a situation.
This series of artless will include:
- What it is – what do I mean by agile data warehouse?
- Challenges agile teams face in an enterprise
- Patterns for writing User Stories: Different ways of Slicing the work
- Agile model that helps us develop and deliver data warehouse incrementally, delivering value earlier, and driving RoI for our customers; internal and external.
There is no organization that can live (and prosper) without data warehouse. Every organization is using data warehouse (on a smaller scale, perhaps) to house relevant data and use it to their advantages.
Look forward to ‘seeing’ you all here in this series.
[Next post: What it is? – the agile data warehouse]
Read MoreI have been involved in agile transformation at a Fortune 100 company, specifically in their EDS division. EDS being a central steward of all the data warehouse the company uses, it has been a challenge to rollout agile in this centralized group. In a series of articles, I will talk about my experience of agile rollout in EDS and data warehouse build out, the challenges we faced, and the ‘model’ that could be used. My hope is this series of articles will help you get a ‘head start’ when you have to work in such a situation.
This series of artless will include:
- What it is – what do I mean by agile data warehouse?
- Challenges agile teams face in an enterprise
- Patterns for writing User Stories: Different ways of Slicing the work
- Agile model that helps us develop and deliver data warehouse incrementally, delivering value earlier, and driving RoI for our customers; internal and external.
There is no organization that can live (and prosper) without data warehouse. Every organization is using data warehouse (on a smaller scale, perhaps) to house relevant data and use it to their advantages.
Look forward to ‘seeing’ you all here in this series.
[Next post: What it is? – the agile data warehouse]
Read More