Strategy in AGILE/DevOps

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