AgileData #9 - Adapting for a BI Lifecycle

Welcome to the Agile BI Podcast, where we chat with guests, or sometimes just to ourselves, about being agile with teams who are delivering data analytics and visualizations. Welcome to the Agile BI Podcast. I'm Shane Goodson.

I'm Blair Tampero.

And I'm Nikki McKenzie.

Hey Nikki, welcome and thank you for joining Blair and myself to have a little chat. I think today we're going to start off talking about the definition of the Kanban board, you know, why we typically start off with to-do, doing, done, done, done, done, and see where we go from there. But before we do that, what we typically do is get somebody that's joining us to give a little bit of background about where you've come from, how you joined this world of agile for data and analytics, and kind of give us a little bit of back history on yourself.

Okay, well, I'm going to start back when I'm back at university. I studied operations research, and that's about using maths to solve optimization problems. We learnt about things like just-in-time manufacturing, kanban, TQM, total quality management, and things like queuing theory. And it's really good to see that now these kind of techniques are being used and applied wider than just manufacturing. So I started off, my first job was in customer service. I was providing information requests. And after that, I was a marketing analyst doing direct mail campaigns. Providing the data for that. And I did my OAE in London and I worked for a small data analytics consultancy and that's where I got into data warehousing. And I've been an ETL developer for years and now I'm leading a team of developers with an agile mindset.

Cool. Yeah, I mean, for me, I suppose when I'm coaching teams, I know we should be doing burn-down charts, we should be understanding, obviously, the team using data. Yeah, we should be data-driven. But it's one that I've always struggled with a little bit. I know Blair, we stole your burn-down chart magic spreadsheet the other day for a customer. That's okay. But Blair's obviously, well not obviously, Blair's been a lot stronger as the Scrum Master in managing that. And for me, one of the things I always start off with is working with a team, well not always, I've started starting off with, is explaining to the squads and teams that I'm working with the choices between an iterative approach like Scrum and what it does and the way it gives us unnatural constraints, but that helps us versus a flow-based approach like Kanban or Lean and, you know, how that works. And when I look at the boards, if we take a flow-based or even if we take a Scrum-based approach, you know, starting off with to-do, doing, done, done-done, kind of forces the teams to break their behaviors. When I start off with, you know, requirements, you know, more of a pipeline or an SDLC approach, even those things we do, as soon as they're on the board, we get into natural waterfall behavior with handoffs, right? Oh, that's the requirements bucket, I'm the BA, you know, oh no, I'm an Agile developer, I can't do that. Even though they have the T-skills, So I've always kind of started off with that to-do, doing, done, done-done, because it forces a team to start behaving differently. But from your point of view, how are you finding it?

Well, when I've worked with cross-functional teams where there have been analysts, testers, and developers, I found that the testers pretty much just want to do testing.

Yeah, we found that as well.

And I actually had to go and talk to the test manager to say, will you let your testers do some analysis? And I got agreement. And then they started doing analysis. And they're really good. Testers are really good at analysis.

Yeah, it's a great— they have that T skill naturally, typically, right? Yeah. A tester is typically good at analyzing something. I suppose my theory is because they've got to analyze what the requirements and the developers were doing to figure out what's a test that has value. And they've always done that naturally. Yeah. Do you think though that one of the problems is you had to talk to a test manager, right? So if we're talking about agile and agile mindset, agile ways of working, they should be a self-contained team, right? They should be in charge of their own destiny and the way they work. As soon as you have to go and ask a manager whether a member on that team can do a task, we've kind of broken it, right? We're trying to develop in an agile way, but actually our organization, our business agility is hierarchical.

Yeah, and that's like a pocket of doing agile, and you've kind of got to try and fit it in with everybody else. We had a waterfall project that we were doing this for, and there was a deadline, so we had to work in with that deadline.

Right.

But, you know, we still had weekly planning sessions that I found worked really well. And because there were so many things that were changing, we had the environment, you know, the testing environment, development environment, that was all changing underneath us, and we never knew when we were going to get it. And so it was really difficult for us to plan any further than a week. And we also had our testers being moved off onto another project from time to time. They were a shared resource, so that was interesting because we never really knew if they were going to be pulled away from us.

