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 Gibson.

I'm Blair Temporary.

And I'm Nicky McKenzie.

Hey Nicky, 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. Why we typically start off with to do doing ducking, 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 learned about things, 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 wider applied wider than just manufacturing. Yeah. So I started off, my first job was.

In customer service using 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 OE 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 the team using data, 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 working with. But Blair's obviously. Well, not obviously. Blair's been a lot stronger as a Scrum master in managing that. And for me one of the things I always start off with is working with a team, 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 and what it does in the way it gives us unnatural constraints but that helps us versus a flow based approach like Kanban or Lean and 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.

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 SDC 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 on the ba, you know. Oh no, I'm an ETL developer, I can't do that even though they have the T schools. 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 they've 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.

So they have that T skill naturally. Typically. Right.

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 the test that has value and they've always done that naturally.

Do you think though that one of the problems is you had to talk to a test manager? Right. So if we talk about agile and Agile mindset, agile ways of working, they should be a self contained team. 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.

It's like a pocket of doing agile and you've kind of got to try and fit it in with everybody else. And 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, we still had a, we had weekly planning sessions. So I found work really well. And because there were so many things that were changing, we had the environment, you know, the testing 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. We just had 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 this one I heard. 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, you know, 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. Alright, well that's.

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

It was waterfall, right?

Yeah.

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 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 start 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 stick it 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 two developers and two testers.

Okay. So there were four in the squad. Effectively, did you limit each one of those buckets to four tasks or one task or as many. Like how did you manage the work in progress limit for each of those on the.

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

Right. And you just keep an eye to say did it feel right? Yeah, in terms of that. And then I'm amazed how many ops research or, or science people get into data. I don't know why, it's weird.

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 they're 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 and 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, that's my bucket and I'm not going to move across.

Yeah, I mean we did have developers who just did development and 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 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? Well, a 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 prioritisation process of what to do next. Some visual way of saying how far through the waterfall delivery promise 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. All right, I'm interested. I've got one team I'm working with at the moment where actually they're almost down to three weeks. I think they're rocking it. They're going from initial requirements to equilibrium the data all the way through to a production ready product almost in three 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. But they've done far more documentation than I expected and they've all nailed it just about in three weeks.

How big's the team?

That's a squad of four.

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 was always right. How do you break that big information product down into smaller dashboards of maybe three metrics, not the 12 and then next time you add the next three. That, that was one of the mindset changes. Yeah.

But yeah, it's interesting. The team that I'm working with now, they do come from an agile background.

Right.

The thing is that they don't have the experience in their organization to know the subject matter and, and the processes that we do. So.

And do they come from a scrum or so an iterative scrum type process.

Where they've done a mix. Yeah.

And how 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. Okay. Okay. So it's the other way around.

Yeah. So there was already a process in place or that it was a Kanban doing to do during done.

Right.

And I've actually now changed that.

Okay, good on.

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 the bottleneck when we used Kanban.

So we've moved to actually removing a lot of that 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.

You're making me nervous.

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 that. 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 the documents that we did or there was a lot of context in there that we never disclosed. So the developer got it, they'd look at it and 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 BEAM 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.

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, 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 a bunch of BI analysts and a bunch of developers.

And where the testers sit. Now the testers, 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 run 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 three iterations ahead. Right. So in your case they're three weeks behind actually. So requirements teams now on product number three doing requirements development, teams now on product number two doing development testing, teams on product number one 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. 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 stop what they're doing and.

Scrum three and move back to scrum one.

So while for me having SDLC on the board has value because I want to see the flow, I want to know that actually where's the blockage if we have work in progress. So work in progress on doing. Right, so let's say we have a squad of four and we're in doing and you can only have four 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 we're bubbling 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.

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 and then get the developers or the BAS 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 three weeks.

But it looks like it's possible. But what we have to focus on is those thin slices. Right. They're not done. You know, how much. What's the least we can do to get that puppy through? And then I suppose what I'm describing it 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 moved 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 andipet.

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.

All 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 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 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 a unlearn, relearn behavior 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.

It's a coach, it's a coaching behaviour. 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 coach and not a talent.

Yes. 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 on annual leave. We have to wait for them to come back. That sort of behavior is. It's really easy to get into. 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, if the developer is happy to become a T skilled individual, 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 at the moment, 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 one. Is there a squad that are good at that? And we've got technology two, and both of those technologies are going to stay around. We're not going to lose them. And we've got the new technology.

Right.

The new Cool Shit. So is your 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. Because they weren't getting new skills, they weren't learning new things, they were just doing the dross. And a second behaviour 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, that'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 behavior. I didn't think that didn't work.

And we also toyed around with having cool new shit team and a team that was solely enhancing existing products so they will possibly take something that the cool shit team has 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 technical debt, truly, then actually the team that build 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, 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 life cycle of those products.

So I'm sort of ho humming about that because where is the love transferred?

Where's the trade off, right? The core bill product owner gets to trade, make decisions that cost, catch the shit product owners. Right. So I suppose if you are 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? So if we go back to, if we say team one's on this technology and team two's on this technology, then if you're on team two, 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 two technologies even with our small team.

