on October 17, 2019
In this video, Freyja the puppy and I talk about a recent workshop which I facilitated at the IDC DevOps conference in London.
We cover:
- 01:45 The workshop methodology: about the Lightning Decision Jam Session, by AJ&Smart / Jonathan Courtney. I think this is a great format, and you may want to use this yourself for a workshop with your team (on any problem-solving topic)
- 05:33 Key findings from our group about how to overcome the top obstacles to Continuous delivery for databases
A transcript of the session is below the video.
Transcript (edited a bit for clarity)
Hi, I’m Kendra Little. I’m a DevOps Advocate for Redgate
What this means is that I get to spend time talking to folks and thinking about the patterns and practices that help people successfully develop and deploy stable changes to their databases, that bring value to the customers of these organizations.
Recently I went to a conference that was really great– it was the IDC DevOps conference in London. At this conference, I really liked the format. In the morning we had a series of presentations, and in the afternoon we had workshops where we talked about different problems and potential solutions.
These workshops were collaborative
I hosted a workshop, but I didn’t get to just get to tell the whole group: here’s how it’s done. That wasn’t the point!
The problem that we were solving in my group was how to overcome the top obstacles to continuous delivery for databases.
What we zoomed in on was the fact that when you’re starting out on a journey to implement Database DevOps, you’re working across silos. You’ve got the database folks generally working in their own silo. You’ve got developers generally working in another silo, and the larger the organization the more complex it can be to establish new processes between these two groups, because they have different ways of working.
Starting out at the workshop, a lot of people at the conference were in different phases of implementing DevOps, and many were early on. So we did this exercise that not everybody was bought into at first.
This exercise is built on a format called the Lightning Decision Jam Session by AJ&Smart, and that itself is based on a great book called Sprint. It’s about design thinking.
Here’s a little bit about how the workshop goes..
You have everyone take a stack of either paper or post-it notes– having something sticky works well though. Everybody privately writes down different potential solutions to how could we make it easy to get people to take on the new processes required for database DevOps.
1. Generating solutions
Everyone generates these solutions. You focus on quantity, not quality. The idea is that everyone should just start generating ideas, because it’s like brainstorming but without the pressure of having other people listen to your ideas. You’re just recording them on sticky notes. You have a time limit for that, and we did about ten minutes of people generating their solutions.
At first some people were like, well, I don’t know what solutions I have for this because I haven’t done Database DevOps successfully!
But the truth is most people in the group had gone through IT changes and seen what worked well and what didn’t. Most people in the group had observed a lot of behavior among their co-workers and seen what’s difficult and what’s not difficult to get people to do. And also a lot of people at the table had gone through Agile transformations for their application tier, and had seen what worked and didn’t work for that. Everyone already had a lot of reference material to work from.
2. Voting
After you generate all these solutions, you come together. Each solution needs to be legible because you’re not gonna defend them, you’re not gonna explain them. What happens is the facilitator puts them up on a board – we just used a wall in the room. You spread them out on the wall and you equip everyone with either voting dots or a pen. Everyone reads silently reads all the solutions and puts dots on the one that any of them that they think would be viable.
Now, you’re not limited. You can vote for as many of these as you want, but the point is that you don’t vote for your own because you already submitted yours– you already kind of voted for your own. Everybody silently votes on these using dots. The idea is not to do a bunch of talk during this, just read them and vote on them.
3. Filtering
Then you do a filtering process. We filtered out anything that had less than three dots. These aren’t terrible ideas, necessarily, these are just things that the group doesn’t think are gonna be the most effective. That narrows down the window of what you have.
4. Effort / impact scale
Then you take down the ideas that pass the dot filter, and you arrange them by the amount of impact they have in the amount of difficulty they’ll be.
This is where having an axis drawn on a whiteboard can come in handy. We just had to imagine the axis ourselves, but ideally you’ve got a vertical access which is the amount of impact a suggestion will have on the organization / the amount it’ll help you solve the problem. The horizontal axis is how difficult it is.
Things that are very far to the left and very high up will be very high impact and not a lot of work. You can also have things that are high impact and a lot of work (top right quadrant). You can have things that are low impact and a lot of work (lower right quadrant). You have things that are low impact, but they are not a lot of work, either (lower left quardant).
We arranged all the ideas collaboratively on this scale.
This led us to identify things that are high impact but not super duper challenging to do.
The findings that the group came up with were…
1. Version control
For the top three things that help people overcome process obstacles to initiating change for continuous delivery for databases, our group found that establishing version control for database code is number one.
Version control is the foundation of so much collaboration between people that you really need to get code into version control and focus on that. This isn’t always the simplest thing in the world, but it’s really a necessarily necessary enabler for everything else.
3. Minimum viable dataset
The group also had a concept of a Minimum Viable dataset. I loved this point: in order to successfully do development work, we need a copy of a dataset that enables progress.
In some cases, if production is a 10 terabyte environment our Minimum Viable Dataset for development might be much smaller. This viable data set may need to replace sensitive data that lives in production with non sensitive data. In some environments it may need to be synthesized. But we need to have this to support this work.
3. Constant communications between teams
The third thing that the group found is this enabler to break down these silos between teams and get database DevOps going is constant communications between the teams. We need to have teams really working together to establish these new processes, and we need to have the teams listening to one another.
Enabling all of these: an executive sponsor
Additionally, in order to enable all of these things to happen, if you can identify an executive sponsor who can meet with the teams on a regular basis and emphasize how this project meets organization goals, it helps these teams to work together.
For cultural change, it’s good for teams to know they are being supported by the organization at large. That is an underpinning that can help this change go through.
This was a really fun workshop at the IDC DevOps conference. Every time I’ve done this exercise, I’ve been impressed at the insights that come from the group– which is always so much fun because at the beginning the exercise there’s so much doubt as to whether the team knows enough to overcome the challenge! But in this case, we certainly did.
Thanks for joining me for this talk. I’m Kendra little from Redgate– and this is Freyja, our local expert on Corginetes who has joined me for this quick video. Bye folks, I’ll see you again in another video soon.