So, I go through my checklist of things that worry me. So, first one I heard— yeah, yeah, here we go, here we go. So, I heard there was another project which had a deadline which no doubt was never scoped in terms of it being achievable, but you had to meet that. The things or the tools you relied on in terms of the platform and the environments were outside your— so you couldn't deliver them earlier or later, you were reliant on somebody else to give them to you when they could. The team that you had weren't dedicated, and not dedicated, often what we find is they're dedicated but they have to do BAU, right, so there's BAU bleed, that happens often.

Oh no, we didn't have that, it was another project.

But you got even worse, which is actually the resource will be removed from the team or the squad in the middle of doing that work. And I think the last one was what you had to deliver changed, or did I?

No, no, no.

Okay, so you kind of knew what you had to deliver, that was a given.

So was that other project waterfall, or was it another Kanban type approach?

It was waterfall.

Right, and were you engaged early in that waterfall process, or right near the end?

Well, it was going on at the same time.

Were you and your team engaged at the beginning of their waterfall journey, or right near the end?

It was right at the end.

Right at the end, just before they were about to go live?

Yeah. Right.

Cool, so what did you do? So you moved to a weekly planning iteration, right, to help manage that change and bring that flexibility, and that's cool. It sounded like you were using a flow or Kanban-based board.

We had a Kanban board, and we started off doing to-do, doing, done.

Right.

Yep, and so we put that on the board. It was before we had any— we didn't have We didn't have an electronic board, it was all a manual, um, sticky notes board.

Did you manage work in progress? So for each of those buckets, or glasses of water I call them, how many people were in the team that you had in the development team?

We had 2 developers and 2 testers.

Okay, so there were 4 in the squad effectively. Yeah. Did you limit each one of those buckets to 4 tasks, or 1 task, or as many, like, how did you manage the work in progress limit for each of those on the—

I didn't have a hard limit, but it was when we had our weekly planning session, we worked out how much we thought we could do in a week. We had a pretty good feel for that, and we just kind of had a guess. Okay. And just made sure there weren't too many things up there, so it was 2 or 3 tasks.

Right, and you just kept an eye to say, "Does it feel right?" Yeah. In terms of that. And then, I'm amazed how many ops research or science people get into data. It's a really, I I don't know why, it's weird, eh? Lots of, we had Kat Greenbrook on a while ago doing data storytelling and she actually came out as a, she did a science degree and was in a lab and decided she didn't like that, but then that gave her the background for analytics. So given your ops research, your statistical stuff around wastage and flow, how many of those techniques did you bring to the table with the team in terms of using data to help them understand where their blockages were, or at the moment are you still kind of gut, like intuition-based?

I think the thing was that it was difficult to see from the to-do, doing, done, who was doing analysis and who was doing development and how that was progressing. So we had a go at changing up the board so it had the SDLC along the top, so, you know, analysis, design, build, test, deploy. And then that gives a much better picture of if there's a whole lot of analysis going on and then not much development, then you know you haven't got a balance.

If I go back to what I found when I've done that at the beginning of going on the journey with the team is they become waterfall or pipeline-based. So, you know, I'm going to do the requirements and then I've stopped and somebody will pick up the design. And even, you know, a lot of really good requirements people can actually do the design. If they're given a pattern. Did you find that they started off with that, that's my bucket and I'm not going to move across?

Yeah, I mean, we did have developers who just did development. Actually, they did— no, that's not true. They did design development and they— well, the ETL development, and they also did the report development.

Okay.

Yeah.

So there was some form of T-skills and—

Yeah. And because of the way that project shaped up, we did a lot of the analysis up front.

Right. How much of that big guess up front, well, little guess up front was right?

Well, it was more the documentation of the information products. We had all those done up front. Okay.

And so that gave you almost like a prioritization process of what to do next.

Yeah.

Some visual way of saying how far through the waterfall delivery promise, you know, for that project.

Yeah, well, we had priorities on what were the most important things were, so If we ran out of time, we would have said, okay, we'll just do these two, because these are the most important ones.

Did you manage to get the information products down to a level where you could actually deliver an information product production-ready in a week?

We couldn't do it in a week. No?

Okay.

Alright.

