Digital Boards Vs Physical Boards Agile

Clayton Lengel‑Zigich: Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich.

Jade Meskill: I’m Jade Meskill.

Roy vandeWater: I’m still Roy vandeWater.

Derek Neighbors: I’m Derek Neighbors.

**Jade:** So like Still Water…

[laughter]

Jade: …is like because you’re European…What you?

Roy: We’ll mix up the verbs and other things.

Digital vs Physical Boards

Clayton: Quite, you’re so European, you don’t even know, to get the things up.

Today we’re going to be talking about Digital Boards and Physical Boards. Let’s say that I’ve got a digital tool and has my Scrum board in it. And I’ve a physical collocated team, is that going to be problem or can never just look at a computer screen.

You’re Brain Works Differently

Derek: Certainly, everybody could. The question is what are the benefits of a Physical Board versus Digital Board. Andy Hunt’s “Pragmatic Thinking and Learning” is a great book that talks about some of the brain science behind physically writing things down versus typing them into a computer, or versus seeing them on a computer.

It cements something different in your memory. I like to equate this to when I see great schoolchildren or even college students, being asked to memorize vocabulary words or terminology. Usually the teacher requests that they write them down, write them in a sentence, write the definition down. Then they memorize from there. They don’t just give them a printed sheet and say, “Go read the printed sheet and memorize it.”

It’s because something in our brain is wired differently when we actually do the act of writing things out. When you’re forced to write out the story or write out the sprint items or the tasks, I think that something wired different in your brain happens. The second thing is, nobody goes to their computer to look at all that stuff.

When there’s big visible charts all over the walls, it’s much easier for somebody not involved directly in the project, or somebody on the outside, to ask questions. They’re not going to go look at the chart in some digital tool eight things deep, find something out, and then send an email, or not very often. Usually it’s too late. If they’re getting to the point where they know something is that wrong and they’re looking at the tool, it’s probably too late to help.

Difficult To Hide A Physical Board

Jade: If you are physically collocated team, it’s much more difficult to hide from a physical board that has a presence in the room that you’re in, where it’s very easy to minimize a window and just essentially ignore everything that’s going on inside of the software system.

Roy: We’ve even seen examples where we would send emails of our burndown chart for example to everybody within the company or post a picture of it in the chat program we use, and still nobody really commented on it or noticed it even though it was being hand‑delivered to you saying look at me, it still didn’t really have the same effect as to something you occupy every day.

Jade: I saw a really interesting study that really talked about the brain and how when you move from room to room, that the doorway actually creates some physical barrier inside of your mind and that when you walk into a new room, it basically forgets everything about the old room. ref: Forget Why You Walked In The Room?

I started thinking, “Does that apply to windows in our applications”? Like when you minimized that window, does your mind like basically shift gears into, “Well, now I’m doing something new and I’m in a new room. I can disregard all the other stuff.”

Face To Face Conversations

Clayton: What are some of the other benefits that you would get if you were a physical team having a physical board? Does that help promote collaboration or communication? What are some things you would get from that?

Jade: I think it’s a lot like having a face‑to‑face to conversation. There’re a lot of things that are communicated without words, and by placing it up in a physical dimension, you can tell so much more out of glance than looking at your screen which can only convey so much information and so much detail, just due to its limited size.

You can get away with a whole lot more. You can have a lot of more informal statistics or data that becomes very difficult for a computer to calculate. If I want to write something up on the board, I can just do it. I don’t need a special place to put it or if I want to post something new that we’ve never tried before, I don’t need a code to let me do that. I can do it with a piece of paper.

Derek: Some of it goes towards…if you’re really trying to be agile, you want to be locked into some best practice? That starts to…

Jade: Or at least a practice. [laughs]

Open Possibilities Instead Of Fighting Tools

Derek: Yes, that starts to cramp. A good example on build now on what Jade said is, “The nice thing about blank index card is it’s a blank index card,” so anything your mind can imagine to do with and index card, from shredding it up to adding new elements to doing anything, is possible. Whether you want to use pushpins with different colors to meant different thing, if you want to use different colors with a type of marker, the sky is the limit.

