Need some rocket fuel for your DevOps team? Look at agile data?

If your DevOps team is the rocket engine for your agile delivery processes, then effective collaborative data management should be your rocket fuel.  -Brent Reed

As IT departments continue to embrace DevOps, the lifeblood of our products and services is data.  Thus, we need to include in our “way of working” good agile data practices. By the way, Scott Ambler Co-Founder of DA wrote the Data Modeling and Agile Data book on this and blogged this eons ago in much more detail.

For this blog, I am going to suggest three areas to help improve the ability to bring the concept of agile data into your delivery and operations.  

Stage 1: Agile Data Modeling

When we start the process of a shared vision (what PMI DA calls the goal “Common Vision), of what we want to achieve, it is essential to ensure we include goals, decisions and the options we desire or may want to explore. The team should be open to doing some early light data modelling with data experts and support staff.  

  • During your initial discussion, such as requirements, why not model the system using a current and future state (i.e. high-level UML diagram). 
  • Next, explore data entities and structures. Start from the domain level and iterate through the logical and physical models over time, the lower level semantics required to develop the next level of detail. This kind of data modelling is what I refer to as “Evolutionary Data Modeling.”
  • Collaborate and model collectively, with not just the architects, include your administrators, product owner, help desk and others as you develop the models

There are many reasons why the above points are what I believe are essential data modelling strategies. For example, the first point when discussed, even in a short modelling conversation, can uncover the need to consider, various types of data, locations, legacy or new data sets, need to refactor or replace, the need for flat or cube data, data warehouse and business intelligence concerns. Thus a connection and feedback loop are essential to unlocking the right conversations when doing agile projects and especially critical to DevOps becoming a maturing and the rocket engine to your speed to market for business value, and hypothesis-driven design. Don’t get disrupted, & replaced, you need agile data and business agility to keep ahead of the competition (or a lurking competitor).

DevOps Workflow

Figure 1 Data Management & collaboration equals success

Stage 2: Agile Data Management

When considering your data objectives using a set of hypothesized or validated goals for your product, a Data Management Goal in the image below, is a great start:


Figure 2 Data Management Goals 

The above figure includes a fair amount to ingest & understand.   However, there is little doubt that effective, collaborative data management opens discussions and evolves many of the agile delivery and DevOps practices not yet realized.   Thus, a focus on data management goals begins the conversation to a strategy that is enterprise aware and includes patterns for reuse of information services. this approach helps us to shift left focusing on value, can reduce costs, technical debt, and increase quality and value in a very short time.  Planning data management is a must, and its part of the rocket fuel required, for high-performance teams in DevOps.

Stage 3: Connections, Feedback and the big picture

When we apply disciplined agile to our way of working, the feedback and continuous improvement goal is included and thus already baked into the project cycle. This great, and using this process by understanding the feedback loops, especially around our subject of discussion (Data & Information), is connected to the “enterprise awareness” DA principle that is key to unlocking agile data. Thus we need to reflect on our understanding of our internal and external lines of communication. I cannot emphasize how vital knowing whom our stakeholders are and identifying how and when we engage with them because the nature of agile data is “highly collaborative.” This means that the agile data strategy approach is very different than the traditional data strategy approach because of the nature of agile being flexible and the connection to DevOps, which looks at continuous “flow,” “feedback,” and “learning.” Considering these points also mean that we should model early on in our agile way of working to identify and develop streamlined ways of getting information to and from our stakeholders. This “streamlining” of data conversations works in harmony with the natural approach to speed and flexibility with the agile delivery methods and support the maturity and value of DevOps. Thus with the agile data strategy approach of documenting incremental change though what Scott Ambler calls “JBGE” just barely good enough lean documentation and governance, we can keep the velocity needed while retaining the right amount of information and context in our delivery process. Once again looking at the diagram below we still document change lightly and ensure we are transparently sharing and collaborating with our stakeholders using “lo-fi” a’ la whiteboard and photo, modelling techniques initially and then decide if a further value gained by using “high-fi” or digital modelling tools and techniques.  

Core to Data Agile Data is collaboration

There is a ton of concepts here; however, nowhere near as much as I could have covered, that is why we provide training and coaching at Tactec. While this blog is way beyond my intention to go into more levels of detail such as adoption, the transformation from traditional to agile and the big agile data picture, I hope I have been successful in introducing you to the subject of agile data, along with important data modelling concepts. I do plan on putting up a blog extending on the adoption of agile data within your organization; so, please reach out to us at [email protected] for a free hour of discussion and deeper dive. Additionally, please let me know your suggestions or anything you would like to share during your path to agile data and agile modelling.

You can, however, find out all this goodness here from the following references:

Share this post

Notify of
Inline Feedbacks
View all comments

Ready to level up your career?

Recent Posts

Add to Waitlist

If a course has an ‘add to waitlist’ button then it is likely booked up. Spots often become available so please fill out the form below. We will be in touch within 24hrs


Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Psychology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“