I'm just, I'm interested. I've got one team I'm working with at the moment where actually they're almost down to 3 weeks. I think it was, they're rocking it. They're going from initial requirements to acquiring the data all the way through. Into a production-ready product almost in 3 weeks, which is the first time that's ever happened to me.

Does that include doing the ETL?

Yep. So that's wireframing, capturing the requirements up front, vision statement, wireframing. They're not using Beam, so they're doing some other way of capturing data requirements to defining the model, creating the ETL, creating the dashboard, peer review, documentation. They've done far more documentation than I expected, and they've all nailed it just about in 3 weeks.

How big's the team?

That's a squad of 4.

Sounds pretty similar.

They're a very experienced team, right, in their job. They just haven't done this agile thing. So they naturally wanted to pipeline big requirements up front, so getting to thin slice was the challenge. Challenge was always, right, how do you break that big information product down into smaller dashboards of maybe 3 metrics, not the 12, and then next time you add the next 3. That was one of the mindset changes.

Yeah, it's interesting, the team that I'm working with now, they do come from an agile background. The thing is that they don't have the experience in their organization to know the subject matter and the processes that we do.

And do they come from a Scrum or a So an iterative Scrum type process?

They've done a mix. They've done a mix.

Yeah. And how have they found moving into a new way of working that's kind of been put in place before they started? How did you onboard them?

They actually started before I came to the team.

Ah, right. OK. OK, so it's the other way around.

Yeah, so there was already a process in place. It was a Kanban doing to-do, doing, done.

Right.

And I've actually now changed that.

OK, good on you.

Yeah.

So now we've got a board that has the SDLC across the top, yeah, and I've done it this week and put up what they're working on, and I can see that there's a massive lot of analysis that's going on, and there's only a few bits of development.

Yeah, I was going to ask you about analysis, because we found that that was a bottleneck when we used Kanban. Yeah. So we've moved to actually removing a lot of that from from the development cycle and doing that up front. Have you found that as well?

What I've been thinking is that because we've got all this analysis, we're going to actually need some other people to come and help us with it.

Oh, you're making me nervous. So, so I've always had a problem doing analysis up front, right, because we do all this work up front without actually proving the value in there. And then as I think back, part of the problem was There was no way once we did the analysis that we had something that we could hand off to another person and they could actually use, right? The documents that we did, or the— there was a lot of context in there that we never disclosed, right? So the developer got it, they'd look at it, not even understand what to build, or they'd build something that actually wasn't what we meant. Now what seems to have happened is by adopting BIM and by adopting information products and vision statements and those user stories and wireframing and which questions we're going to answer, you know, a bunch of detail that we put into some form of pattern. It kind of looks like now it becomes a document that can be adopted by the next person in the supply chain, and they have almost enough to do their job. Um, yeah, business rules, the ETL rules themselves is the one I've just been working on now. But it's an anti-pattern for Agile, right? That we actually define something up front with one group of people and we hand it off to the next group of people and we're not all involved. And so, yeah, I'm just—

Yeah, I think this is something that I'm going to have to look at how we do this. And yeah, so your ideas on this would be welcome. Yeah, because we've got two teams now working side by side. And so they're They're a bunch of BI analysts and a bunch of developers.

And where the testers sit now?

We haven't got any testers at the moment.

But if you had them, they'd be a third squad, right? So we get into a mini Waterfall of Squad 1 requirements, Squad 2 develops, Squad 3 tests. And the problem I've always had with that is when we get to that third squad, right, where they're 3 iterations ahead, right? So in your case, they're 3 weeks behind, actually. So Requirements team's now on product number 3 doing requirements, development team's now on product number 2 doing development, testing team's on product number 1. When they find a problem, requirements team have to time slice back to what the hell did we do a couple weeks ago, developers, and now what you're also doing is interrupting their ability to develop or deliver the acceptance criteria for what they're working on.

Yeah, you've lost the flow, haven't you?

You've lost some of the benefit of agile. There's no collaboration, there's no focus on doing that, there's no just doing the work at the right time. Time. And so I started off mini-waterfalling, and I'm trying to do everything I can to move away from that.

It will also make it hard on the developers to have to go back and fix something that stopped what they're doing.

Yeah.

And, you know, Scrum 3 and move back to Scrum 1.