So if you want to try something, a great example I’ve seen our teams do in the past on occasion is, “Hey, we really want to enforce time boxing. We want to see how we’re performing against tasks, because a lot of people are questioning that. It’s as easy as drawing, if we think this is going to be a hour long task drawing one square for each one of the tasks, and then filling it in as it’s getting completed.” That would be really difficult to do in a tool that didn’t have that functionality already built into it.

The nice thing is, you can experiment with that. If that works really well, great. Maybe you keep doing it. If it doesn’t work well, or you get the data that you need to make the decision, I think in a lot of the cases I’ve seen a team think, “Oh, well the problem is our tasking is really, really horrible. It’s taking us way longer than we think to do the task.”

When they do something like that, they realize it’s not that the tasks that we are putting out there are taking too long it’s that we’re doing really crappy planning. We are not putting out half of the tasks that actually need to be done to complete the work. We put task A is going to be half an hour, and task B is going to be half an hour. We find that it really only took half an hour to do each one of those tasks.

But we totally glossed over the fact that there were tasks C, D, E, F, G, H that we just totally didn’t even talk about in planning. In reality, we need to fix our planning, not fix the estimates of our tasking. It allows you to play with things in a lot more easy format without having to fight against the…you never hear, “Well the index cards don’t do that.”

Jade: [laughs]

Roy: Right.

Tedious To Update Physical Board

Clayton: To play devil’s advocate a bit, I’ll ask, “Doesn’t it take a really long to update your physical board”?

Everybody: Right. Everybody…

Clayton: Yes, it does. Is that what you are saying?

Jade: Doesn’t it take a really long time to update your digital board?

Four Reasons People Replace Physical with Digital

1. Too Much Overhead

2. Saving The Trees

Roy: Every Agile team at some point, it seems like, gets into the, “OK. We need to start replacing the physical tools with digital tools.” I feel like they always have four big reasons for doing that. The first as I say, it’s way too much overhead to update a real board; which I think is kind of bullshit, because it doesn’t take any less work in my opinion, than filling out a digital tool. And it gets you a lot of value.

Another reason why they oftentimes want to go with digital as opposed to a physical board is because they say they want to save paper, which I think is just bullshit altogether.

[laughter]

Derek: You’re European, so it makes sense.

3. We Are Distributed

Roy: The third reason is because they are a distributed team, which I think is the only reason that I can come up with that has any validity at all. The fourth reason ‑‑ I forget at the moment, but I’ll jump in a second with it.

4. Save Historical Data

Clayton: Oh, I have another one. I would use a physical board, but I need to keep track of everything we’ve done, because what if I need to look at it again later? If I have a digital tool, it will save it all for me.

Roy: Yeah. So, you’re never going to need that data.

Clayton: Yeah, but I really, really do.

Roy: No, but you really won’t.

Jade: When you need it, you can write it down on the index.

Derek: I think a lot of this goes back to…

[crosstalk]

Jade: You can save all the cards.

Trying For Accountability

Derek: …a lot of teams still have project manager mentality. The idea is, “I need to track tasks and I need to track who is doing the tasks. I need to track the actual hours against the tasks. I need to track all this data because at some point I need to hold somebody accountable.” The truth is, if your team is doing that, you’ve got way bigger problems than for using a physical board, or using a digital board.

That’s because you don’t trust your team, and you don’t believe the team’s going to do the best decisions. The teams that want that information so that they can actually improve don’t have a problem collecting that data. I know that we’ve thrown together spreadsheets on several teams where it’s like, “Let’s collect the data for two weeks and find out what’s really going on.”

Then make an adjustment and collect another two weeks. But very rarely you need to collect that data long term. I think that it’s one of the classic be careful what you measure. If you’re concerned about measuring the number of hours of tasks, and who is doing what, well that’s what you’re going to get. You’re going to get people that try to game the system, so that they don’t look like dumb asses for the number of tasks.

If you’re actually trying to deliver software of value, make that be what matters.

[crosstalk]

Jade: Measure lines of code.

Derek: Make that be what gets measured.

