← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS Implementing Agile Practices for Data and Analytics Teams | Henrik Reich
00:37:49
Global Agile Summit Preview: Implementing Agile Practices for Data and Analytics Teams with Henrik Reich In this BONUS , we dive into the world of Agile methodologies specifically tailored for data and analytics teams. Henrik Reich, Principal...
Loading summary
Transcript51 lines
- [00:07]
Host
Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon. Hello everybody. Welcome to a very special episode, a bonus episode on this Global Agile Summit week. And for this episode we have with us Henrik Reich. Hey Henrik. Welcome to the show.
- [01:18]
Henrik Reich
Hello. Hello. Thanks.
- [01:21]
Host
So Henrik is the host of the developer track at the Global Agile Summit and he's also a principal architect and developer in the R and D department at Today Data and AI Denmark. He has a deep expertise in all things data, like oltp, olap and a lot more, of course. And he's a strong advocate for of agile development, automation and continuous learning. He also enjoys biking, music, technical blogging. You should definitely follow his blog. And speaking at events on data and AI topics. At the Global Agile Summit, we will explore and learn about many different types of Agile and how it's applied in real life. And Henrik is going to talk to us about working with data teams, which is a big topic these days. So, Enrique, let's start with why you think it's important to specifically talk about Agile data teams.
- [02:24]
Henrik Reich
Yes, it's a very good question. And the reason I think it's important is because the data is moving towards the principle of software development. And we have seen for a lot of the last couple of years that languages like Python is gaining more and more ground within data. At the same time, many people who work within data doesn't have an engineering background as many software developers. So the practices on how to utilize a programming tool like Python fully and make, what can say, a quality development and so forth is lacking. So that's why I'm thinking that it's a very important topic right now because we are seeing so much development within data and data is gaining more and more popularity. So it's yeah, it's important.
- [03:30]
Host
Absolutely. About a year ago we helped publish a book on agile software development for business intelligence projects. I'll put the link in the show notes. And there's a lot of that specificity that you talk about, but when you talk about data teams, you also bring in another dimension. So of course, one is the fact that people come from a data background, not necessarily a software engineering or computer science background, and they might need some of those concepts and practices that we've developed in over the last two decades or so. But you also about dynamic teams. Let's give our listeners a bit more of context. What do you mean by this dynamic team concept?
- [04:13]
Henrik Reich
Yes, as I work for Consultancy House, for example, the teams I work with, we have a lot of consultancies who also have customers which they have to go to once in a while. So when we are doing our planning, Sprint planning and so forth, we can only be certain there will be there so much time and that can change from Sprint to Sprint to Sprint. So it's also something we have to take account for and also think that's quite common in a lot of other areas. So yeah, in the perfect world we would have the static team with all the static members and so forth. But I have never seen that work in real life.
- [05:01]
Host
Yeah, that's true. In fact, in many project organizations we have that exact same condition or context. Right. Like where people are assigned based on their expertise and skills rather than being in a team for a long period of time. And of course this is true for rare specialties. Right. If you're a specialist in a specific environment or specific set of technologies where there are not too many. That's one. But also in project organizations we very often see people serving more than one team, therefore only being partially available to a team.
- [05:39]
Henrik Reich
That's true.
- [05:40]
Host
And of course this brings the topic, which is the topic we're going to explore today, which is this idea that Agile isn't a one size fits all. And you've talked about how there isn't a single Agile framework that works for every team. So when it comes to data teams, what are some of the unique challenges, and I should say data dynamic teams, what are some of the unique challenges that they face in adopting Agile?
- [06:09]
Henrik Reich
Yes, One of the biggest, what can I say, challenge is that people are different and we have a lot of people who have worked a long time with data and a lot of the tools used within data doesn't support Agile as well. They built around clickups and still to this day, companies, the big winters of data tools are promoting that. Okay, you, you can bypass all these practices around good practices by just clicking and then you have skipped a lot of steps and you, you are, yeah, ahead. But yeah, how can I put it? Yeah, the, the data in itself, the data industry and the tools have been lagging attention to agile development for so many years and all approaches to it has been, I won't say failed, but they haven't not been that easy to use. So I'm still seeing that.
- [07:26]
Host
So that's definitely one of the challenges that we have tools that are not necessarily adequate for the practice, like test driven development, for example. But what are other things, like what are other things that you think really make it difficult for an agile dynamic data team to adopt? For example, vanilla scrum.
- [07:52]
Henrik Reich
It is again practices and tools and also how you are trained. I see solution. It's not only data solution, but data solution as well. It has three parts. It has the people who has to do the things have to do solutions. Then you have the technology that can be the programming language, your tools and so forth. And then it can be the architecture and all these three has, you have to serve them. But if you give some of the three, one of the three too much attention, the two other surfers. So this triangle has perhaps been pointing towards the people mostly also. And again, what I see, the data people, I see and they're very clever and they're very good within BI and data and they're very good within databases. They are not trained in the concept of product development and best practices around that. And it can be sometimes perhaps difficult to see there's multi clickups because you might have to do these operations like 100 times within the next couple of years. So, and I think that might not have been exposed to it because a lot of training and training material comes from the vendors. So there's also an expectation around how the ways of working around these data tools are. And if these ways of working is just you can do your job very fast by just clicking these five buttons. You never get trained in how to do this and how it might be better to do it some other ways.
- [09:58]
Host
In the projects that you work, what are the fundamental challenges that you're trying to tackle to help these teams become more agile?
- [10:10]
Henrik Reich
First of all, we are looking into, okay, how can we deliver fast as possible, with most value as possible and still keep the good mood on the team? So our first approach is actually how can we make CI CD available? Continuous integration, continuous delivery. Some might have heard me say that, for example, you can get Agile library, you can do agile programming. The technologies you're using is enabling you, is enabling the agile. So if we would like to do CI cd, we need to find some development patterns which enables the CI cd and it might be okay if we use specific programming patterns in Python, we might encapsulate problems better and we might be able to use some board tool better to keep track of these. And we might only have a little something to integrate and to deliver. So it's more around the ways of working and the goals than it's the technology as such. But sometimes we are facing technologies where it's not possible and then we have to figure out what can we do instead. But at my department we are looking very much at, for example, okay, this tool is lacking the possibility to do CI cd. What can we do instead? How can we get close as possible?
- [12:02]
Host
Yeah. So what you're basically saying, if I understand you correctly, is that within the data environment there are still many of the good principles of, for example, object oriented programming, like encapsulation, that are not yet available to people who work with data projects every day. Right?
- [12:20]
Henrik Reich
Exactly, exactly.
- [12:22]
Host
And that poses challenges for what kind of tools we can then use and try to apply these more agile practices like cicd.
- [12:31]
Henrik Reich
Yeah.
- [12:31]
Host
So what are some of the solutions that you have found? Like, do you, do you have some examples of how, for example, to bring that CI CD enabling thoughts or patterns to the agile data teams?
- [12:47]
Henrik Reich
Yes, we have, for example, accelerators we built and we are building ways of working together with these accelerators. An accelerator at us is how can we make our consultants more productive as the customers? How can we get them to spin up a data platform faster? So it's not only based on the technology, it's also, as I said, the ways of working. And then we are saying, okay, we had some technology with a partner which didn't support CICD that well over the last year and we started small here also because they had something we could do a bit like that. And if it was tweaked correctly, we could actually do some CI CD and then we could later on base it on the version system and now we are basing it on API because they have API support now. So when we don't have the technologies in place, we are trying to find the next best solution and then we actually document our way out of it. It means again, it means again that perhaps the consultants might need to do clickups. It might take a little bit longer. So yeah, that's the way we have found work.
- [14:26]
Host
So it's almost like you take a challenge like, for example, we want to have version control and you take that challenge and you try to extract as much as possible from the context to allow for version controlling. But then there is a point where you can't add anymore, so you will still need to do things quote unquote manually. I mean, I remember when I started programming and the version control was the name of the file, underscore final, then underscore final, underscore final, then underscore final, final, final, and so on. Right. Like I remember that. And what you're saying is that many data teams are still at that level in terms of the availability of version control for their technology, so you need to find workarounds through defining ways of working. Right?
- [15:16]
Henrik Reich
Exactly, exactly. And again, you could say there might be actually some cases where cicd is not agile, but it's a way for us to get our work out to the customer as fast as possible. And that's what agile is in the end. So you can say CICD is an enabler for that. But there might also be other ways, like the version control you mentioned could, in a dimension be the best way.
- [15:47]
Host
Yeah, especially because many of these tools have their own quote unquote file system. It's not really a file system, might be just a database or whatever. But you can't necessarily hold the code outside the tool. Right. Like the code is inside the tool.
- [16:01]
Henrik Reich
Yeah.
- [16:03]
Host
So this presents quite a lot of challenges. And I wonder, Christian, in your, let's call it investigations in your research, what have you found? Are some common practices that agile data teams out there could start looking into and to bring in these aspects of agile development like CICD and version control, and even pair programming and debugging, whatever that might be.
- [16:36]
Henrik Reich
Yes, that's. Yeah, I have a lot of thought about that. My recommendation number one overall best recommendation as I see it, is to start small, to start and say, and I would not say you should ditch the frameworks we have now. This should stand as inspiration. But start small and say, okay, what task do we have? Okay, we have to deliver something to a customer. Okay, how do we do that? And then you can look at the Agile frameworks. What methodologies has it taken to do that? Then you can go to the next step. Okay, how do we develop this? How do you. Yeah, I see development and Agile and develop in general is like football. You have to practice. If you're a new team, you have to figure out how do the other players play and start from the other End I think if you come because, and it's nothing bad about the frameworks we have, but if you start out there and have to check all the marks around practices in these frameworks, I think you kill the team faster than anything. So start small and figure out how and what jobs you have to do. One problem regarding data is that it starts at grassroots. It starts at some point where somebody says, okay, we need something around data, because that's very popular and I can imagine also in this AI hype, it has much more focus. So I've been places where there's a little bit of conception that it fixes itself, it handles samples. But actually the biggest stakeholders within data is actually what was called the CXOs because they need the numbers, they need how to run a company, data driven. But very often we are seeing that, okay, we are missing stakeholders and we are missing owner for the project. And this should also be, it should be decided at the beginning of a project who owns it and who is the stakeholders. Because then you also start to get requirements. One, what can you say? One pitfall of not having a stakeholder is that the owner might perhaps put too much pressure on the team because the owners perhaps thinks, okay, how much can we deliver? We should deliver much as possible. And yeah, you will run without any guidance or anything. You run in plant.
- [19:46]
Host
Yeah, you talk about these accidental product owners, right? Like people who don't understand the role of the product owner, who don't necessarily even care about the details of the implementation that needs to happen. But we in the teams, in these agile data teams, we need to be aware that one of our perhaps success conditions, prerequisites, even will be to work with the client organization in order to find a stakeholder, a product owner who is actually able to give us feedback early on, right?
- [20:18]
Henrik Reich
Yeah, exactly. So what we do is that we don't have a concrete stakeholder. We are seeing all our consultants as the stakeholders and that's a lot of stakeholders. But our take on it is that we also spend some time on UX user research. So we have two hours per week where we have something called open office hours. So our consultants can be in contact with the team and say, okay, we need this, or this is a bulky or something like that.
- [20:57]
Host
So you're using this pattern where the consultant working in the client organization takes on the proxy product owner role and then does the work of finding within the client organization who can give feedback, clarify requirements and so on, right?
- [21:12]
Henrik Reich
Yeah, exactly. So we, we don't have one point of stakeholder product owner contact. We, we are spreading it out and we actually see it's very beneficial and yeah, it just seems to work for us.
- [21:36]
Host
Absolutely. And this actually highlights that principle of our idea rather that one agile does not fit all teams. Right. That we need to be kind of aware of the specific characteristics of the project and the organizations we work with and then deliberately adapt to what might be needed.
- [22:00]
Henrik Reich
But that's agile for me.
- [22:08]
Host
We need to be agile about being agile, right?
- [22:11]
Henrik Reich
Exactly, exactly. My biggest path to learning Agile is that when I find systems to be rigid, then I'm like, okay, this doesn't feel right. I have to look up what does it say. And it's also about my claim that the Agile framework, there's no one fit. And one of the things I've been looking into, for example, is that there's a lot of focus on the stakeholders, the product owners, there's all kind of concepts, but the team is always just a team. And I've been looking into. Okay, what about. Because we're also speaking about Personas, that's the customer who's going to take our product. But what about the Personas and the teams? Nobody describes that very good. I have tried to look it up and I came across where to describe. You can have specialists and you can have generalists and you can have a hybrid and you can have parallel. And it's like, it's very quantitative, excel sheet alike. And if you dive deeper into that, you read, okay, general lists. That's somebody who knows a lot but can't.
- [23:50]
Host
Not very deep.
- [23:51]
Henrik Reich
Yeah, yeah. And that's not my experience. My experience is that we are much more diverse as a team. You have people who are extremely strong at technologies, also broad and deep at the same time. So if I can quantize it in the same way, I would put people into two categories and there's nothing wrong with either category. But you have the people who code for living or live for coding. That's it.
- [24:29]
Host
And what are the key differences that you see between those two groups? The people who code for living and the people who live for coding, specifically in data projects.
- [24:42]
Henrik Reich
I can look at my own group. Okay. Most of them are living for code, is that this is a hobby for these people. They have another drive, then they have to make an income and support their home. And there's nothing wrong with that. I have to point that. But for them it's more hobby than a job and it can sometimes be a little bit difficult to control, but it also gives a lot of benefits. So yeah. And you can say within data we have a lot of the same work, especially when we work with structured data and bi and do report accountants and so forth. And if you are in the second group code for a living, you might fit very well into that one. But if you are on an RD product like finding out how do we solve this rd, you need to use a lot of creativity and you can box that and you can't time box that. As such, I don't know how to time box creativity. You can't really do that. And I don't think a lot of agile frameworks look into that perspective because it's much more about, okay, how can we predict the value for the customer?
- [26:24]
Host
That's actually a very good point. How do we organize agile teams for tasks that require a lot of creativity and are therefore not necessarily predictable in their delivery timeline or even the technology requirements that we might end up having? That's a great question. How have you guys solved that? Because of course you work with problems like this every day.
- [26:47]
Henrik Reich
Yeah. What we have done is that we had a dynamic team as we spoke about. We can guarantee we can be there all the time for the next sprint. So we have, we are looking at the individual and saying, okay, this person, he's well, very skilled, but some are just better to sit down and program and some are better to be around. So we're looking at, okay, the next sprint. This person can be a subject matter expert and give input to the people who has time to develop in the next spring. So there isn't a hard requirement that you should be able to produce some code or some SQL or some data at the end of the sprint. Being a subject, being meta expert or writing documentation or anything to give a little bit of progress, that's okay.
- [27:54]
Host
So, but, so what you're saying is that you try to focus on what are the strengths of specific people and you try to assign the work so that you highlight what they are really good at. So some people might be good at doing like deep research into a topic, others might be good at interacting with client, collecting requirements, clarifying the problem, and then you try to assign the work in that.
- [28:20]
Henrik Reich
Yeah, exactly. And I like one thing and I've taken from the scrum, it's sprint goals. If we can decide, okay, we need to be done with this within a sprint, that's very powerful because then everybody can contribute. If we figure out at the beginning a sprint, okay, we need to do this, then everybody, some might say, okay, I know something about it, I can tell you about it. Some might say I can write about it and some might say I can create it.
- [29:01]
Host
So kind of enabling the team to also volunteer their expertise in the context of that goal.
- [29:07]
Henrik Reich
Exactly. And it's so much more powerful because if we every. If everybody is just taking their own task within their domain, which they know much about, then you're not a team anymore. Then you're just individuals, single persons who are somehow sitting together. Team means work together. Right. So I think that's a very strong what's called tool within the Agile Toolbox.
- [29:42]
Host
Absolutely, absolutely. Great example. All right, Henrik, so if people want to know more about this topic, applying Agile in Data Teams, what is one resource that you would recommend to help them get started?
- [29:56]
Henrik Reich
Oh, that's a good question. So we have spent over a year on this and it hasn't been easy. There's also been some pain and so forth. I think a lot of us who is on the team has been developers for a long time, either within data or within application or both. So we come all with some foundation of agile, perhaps in different flavors. So we haven't found a source which saying, okay, this is the whole grail for this. So what I'm telling here is actually based on the experience I had with over the last year and working on this team.
- [30:52]
Host
Absolutely. This reminds me that one of the goals of the Global Agile Summit is really to bring up these questions. We don't always have the answers to the questions, but it's really important for us to come together around those questions so that we can provide experiments for the community to then try out and report back what they find. Right. Because we're at the conference, we might find someone, or you might find someone who has some data experience. You talk about it and then later on they try out some of your ideas and they say, hey, does this work great. And then they share it forward. Right. Like that's kind of the mindset. And I'm also reminded of one book that we helped publish here in the podcast. It's called how to Succeed with Agile Business Intelligence, Pardon me, where Rafael Brangard, the author, talks about their experience, their meaning IT Logics in Switzerland, their experience of trying to bring Agile to BI project, which are one aspect of data projects. Right. Trying to bring Agile to BI projects for several years. So it's definitely a great resource for those of you that might be interested in BI or data projects. Henrik, and how about you? What if people want to get in touch and know more about you and maybe ask a few follow up questions? Because I'm sure many of our listeners are facing the same type of challenges right now.
- [32:19]
Henrik Reich
Yes, of course. Just reach out on LinkedIn. I might also, as you mentioned before, I do plug it's most very technical blog, but I might also write off these things.
- [32:38]
Host
Absolutely. And we do appreciate people like you Henrik, who are so open and generous with their knowledge towards the community. So thank you very much for being here with us and for being so generous with your time and your knowledge.
- [32:52]
Henrik Reich
Thank you. And thank you for I could be here. It was great.
- [33:00]
Host
Hey friend, thank you for staying here is all you need to know about the Global Agile Summit if you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. Then 19th and 20th, the conference day. And Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at the product growth with his Lizard optimization tool Keynote. Other speakers include, for example Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on, for example, AI assisted test driven development, developing products in minutes with a different approach to how we develop configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile Business track where we will talk about, for example, Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendit's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations. Agile products for product managers, product owners and innovators. An agile developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and and want to learn. By challenging the ideas that don't work anymore at the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now at the Global Agile Summit. I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.