So while for me having SDLC on the board has value because I want to see the flow, right, I want to know that actually, where's the blockage, right? If we have work in progress, so work in progress on doing, right? So let's say we have a squad of 4 and we're in doing and you can only have 4 cards. That has value, right? But actually having a visual cue of how close to finishing, done done, on that product are we, unless you can see the pattern, it's a little bit hard. So introducing that SDLC flow or that supply chain, I think I like to call it now, So you can visually see, actually, no, there's lots in to-do that are still kind of requirementy, requirements full, there's nothing, or, you know, we're bubbling. You can bring in some of your OR stuff around, actually, what do we need to tweak, where do we need to focus to improve that throughput? But if we're mini-waterfalling—

Yeah, so what are you suggesting then? Perhaps we take, get the developers to spend more time on analysis before they do any more development.

Yeah, yeah, yeah, and then get the developers or the BA skills people to spend time around testing or documentation. So it's not easy, it's not easy to take that entire thing and slam it into 3 weeks, but it looks like it's possible. But what we have to focus on is those thin slices, right, the not done, you know, how much, what's the least what we can do to get that puppy through, and then I suppose what I'm describing now is icing, right? What's the minimum amount of icing that we can do for the first layer of icing, and then once that's on the cake, we put the next level of icing on, and we just build up those icing layers.

And we found it hard to, because we've also got functional teams, so we have team leads and an actual functional development team, data team, testing team. To get those individuals to start using some of their T-skills and go cross-functional was actually quite hard. So even though everyone has their T-skills, you know, to get them to move away from their function is quite a mission.

But if we look, when you first started your journey, you didn't have that.

No, that's right.

We started off with a single squad of T-skills. With no organizational hierarchy, and then you move your organization, move to those functional hierarchies for pastoral care.

But also to enable us to scale easier, to upscale.

Yeah, has it worked? I'm really interested because it's an Andy pattern.

It has.

Introducing Andy pattern.

It has in terms of being able to scale up.

You're effectively doing what Nikki's doing with her team, or being forced to do with her team, at scale. So what have you done about the mini waterfall, the handoff, the where we're at, the rework, the time slicing? How have you managed?

It's a daily challenge.

Okay, right.

We haven't nailed it.

So yeah, it's a case of working on encouraging people to do more than just their core skill, isn't it?

Yeah, and often this is one of the challenging conversations which, you know, I have with teams all the time. Somebody will say, 'But that person is better at it than me.' And I'm like, 'Yes, they are, but are they busy at the moment?' 'Oh yes, they're working on that.' 'Right, is that the highest value task in this and what we've promised right now?' 'Yes.' 'Cool. Is there anything else you can do that has value that's on the board?' 'No.' 'Right, so you might not be the best, but you can do it. You might be slower, but you're still moving it, so We either waste the points.

Yeah, I think getting that buy-in for people to actually pick something up and do something that they're maybe not as comfortable doing.

It's really unnatural, right? It becomes— it's an unlearn-relearn behaviour that actually, yeah, doing the thing that you're not the best at is still—

Do you think that's where coaching comes in? Do you think that's where you need to have somebody sitting with them and helping them?

Yeah.

Or a technical person.

Sitting with them a lot. It's a coach, it's a coaching behavior, so it might be the Scrum Master, it might be an Agile Coach, it might be an experienced person in the squad that has done it before and can help them, but it's a coaching, not a talent.

Yes, so we want to get away from situations where somebody's sick and, oh no, we haven't got a Developer today, we'll have to get another one, or we haven't got an Analyst because they're They're on annual leave, we have to wait for them to come back. That sort of behaviour is really easy to get into, and we're trying to avoid that. And it's like, the developer can pick up and do some analysis.

Or what skills do we need to do to give the developer those skills over time? Right, because again, it's, um, if the developer's happy to become a T-skilled individual, right, and that's actually one of the core conversations, we have to invest in that person gaining those skills. So, like, one of the teams I'm working at the moment, you know, they made a— they had to make a decision. They have a number of technology platforms, and they had to make a decision whether the squads were technology-bound. So, you know, we've got Technology 1, is there a squad that are good at that? And we've got Technology 2, and both those technologies are going to stay around, right? We're not going to lose them. And we've got the new technology, right? The new cool shit. So is there a squad that just does new cool shit? And my experience actually, did it with you guys to begin with, was when we ended up with the cool shit team and the boring BAU team, it was really sad on the boring BAU team, right? 'Cause they weren't getting new skills, they weren't learning new things, they were just doing the dross. And a second behavior happened which was really bad was the new cool shit team actually knew that if they didn't quite get done it would go over the fence to the BAU team and they'd wear it, right?