[laughter]

Derek: Function points are my personal favorite. Some of that goes back to…that’s more of a management thing usually, than a team thing.

Or if it’s a team thing, it’s because somebody is definitely afraid that they’re kicking ass, and that they’re not getting credit for kicking ass, which I also think is an entirely big smell. That you’re not a team player if you’re only worried for getting credit for the work that you’re doing, and you’re not actually worried about delivering the best product and making it the best.

Jade: That or you know that Clayton’s doing a terrible job and you just want to expose it. That’s how you’re trying to come up with that.

Roy: Leaving your paper trail so you can fire him.

Who Decides Physical or Digital

Clayton: Let’s say I’m a development manager, and my team comes to me. I have this Scrum team or whatever. They come to me and they say, “We’re using this digital tool now, but we’ve all talked about it. We listen to the really awesome podcasts. And we decided that we want to have a physical board.”

Roy: Is there a podcast out there that talks about this?

[laughter]

Jade: Yeah, we’ll send you the URL later.

Clayton: Is that something the team can decide? Should I let the team do that? Or should I just jump out the window and give up? Those are the two choices.

Jade: If I was a development manager…

[laughter]

Roy: What’s the title again?

Derek: If it’s got the word “manager” or “management” in it, you should just jump out of the window now. And yes, I’m kidding to all those people that are managers.

Jade: Should we let the team do it? I think if you truly believe in self‑organization, then, yeah, you should let the team do it because that’s their work.

I think you have a reasonable expectation to get the information that you need to do your job to report to the people above you and stakeholders and all that stuff, so that information should be delivered to you however you need it.

But when it comes to the team performing their own work and managing their own work, that is the team’s realm of responsibility, and they should be fully able to do it however they would like whether that’s a digital or a physical tool. I don’t think it’s management’s role to dictate that solution.

Clayton: What are some instances…You hinted at Roy, but what are some instances where maybe we would want to use some digital tool? Maybe we want a physical board, but we think we need a digital one.

Roy: The one that I brought up was a distributed team. That one I would say, “Why distributed”? But if you really have to be distributed, then you have to have some way of keeping track of everything, and I haven’t found a better way than a digital tool, but as soon as I do, I’m jumping off the…

Jade: [laughs] Teleportation.

Derek: I think anytime you got a lot of cash to burn and you want a bunch of licensing fees is a good time to…

Jade: Yeah, if you really like that tool vendor [laughs] .

[laughter]

Jade: I think a distributed team is definitely a situation where a physical board does not work. We’ve tried it many times being distributed ourselves to try to manage a physical board, and at some point, it completely falls apart.

Roy: It was a physical implementation of a digital tool because it would be, one person would maintain a physical board and take a picture of it and send it to everybody else.

Jade: Which was just insanity. It was…

[crosstalk]

Roy: …writing an intelligible digital tool that you couldn’t update immediately.

Jade: Yeah, it wasn’t providing value.

What About Reporting Up

Derek: Another valid reason for it ‑‑ and I would say that this should be a short‑term reason only ‑‑ is if you are in probably a larger company whereby you are a pilot or one of the few teams in an agile organization and you still have reporting structures that are requiring some of the data that you might need digitally.

Now in those instances, I would really recommend to go ahead and let people use a physical board and then actually key the information that you need for whatever roll up reporting you need for your manager. But I would say that in that case, it would be worth double keying that information to allow the team the benefits of a physical board.

But I could see somebody saying, “It’s just not worth a waste of doing it in paper and keying it in.” I’d say, “I don’t think you understand the benefits well enough,” but if you really believe that, I think that that is another reason. If you have to report some of the upstream until you can convince them otherwise, that might be a reason why you would see that.

Roy: Another reason too in that exact same situation ‑‑ why you would want to double key the information? ‑‑ is nothing starts conversation as well as a board. I can’t tell you how many times I’ve been sitting around here at Gangplank and then somebody comes up and asked me, “What’s the deal with all these cards”? Even people that normally wouldn’t ask questions of anybody else.

