Thus, begins the new blog. I am
unsure how to go about introducing myself best or how best to start things off;
I suppose it is best to dive right in with what this blog will be about.
The purpose of this blog is to
share what I have learned, in the areas of database admin, data management,
business intelligence, and DevOps/AGILE. I will be discussing my opinion and
experience in these matters, and what I am continuing to learn along the way. I
have spent my career as a generalist, and I make no claims to be exceptional in
any of these areas, so if there is something I discuss that can be done in a
better, more efficient, or easier way, I am very open to feedback.
I currently work as a business
intelligence lead for a community college and have been responsible for
enacting business intelligence from the ground up. This has led to some
interesting challenges, as well as some interesting opportunities, along the way.
The primary opportunity is that I have been given the autonomy to enact the
program with the AGILE/DevOps methodologies.
Which will bring me, I think, to
the first piece I would like to discuss. Strategy design and management in
AGILE and DevOps. This stems from a pet peeve of mine; too many times in my
career I have heard that people are against agile, or anything based in agile, because
the times they have seen it used, it was an excuse to not plan, to not
strategize, and to not document properly. I need to make one thing clear: if
you are not strategizing your AGILE initiatives, you have set yourself up for
failure.
So how to do it then? Are we able
to plan out and strategize the same way we do in other methods? Not exactly,
but that doesn’t mean we don’t do it. In
a traditional waterfall style strategy build, we sit down and determine where
we are, where we want to go, the steps required to get there, and map those
steps out with milestones to measure our progress towards completion. This is a
tried and true method, and it does work when done correctly. My continued
concern with this method though, is that the strategy is based on providing
value from the project only upon completion. During the time that the strategy
is being followed, the milestones hit, and we stop to pat ourselves on the back,
we are not providing value, only consuming resources towards the promise of
value.
When we have changes along the
way; a change in leadership, direction, market, user group, or expectations, then
we are not able to account for these changes with the waterfall strategy. We
require a large amount of time and effort to account for these changes and
pivot the strategy towards the new goals. We also remain unable to provide
value until we complete the project. These sorts of delayed gratifications may work
in some industries. When we are providing insight through intelligence, analytics,
and data management however, the key is to provide value sooner rather than
later. To provide the tools, the
expertise, and the insights to enact appropriate changes, and to guide our
users with the best possible data we can.
We strategize this through
similar methods to waterfall.
- 1. Current State: We always begin a strategy with examining the current state. We need to know what tools we have, what is the current state of our data landscape, what are our gaps, and where do we need to improve. Part of this is also about finding out where we are in providing value to our users.
- 2. Future State: We need to know where we are going. This is the big picture outcome, that defines the direction of our strategy. In order to properly strategize, we need to understand what the future state will look like, whether it be through enacting self-service, completing enterprise ERD, or launching a centralized data warehouse. This future state is critical for defining the path to success.
This is where we will diverge
from standard waterfall strategy mapping. Once we have the future state identified,
instead of planning out all the steps to get there in detail, engage with all
the stakeholders at once, identify risks and mitigations, and documenting
everything ad nausea, we are going to take a slightly different route.
- I. First, we will break down the future state and identify all the parts of it that are divergent from the current state. We identify dependencies and determine the importance of each piece of the whole future state. We identify the areas that can be brought forward as value to the end users and lay these tactical initiatives out as a trail of breadcrumbs for the overall project to follow.
- II. We document this trail and identify the areas of value that are brought to the organization and the end users, and use these value-adds as the milestones to measure our progress.
- III. We begin the first of the tactical initiatives, launching into either an AGILE cycle or a DataOps/DevOps cycle to achieve success. Once we begin work in earnest we immediately engage with the clients or stakeholders and get them involved in this process from the ground.
I will be writing more on this
topic on future posts, so I hope you will stay tuned for this. Next week we
will be diving more in depth into the engagement model on the AGILE and DevOps
cycles, as I have been involved in enacting them.
Cheers!
SQL Doch
No comments:
Post a Comment