Healthy competition.

Yeah, but the BAU team really couldn't pass it back to them and say, "It's not done," right? That's not done done. So yeah, you kind of could get away with not quite being done done. And so I didn't like that, but yeah, that behavior, I didn't think was good.

That didn't work. And we also toyed around with having a kōrnuša team and a team that was solely enhancing existing products. So they will possibly take something that the CoolShit team have done and add some functionality to that. But then you get into, why did you do that? You should have done that. So we found that didn't— yeah.

So right now my focus for teams is you own it, right? If we want true automation, if we want things to not cost us time later, or if they are, we're identifying those things or dear truly, then actually the team that built it should maintain it. Because you're going to keep your room tidy if it has an impact on you.

I think also with product ownership as well. So there's a concept in our organization that there'll be a product owner that will be in for the journey of building something, and then it will go across to a team that look at existing products and work on the lifecycle of those products. So I'm sort of humming about that because where is the love transferred?

Where's the trade-off, right? The core build product owner gets to trade, make decisions that cost catch the shit product owners, right? So I suppose if you're identifying that as technical debt, like true debt with a cost, and the money to pay that cost later goes to the catch-it team, then that might work. But if you don't, so again, a lot of it comes back to business agility for the organization. If your organization behaves in a way that an agile team will create something and then hand it off to another team to operate it, that's okay, right? That's still better than doing waterfall, but there's a consequence coming of that behavior. So same with the developer, right? Go back to, you know, if we say Team 1's on this technology and Team 2's on this technology, then if you're on Team 2, you're never going to learn the new technology. So this team I'm working with, they need to learn Python. One knows it, one doesn't. There's a natural learning curve for them.

We've got that problem because we've got 2 technologies, even with our small team, we've got 2 technologies. And so we've got specialists within the team, and yeah, so we're Yeah, we're trying to do some crossover, but that's more difficult, isn't it?

So peer programming is a way of doing crossover. Now, that's interesting. So when I start with a team and go, let's peer program, and they go, what's that? It's where two of you are staring at the same screen. They naturally go, oh my God, that's going to— we're going to get half as much done. Yeah, it's not going to be as efficient. But what I find is when they try it, actually they realize it's far more efficient. Because they don't go down rabbit holes, right? As an individual, you tend to go down a rabbit hole of something, and when you're pair programming, your peer's gonna go, "Uh-uh, why are we doing that?" Right, it's not important right now, let's just carry on. Second one is sometimes you'll strike a problem that they've seen before and they know some ideas, so they'll jump in and go, "Ah, look at ya." They're effectively, as they watch the first person working, they're effectively testing and peer reviewing as you go. So, you tend to get better quality code. And pair programming, I think, comes out of a lot of the XP practice, so it's been around for 20 or 30 years. So, I find that actually if you want to upskill and cross-skill, then pair programming is a great way of starting, but it's always a long, arduous conversation to get there.

So, does that work when you get a tester and a developer pair programming?

Yeah, I'd say if you've got testers that have strong T skills and developers that have strong development skills and you haven't blended those skills yet, then get your testers and your developers to try and say you have to be staring at the same screen when any code is written.

That's interesting because we have probably a waterfall approach of getting some requirements from the BA and they go to the tester and they go to the developer developer and they have their own way of building that into code and then—

Yeah, so I've struggled with that one for many years because I couldn't find a better pattern, right? So I looked at that and went, I hate that because, you know, again, we learned it when we did that work together. So I didn't like the fact that actually we have two lots of people writing code that does the same thing, one to develop the ETL and one to write the code again to test whether it was right.

Yeah.