Jade: We’ve seen that in client’s sides too. The CEO or some executive VP walks by and says, “Oh, what’s going on? What do these charts mean”? And you can start to have a real conversation.

Card Man Brings The Serendipity Out

Derek: Absolutely. One of my favorite stories along this line is, we implemented cards, and I was sitting more where the executives were not necessarily where the team was, so the team had decided to put the board in that hallway, which I thought was bad for the team, but I thought it was good because it got a lot of management highlight.

I had one of the members that wasn’t on our team ‑‑ she’s not part of the development at all ‑‑ walk by, and she’d called me “card man.” We joked and laughed. She said, “Even though I’m teasing you, I’m serious. I really liked it.” She showed me cards that were for…The output of the software directly affected her department. It was the tool they used.

She said, “Right here, it says this, but it’s missing one. Do you know when they’re going to do that”? I said, “Well, they chose to not do that this sprint.” She said, “Well, why not”? She actually got really upset like, “That’s the most important thing, and it’s not even on there.”

She was able to go back to that development manager and say, “Hey, how come your team didn’t do this”? They gotten to a lengthy discussion, and it brought out all sorts of things about the inefficiency of the particular tool. She would have never done that if they were using a spreadsheet or some tool because she wouldn’t have ever known that it even existed.

That it’s those serendipitous moments that we don’t even really talked about very much that sometimes provide the most amount of value by having things out in the open and able for feedback from anybody.

But Im On a Distributed Team

Jade: What do you do if you’re a distributed team?

Roy: Cry [laughs] .

Clayton: Also jump out of the window is an option.

Jade: Jump out the window. Yeah, OK. So I’ve cried. I’ve jumped out the window. And they brought me back from the dead for this project [laughs] . What do you do to try to get the advantages of a physical board and a distributed world?

Roy: One thing that I’ve tried in the past is to use an online spreadsheet tool, like Google Spreadsheets, because it gives you a lot of flexibility while still maintaining somewhat a structure.

Although, I found that that works great for two weeks, and then it starts to get really disorganized as we try to make the same types of adaptation that look perfectly organized on the index card, but it starts to look very messy on a spreadsheet.

Derek: For me the problem is that you’ve got a much bigger problem than your board once you get distributed. I think that not being within proximity of other people is a much larger problem when you’re distributed than whether it’s physical or digital boards.

I’d say the first thing I would do is try to do everything humanly possible to simulate being collocated even though you’re distributed, whether that be Skype, whether it be pair programming, whether it be some kind of online instant messenger app, anything that promotes a lot of communication that is asynchronous and can simulate real being in a physical presence to someone.

I would really stress that that’s probably the most important. Once you have that, I think then you can start to add ways to say, “Hey, maybe every so often, we’re going to post the current burn down, or we’re going to do something, or maybe we’d add another stand up or something.”

I think there’s ways you can start to say, “How do we incorporate what we’re putting in a digital tool into the conversation”? But most distributed teams just don’t even have the conversation, which is, I think, absolutely critical to have.

Making A Board Better

Clayton: To wrap up, can we go around and get one thing that you think will make the most of your physical board, something that will make it better than it could be on its own?

Meaningful Colors

Jade: Colors.

Big Visible Charts

Derek: For me, the biggest one is big, visible charts.

Jade: I should say “meaningful colors,” not just random rainbow.

Visual Details and Overviews

Roy: What I’ve seen help a lot was Derek’s example, where you show your time box by indicating the black boxes for you’re still using your time box. For every 15 minute increment, you draw a square. As you exceed your time box, you start drawing red ones. It becomes very easy to see.

At an overview, you can see an entire board. You can see where sections are red and where sections are green. It becomes very easy to see which stories cause the most problems throughout that week, and which ones went a lot faster than expected.

Collapsing Board In Real Time

Clayton: For me, I would say updating the board in real time and collapsing things. You collapse all your tasks that you’ve completed down so that over time, as you’re passing by, in your subconscious you can look at the board. It looks different. It starts looking smaller, and it looks like things are going away.

Derek: I think that’s a really powerful one.

Jade: That’s good.

Clayton: Thanks guys.