And so we've got specialists within the team and yeah, so we're trying, 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 gonna get half as much done. It's not gonna 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. As an individual, you tend to go down a rabbit hole of something and when you're peer programming, your peer's gonna go, that's not gonna work. 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. Yeah, 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 peer 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, the peer 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 for your programmer?

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 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 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. I didn't like the fact that they both work off a requirements document. But as the development team became more agile, there was a 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 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 two weeks ago when they ran. There was a natural problem.

Yeah, that happened a lot.

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 hold of the time. So I didn't like that. But I didn't have an alternate pattern. Right. Like what's actually better. So that's why working down this idea of using a rules based approach of testing, using Gherkin has solved that problem. 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 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 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 if there's not an alternative.

Yeah.

So here I don't know. How are you? I mean, did you have with your testers what I call the Excel approach? So the developers are writing against the requirements, 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 semi manual testing process. So retesting still is another week.

Yeah, we had that going on. Exactly what you described, 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 pass testing. The developer writes some code, runs it and they're happy that they met the requirements, but they don't really have the T skills yet to go. What's the Unhappy path. That's what testers are good at. Right. Looking at going well, what happens if this happens to the data? I think that blending of those T skills together is really important, but it's hard. So yeah, if you can go back, Nicky, and sort it out and then make the next podcast with the blog, the pattern 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. Herder's in charge of it. When they see a slot next, they move it across so it can be picked up by the. The team focused 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're putting in place to improve that. What you've done, it sounds like is kind of. I'm not sure if it's called Scrumban or Khan. Scrum.

Scrumban up here.

Yeah, yeah. Where it's a flow based model to a degree. But again, you're still naturally putting constraint of some planning and some proof, you know, or 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 easier 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 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.

Yeah, we take the one that we enjoy or we know is easy to get that success and we leave the blocker sitting there because it's sitting there as a blocker because 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, with the analysts as well. And we've got people off site, so we've got people remote.

So that's number one on my checklist, semi remote team.

Just to add that to the mix.

Yeah.

So we have Skype. We have Skype meeting, right? Yeah, yeah. And so that's. So we look at, we've got. We're using Jira 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. Keep that aligned.

It's hard.

Yeah, I can talk to you about that.

Yeah.

Okay. So Jira, for the, for those that are remote especially, I guess. Yeah. Do you. Do you have the ritual where the person that finishes the card gets to move it to done? Yeah, I found that's quite, quite an achievement to actually. And as a Scrum master, I find it really hard not to move it myself.

Yeah, I find it hard is saying to the team, you can't move it to Dundun. That's the product owner's rule. 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 Dundun. So again, it was that conversation with the product owner actually. You need to do. You need to every day come and clear it to done done for them because it helps them enjoy that 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 like, yeah, okay, but I need this. Well, that's cool. We're just going to this new card. That's fine. 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, kind of exciting.

I think with the physical board, the.

Actual, the 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, if it's a different type of card than the new ones around it that are moving. I 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?

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 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 of the things 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 vs information product development is 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 not sure I'm comfortable putting it in as a solid line. But start visually moving that card to the top, 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 been sitting there for too long now. We've got to define what too long means, but gut feel to begin with and see if that visual cue of, okay, that one just needs to be done now, 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 five days. Maybe we should introduce a data driven rule which is, you know, a task can't sit there for more than three days unless it's blocked.

Right.

If it's blocked, then it should have something on it. That's the 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 because blocked. Right. So we kind of walked in and there were like four cards there for a person. It was like, what? But two 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.

And there's that blocker. And then what happens is everybody comes in and scans the blockers, right? Yeah, they. Oh, that's blocked. What do we do? But without that visual cue, the card kind of length.

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. 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 struggle 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. 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 glue, 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 realise 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 busting. 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. And, yeah, so they were all listed out because there were some things we're blocking that were taking a Long time to solve, right? Yeah.

Is that because you're reliant on another team for a platform and environment and those kind of things? Yeah, yeah.

We almost had a decision register that I quickly discounted because it sounds waterfall. Decision register, risk register.

So we, we compromised with the. The yellow stickies.

Okay, close.

What were the yellow stickies?

These things are waiting on a decision by the business.

Ah, right. Okay.

Right.

Okay. 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.

So 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, we're. We go, look, we know we should do that, but actually for these reasons we're not going to. And then we just get to fill 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 I should change that to context register or context rules or something like that. Not contextual context register of what was the context of that at the time. Excellent. All right, well, 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 do.

To do doing, done, done, done because it helps move away from a traditional way of working, working with a data analytics team.

But ideally moving back to that flow based of 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 two to three weeks and what we're working on then how the testers become a cool part of the team. But we all know that, yeah, 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. So I tip my hat to that.

I agree. But 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 so you 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 someone else have written a book on that on a podcast. So I'm going to get around to buying and reading that because I'm really, really interested because a lot of the teams I work with now are at least one member.

Is distributed.

Never used to be the norm, but it seems to be.

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

Yeah, yeah, yeah. So that we're starting to get some tools that help us. But I like you. I still love the physical board. Yeah, yeah. Until we get virtual reality. Matrixy.

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. Minority Report. That's the one I was thinking of. That'd be cool. All right, 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.

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.