I didn't like the fact that they both work off a requirements document, but as the development team became more agile, there was that continuous loop of feedback of, "Well, actually, that requirement doesn't make sense." And so they would iteratively work through with the product owner and that, and those trade-off decisions and refine that, but it never went back into the document. The tester never got it. So their code was based on what it looked like 2 weeks ago when they ran. There was a a natural problem. Um, well, yeah, that happened a lot. Yeah, yeah, yeah, yeah. Um, the, uh, we'd run it overnight and then we'd find there's a problem and now somebody had to deep dive. Well, was it the ETL code that was wrong, the testing code, or a divergence? And that took a whole other time. Um, so I didn't like that, but I didn't have an alternative pattern, right? Like, what's actually better? Um, so that's why working down this idea of using rules-based approach of testing using Gherkin has solved that problem, right, because we're writing a rule and now what we're doing is validating the rule, validating the code against the rule, validating the exceptions, not rewriting the code, and I found that that's a much better pattern, but it's a whole new set of patterns, a whole new set of skills, and one of the problems is there's still not a lot of software in the data and analytics space that does that for you, right?

To automate it?

Yeah, it's not out of the box, so we end up having to write it ourselves, and we know that writing our own software is part of the way we work. Not as expensive and hard, but there's not an alternative.

Yeah.

So, yeah, I don't know, how were you? I mean, did you have with your testers what I call the Excel approach? So, um, the developers are writing against the requirements, the The testers are having an Excel spreadsheet of all the tests they need to run and the code. Developers hand it off. The testers have a great time running through their checklist manually, or running the code, going back and highlighting all the mistakes, and we go back into that loop. But next time we do it, the testers still run through that manual, semi-manual testing process, so testing, retesting still is another week.

Yeah, we had that going on. Exactly what you've just said. Described, yeah, where you've got the testers coming up with their own code and the ETL developers doing their own code and the requirements changing. That's exactly what was going on.

But the alternative is we don't have testers embedded in the team, then we do what we call happy path testing, right? The developer writes some code, runs it, and they're happy that they've met the requirements, but they don't really have the T skills yet to go, what's the unhappy path? What are the That's what testers are good at, right? Looking and going, well, what happens if this happens to the data, right? And so I think that blending of those T skills together is really important, but it's hard. So yeah, if you can go back, Nikki, and sort it out and then make the next podcast with the blog, the pattern, the documentation for us so we can adopt it, that'd be great. So naturally, when you do a Kanban flow, you don't typically have this concept of an iteration. The idea is actually stuff just comes into the backlog naturally, whoever's in charge of it, when they see a slot next, they move it across so it can be picked up by the team. The team focus on flushing it all the way through so they can carry on. We focus on the speed it moves through those stages and any work-in-progress constraints that we putting in place to improve that. What you've done, it sounds like, is kind of— I'm not sure if it's called scrum-ban or kan-scrum.

Scrumban, I think.

Yeah, yeah, where it's a flow-based model to a degree, but you're again, you're still naturally putting constraint of some planning and some proof, you know, focus on what happens each week, which I do, you know, working with teams, actually do a lot.

Yeah, I find it really helps to focus and make sure people are working on the right things, because it's easy for people to just say, "Ah, that's— that one, I'm not really sure what I should be doing on that one." So, "Oh, I'm, you know, I'm really comfortable with this," so they just pick up the thing they're really comfortable with, but actually they need to get on and do that one that's hard to get through it.

Yep, we take the one that we enjoy or we know is easy to get that success, and we leave the blocker sitting there, 'cause it's sitting there as a blocker 'cause it's hard.

But you can see that story sitting there and gathering dust on the board.

Yeah.

Do you have morning stand-ups where you—

Yeah, we do have that as well, yeah. We have stand-ups. We've got, we have a stand-up with the analysts as well, and we've got people offsite, so we've got people who are remote.

Ooh! So that's pretty good. Another one on my checklist, semi-remote team, just to add that to the mix.

Yeah, so we have Skype meetings.

Right, yeah.

Yeah, and so that's, so we look at, we've got, we're using Jira.

Yep.

And so we have, we have that, and so I've just introduced the manual board, so I'm kind of figuring out how I'm going to keep that aligned.

It's hard.

Yeah. I could talk to you about that. Yeah. Okay, so Jira for the, for those that are remote, especially, I guess. Yeah. Do you have the ritual where the person that finishes the card gets to move it to done?

