Blue screen of death! Even at the gas station !?
Read More
In my previous post , I announced my intention on writing a series of posts talking about my recent experience with data warehouse build out in agile transformation of EDS for a Fortune 100 company. Let’s continue our discussion on this interesting topic.
So, what exactly it is? What do I mean by agile data warehouse build out?
First of all, let’s talk about Data Warehouse in general. A data warehouse initiative typically involves building out data structures in the enterprise data model, pulling data from multiple sources, doing some (data) transformation, and then ‘parking’ them into the target data structure. Sounds about right?
At a high level, at least, this is the work flow for a data warehouse build out. To get to next level of details, your data warehouse build out includes:
- 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
To summarize, a typical data warehouse build out contains of following work flow (of events):
 |
| Typical workflow for a Data Warehouse build out [Please note that we will be modifying this as we discuss the topic further] |
Now, let’s talk about Agile data warehouse (ADW). By ADW, I mean:
- 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 🙁
Let the customers’ need be your guiding beacon!
[Next post: Know thy customer!]
In my previous post , I announced my intention on writing a series of posts talking about my recent experience with data warehouse build out in agile transformation of EDS for a Fortune 100 company. Let’s continue our discussion on this interesting topic.
So, what exactly it is? What do I mean by agile data warehouse build out?
First of all, let’s talk about Data Warehouse in general. A data warehouse initiative typically involves building out data structures in the enterprise data model, pulling data from multiple sources, doing some (data) transformation, and then ‘parking’ them into the target data structure. Sounds about right?
At a high level, at least, this is the work flow for a data warehouse build out. To get to next level of details, your data warehouse build out includes:
- 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
To summarize, a typical data warehouse build out contains of following work flow (of events):
|
| Typical workflow for a Data Warehouse build out [Please note that we will be modifying this as we discuss the topic further] |
Now, let’s talk about Agile data warehouse (ADW). By ADW, I mean:
- 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 🙁
Let the customers’ need be your guiding beacon!
[Next post: Know thy customer!]
Event Description:
Event Date
Event Time
From: 12:00 – To: 13:00
Event Venue
TBD
Event TimeZone
US/Eastern
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 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
Announcing agileTwitionary – a marriage of Twitter bird and the Dictionary !
Our intent here is to bring very concentrated doses of agile terms’ definitions. These twits will take out all the unnecessary information from definitions of agile terms, focus on the essence and key ingredients of the it, create a concentrated potion and deliver to your mobile devices!
How to get this potion? Just goto www.AgileTwitionary.com, follow us @agileTwitionary, or look for hash tag #agileTwitionary
To these concentrated doeses of this potion, along with agile terms, we will also be adding brief about:
- Personalities that are shaping agile world
- Alphabet soup – Accronyms that you may run into
- Agile tools
This has been a fun project for us, and we think this daily, concentrated doses will benefit you, and add a little bit more value to your day! So, start hearing the chirps from @agileTwitionary !
P.S.
Got any comments? We would love to hear from you. Shout out at www.AgileTwitionary.com or send us email at admin@agileTwitionary.com
Announcing agileTwitionary – a marriage of Twitter bird and the Dictionary !
Our intent here is to bring very concentrated doses of agile terms’ definitions. These twits will take out all the unnecessary information from definitions of agile terms, focus on the essence and key ingredients of the it, create a concentrated potion and deliver to your mobile devices!
How to get this potion? Just goto www.AgileTwitionary.com, follow us @agileTwitionary, or look for hash tag #agileTwitionary
To these concentrated doeses of this potion, along with agile terms, we will also be adding brief about:
- Personalities that are shaping agile world
- Alphabet soup – Accronyms that you may run into
- Agile tools
This has been a fun project for us, and we think this daily, concentrated doses will benefit you, and add a little bit more value to your day! So, start hearing the chirps from @agileTwitionary !
P.S.
Got any comments? We would love to hear from you. Shout out at www.AgileTwitionary.com or send us email at admin@agileTwitionary.com
As described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.
As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.
Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.
Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.
Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.
If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.
UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.
Read MoreAs described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.
As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.
Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.
Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.
Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.
If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.
UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.
share the #Wisdome