Yeah.

I found that's quite an achievement to actually, and as a Scrum Master, find it really hard not to move it myself.

Yeah, the one I find it hard is saying to the team, you can't move it to done done, that's the Product Owner's role. And actually, it was interesting with the team at the moment is the done column was getting flooded over time and it wasn't getting moved to done-done. So again, it was that conversation with the product owner, actually, you know, you need to do, you need to every day come and clear it to done-done for them because it helps them enjoy their success, right? And yes, I know it's hard, but let's just find that time. And if you're not sure how you know it's done-done, you know, because we're still learning with this team through acceptance criteria, it's fine, let's just have a quick chat to the team and you can make a gut feel that you're happy or you're not, but you need to give them feedback. Whereas one of the other teams I'm working on with, they've got very good acceptance criteria, and so it's quite a robust discussion when the product owner goes, "No, it's not done done," and the team's going, "Ah, hold on, let's look at the acceptance criteria." Bang, bang, bang, bang, you know, we've done what we agreed. And I'm like, "Yeah, okay, but I need this." Well, that's cool, we're just gonna make a lot—

So, new card.

There's a new card, that's fine, yeah, that's okay, change is okay, you know, New things are okay, but it's not slipped in there, right? We didn't commit to that for that series of effort. So that was kind of exciting.

I think with the physical board, the actual visibility of that card that's holding things up is something you just don't get in Jira. And we find that if it's sticking there and if it's a different type of card than the new ones around it that are moving, I've found that as well. Then we might have a ceremony or a planning session where we say, "Why is this not moving? It needs breaking up." Do you have that sort of thing as well?

Oh, we haven't done that yet. It's a pretty new team, so we're still finding our feet, really.

I think one of the things I would really like is, especially with the paper boards, because I still think that electronic boards for some reason stop our conversations a bit. But when we have partially remote teams, it's a nightmare. But one thing is pattern recognition. So with one of the teams I'm working at the moment, the new things they're building are kind of yellow stickies, and the BAU stuff is a different color sticky. So you get a visual— it's quite interesting— a visual pattern of how much BAU versus information product development's happening. I'm just wondering, with your your flow board, maybe have kind of a visual pattern that as you see a task or a card kind of getting stuck, find some way of visually moving it to the top of the board. So almost, I'm not sure I'd create swim lanes because I'm not sure I'm comfortable putting it in as a solid line, but start visually moving that card to the top and leaving the other ones to the bottom, and then the conversation is, look, this task has been sitting there, it's kind of rising to the top of the glass as being sitting there for too long. Now we've got to define what too long means, but do it gut feel to begin with and see if that visual cue of, okay, that one just needs to be done now, uh, actually starts helping the behavior. And then if it doesn't, maybe start reinforcing it with data to say, well, 'You know, this one's been sitting there for 5 days, maybe we should introduce a data-driven rule which is, you know, a task can't sit there for more than 3 days unless it's blocked, right? If it's blocked, then it should have something on it.' This other one we did was we introduced block icons, so again, you forget what works, so we have a magnet and if you're blocked on a task, you whack it on there because then you're allowed another task as a it's blocked, right? So we kind of walked in and there were like 4 cards there for a person. It was like, what? But 2 of them, because they were remote, hadn't been moved for them. One of them was blocked, and so they introduced the next valuable piece of work to be done.

Yeah, we've used that as well.

Yeah, so that blocker, and then what happens is everybody comes in and scans the blockers, right? Yeah, they're, oh, that's blocked, what do we do? But without that visual cue, the card kind of limits.

Yeah, when we were doing that, it was sometimes You had to make sure someone was actually following up on that block, because that block could just sit there for ages, and then you don't know what's happening, like, why is it blocked?

Yeah, we had a similar situation where we were waiting on decisions to be made by the product owner, so we'd give it a nice yellow sort of highlighted sticker on there, just to show what we're waiting on.

Yeah, I struggled with that one, and that What do we do with the card that's waiting for somebody else? Not done to done done, but do we move it back to to-do, or do we move it to another place on the board where it's highlighted that actually it's not blocked, but we're waiting? You know, do we have another column which is waiting, and then we move it in and out?

We have another icon for it.

Yeah, yeah. But I think we need some visual clue, which is the team have done everything they can, they're now dependent on something else.

Yeah, and we've brought stories into our Scrum backlog that they've got past our sort of test of, is it actually us that's going to be doing this? And it's not until we see that card lingering around that we realize that, well, it's not actually us that are doing it, so we can park it somewhere. And as you say, there might be another place on the board where you put external things that you're waiting on, decisions, that sort of thing.

So it's kind of blocked, but it's kind of not. But then if we go back to the definition of blocked, the team has got as far as they can, they're reliant on something happening for them to finish. So really, that waiting on somebody else is a form of blockage, right?

Yeah, and it's also an impediment that Scrum Master is probably responsible for.

Yeah.

Busting down.

So I think I'll go back to answer my question, which is you put the block magnet on it and say, I'm blocked, right? I'm not, you know, I'm not blocked because of a technology problem or access to the data, or I'm blocked because somebody else needs to do something for me to finish that off.

We end up having a list of what the blocks are on the side of the board. And yeah, so they were all listed out because there were some things that were blocking that were taking a long time to solve.

Right.

Yeah.

Is that because you're reliant on another team for platform and environment and those kind of things.

Yeah, we almost had a decision register that I quickly discounted because it sounds waterfall. Decision register, risk register. So we compromised with the yellow stickies.

Okay.

Close.

What were the yellow stickies?

These things are waiting on a decision by the business Ah, right, okay, yeah, okay. Right, I use, I actually do use decision registers, but I use them slightly differently. So for me, we keep a very small form piece of documentation of the context of why a decision was made. Right. So, you know, if we're going to do something and there were a number of choices, often I find it's important for the team to document the choice they made and the context in which they made it. Especially around technical debt, right, when we're cheating, when we go, look, we know we should do that, but actually for these reasons we're not going to. And then we just get them to put out a really small piece of text that gives context on that decision. But yeah, so the next person or next team or next time you come back in a couple of weeks with your testing team of why did you do that, you can actually go back and see the context. But maybe Maybe I should change that to context register or context rules or something like that. Not context rules, context register of what was the context of that at the time. Excellent. All right. Well, it looks like we've got to the end of that one. Anything else you kind of— So yeah, look, I think in summary, I tend to go to, to do, to do, doing, done. Dun dun, because it helps move away from a traditional way of working with a data and analytics team, but ideally moving back to that flow based off, you know, the steps in the supply chain for getting data from one place into some form of visualization or data service when everything else is sorted. But that's really only because it's kind of worked for me over the last few years. So it's good to see that you're kind of ripping straight into that and then just focus on the things that are important, right? The things that the team need to improve on to get better at what they do. So T-skills, how do we hand off without having loss of that insight or context? How do we not have to time slice back 2 to 3 weeks and what we're working on then, how the testers become a core part of the team. But we all know that that's the perfect way of doing it, but we always start slowly and move towards it.

And I just love the fact that the physical board is not dead. You know, standing around as a team in the morning, looking at the board, moving cards, is something that you just can't replicate in Jira.

Yeah.

So I tip my hat to that.

I agree. As soon as you get one remote member, it becomes a nightmare. There's actually a book just come out that I haven't bought yet called, see if I can find it, Working in an Agile Way with Distributed Teams. So an Agile coach who's done nothing but work with distributed teams for a long time. So him and somebody else have written a book on that, I heard on a podcast. So I've got to get around to buying and reading that because I'm really really interested because a lot of the teams I work with now, at least one member is distributed. It never used to be the norm, but it seems to be.

Yeah, with Skype it really helps because we're on the phone a lot.

Yeah, yeah, yeah. So we're starting to get some tools that help us, but like you, I still love the physical board. Yeah. Yeah, until we get virtual reality Matrix-y, swipey swipey. We're all, for the people that can't see us, which is everybody, we're all doing the Matrix swipe. Or the Minority Report. Minority Report, that's the one I like. I was thinking of, that'd be cool. Alright, well, I think we'll wrap that one up. Thank you very much for your time, and we'll catch you all later.

Yeah, thanks a lot.

Thank you. Goodbye.

You've been listening to another podcast from Blair and Shane, where we discuss all things agile BI. For more podcasts and resources, please go to agilebi.guru.