The Counterintuitive Fix—How Collapsing the Jira Board Sparked Collaboration | Aliu Adewale

Summary

Podcast Summary

Overview

Episode Title: The Counterintuitive Fix—How Collapsing the Jira Board Sparked Collaboration
Host: Vasco Duarte
Guest: Aliu Adewale, Scrum Master and Agile Coach
Date: July 7, 2026

This episode, part of the Scrum Master Toolbox Podcast’s “Team Tuesday” series, features a practical exploration of team dysfunctions and their remedies. Aliu Adewale discusses a persistent issue of poor collaboration and communication within a software development team—and the surprising, counterintuitive solution that came from radically simplifying the team's Jira board. The conversation provides actionable insights into diagnosing systemic problems, facilitating collaboration, and prioritizing Agile values over tools.

---

Key Discussion Points & Insights

1. Book Recommendation: Developing Emotional Intelligence

[01:22–03:34]

• Book: “Surrounded by Idiots” by Thomas Erikson
• Impact: Helped Aliu deepen his understanding of emotional intelligence and navigate different personalities as a Scrum Master.
  • "I'm someone that already embrace emotional intelligence and that book also had to my emotional intelligence capability..." (Aliu, 02:24)
• Key Takeaway: Recognizing and adapting to different personalities is essential; Scrum Masters must tailor communication styles to ensure messages ‘land’ with diverse team members.

---

2. Diagnosing the Team’s Biggest Problems

[04:31–08:08]

• Scenario: Aliu describes a team plagued by communication gaps and lack of collaboration:
  • Junior developers hesitant to challenge seniors, resulting in poor dialogue.
  • Role silos (backend, frontend, QA) created knowledge partitions.
  • Stand-ups and refinement meetings were perfunctory, with little true engagement.
  • "...communication gap was their major problem... you have to deal with different backgrounds, different people coming together..." (Aliu, 04:31)
• Host’s Analysis: Vasco emphasizes how workflow partitioning (e.g., overly segmented Jira boards) creates handoffs and feedback delays, exacerbating silos and stifling collaboration.
  • "We know that this is a problem because it delays feedback..." (Vasco, 08:08)
  • "The board... is just a visualization. But that the visualization told you that people were not really trying to get something completed end to end together..." (Vasco, 08:08)

---

3. The Radically Simple Solution: Collapsing the Jira Board

[09:40–13:12]

• Intervention: Aliu condensed the board from 9–10 specialty-based columns to just three: To Do, In Progress, Done.
  • "We streamlined the board... from like nine columns. We reduced it to like four columns... To Do, In Progress, and Done." (Aliu, 09:40)
• Outcome:
  • All work in progress is now collectively visible and not “owned” by a single function.
  • Everyone—developers, QAs, architects—must coordinate directly to advance tasks.
  • Created accountability: team members can't “hide” behind their column; they must discuss blockers and next steps together.
  • "...everything is in progress now rely on everybody. Qa, back end, front end, senior architect, junior architect, everyone have to communicate..." (Aliu, 09:40)
  • "If one ticket is in progress, that means that ticket must lies between developer, qa, senior and architect, front and back end. So everyone have to communicate, everyone have to chat with, with each other..." (Aliu, 09:40)
  • Notable Quote: "Because they had no choice, they had to talk." (Aliu, 12:37)

---

4. Embracing the Counterintuitive Fix

[12:37–14:23]

• Host's Reflection:
  • The deliberate “removal” of detailed status actually forced collaboration, which is at the heart of Agile.
  • "By creating the problem of ‘hiding status’... you required everyone to talk to each other, to coordinate, to synchronize and that sparked collaboration." (Vasco, 12:39)
• Aliu's Agile Principle:
  • This approach honors the Agile Manifesto value of “Individuals and interactions over processes and tools.”
  • Keeping team members focused on working together, not just moving tickets.
  • "Don't let us focus on the tools, let's focus on how people interact... we want to focus on how people actually work together." (Aliu, 13:12)

---

Notable Quotes & Memorable Moments

• [02:24] Aliu:
  "That book actually tell you to the t how different personalities behave... that's what we actually like day to day looks like. So you deal with different personalities..."
• [08:08] Vasco:
  "These partitioned Kanban boards... are symptoms of handoffs... it delays feedback... and then consequences of that delayed feedback, which is basically interruptions, lack of context, and so on."
• [09:40] Aliu:
  "The foundation of that problem back then was the tools, how we utilize the Kanban board... when we streamline the board... everyone have to communicate, collaborate because they had no choice."
• [12:39] Vasco:
  "By hiding status, you required everyone to talk to each other, to coordinate, to synchronize and that sparked collaboration."
• [13:12] Aliu:
  "Don't let us focus on the tools, let's focus on how people interact. Just like the Agile values: individuals and interactions over processes and tools."

---

Timestamps for Key Segments

• [01:22–03:34] — Book Recommendation: Surrounded by Idiots & Emotional Intelligence in Teams
• [04:31–08:08] — The Team’s Communication & Collaboration Struggles
• [09:40–13:12] — The Solution: Collapsing the Jira Board & Creating Radical Transparency
• [12:37–14:23] — Reflection on Agile Values, the Impact of the Change, and Lessons Learned

---

Takeaways for Practitioners

• Simplify processes and tools to the bare essentials to highlight collaboration needs.
• Beware of tool-induced silos—the structure of your board or process can reinforce bad habits.
• Intentionally create environments where direct communication is a necessity, not an option.
• Prioritize individuals and interactions—mechanics and visualizations are secondary to building a collaborative culture.

---

This episode is a reminder that sometimes, the “fix” isn’t adding more detail or process, but removing complexity to force the right behaviors—making collaboration not just easier, but inescapable.

Transcript

[A]

Hey there agile adventurer. Just a quick question.

[B]

What if for the price of a

[A]

fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now.

[B]

But if you're not doing it now,

[A]

let's listen to the podcast.

[B]

Hello everybody. Welcome to our Team Tuesday this week with Aliu Adewale. Hey Aliu, welcome back.

[C]

Thank you Vasco. I'm glad to be back.

[B]

So Aliu Team Tuesday, of course is when we talk about teams and how sometimes they become their own worst enemies. But before diving into the team story, share with us what was the book that most inspired you in your career as a Scrum Master?

[C]

It surprises that the book that inspired me as a Scrum Master is a book that came up on your show. I forgot the name of someone that recommended it so. So this statement actually complements what I said earlier about following your show, your podcast. The title of the book is Surrounded by Idiots by Thomas Erickson. Surrounded by Idiots by Thomas Erickson.

[B]

Tell me a bit more. Why did this book inspire like maybe the surprise that you experienced when reading the book or what it triggered in you?

[A]

What?

[B]

Why did you find it so inspiring?

[C]

I find it so inspiring because the book, the title on its own is like creates a lot of curiosity and I want to know like what is going on in this book and being in that space, you know, make me to realize like okay, let me read this book. And after reading the book I find out like I'm someone that already embrace emotional intelligence and that book also had to my emotional intelligence capability. Communication in term of communication and in overall when you are working, working in a place where you have to deal with different backgrounds, different people coming together and our role as the Scrum Master, that's what we actually like day to day looks like. So you deal with different personalities and that book actually tell you to the t how different personalities behave. It might not be hundred over 100, but at least 90 over 100 about personality, people, personality, human relation. So that is a value I find from that book.

[B]

Absolutely. And learning to understand and accept the different personalities we deal with is so important. Pardon me as Scrum masters, because we can't change those people. We have to understand them and then figure out how we can transform the messages that we need to deliver in order so that it lands with that person. So awesome. Well, thank you for the recommendation. The link is in the show notes of course, so you can all go there and check it out. Aliu now we turn our attention to to the teams and how sometimes they can become their own worst enemies. So Ali, you share with us that story, tell us about the team, you know, the size and what was going on, what kind of project and then walk us through those behaviors or patterns that maybe started small but grew and over time became a problem for the team.

[C]

I was working with a team a few years ago. I was working with a team where communication gap was their major problem. Communication gap. And I believe every Scrum master have had one or two bites of that situation before where you have to deal with senior architect all the way to senior software developer all the way to like coming from junior developer that don't want to speak up even if they know like what the recommendation on the table from their senior colleague is not the right way to approach stuff. So you have to deal with that communication gap whether people don't want to talk or where people don't want to collaborate. Now you still have to deal with the QAs too where acceptance criteria is not really cleared enough. So I was working, we were working on a project where we are supporting a group of customers collaboration and at the end of the day teams were not really communicating. It was huge. And I realized that we have a board, a JIRA board where it segregated everyone tax like to do in progress, dev complete qa, QA test done and

[B]

also documentation, design, backend, front end, all

[C]

those things like you we have like we had close to like 10 columns then. So I realized like okay, the dev team just wanted to deliver and then forget about it. Whatever the QA want to do with it, that's their problem. Nobody's engaging during the refinement. Everyone are not really collaborating any stand up. Looks like just everyone just want to be on the call for the sake of being on it. Nobody's really actually contributing. Nobody's calling out anytime when you're working on IT team, when nobody's calling out anything, everyone is just saying okay, okay, okay to everything. That's a big communication gap. So I realized, like, how can I do this? You know, I can find the right way. Then.

[B]

So what were you trying to do? Like, what were you.

[C]

What.

[B]

What was the outcome you were hoping for?

[C]

My outcome for me as a Scrum Master is to be in a team that are collaborative because collaboration is the foundation of everything. If teams are not collaborating, there is no way negotiation will happen. There is no way continuous improvement will happen. Collaboration is the foundation of a successful Scrum team. So collaboration was gap in that team then, and communication were not really flowing back then. Everyone comes in has, I'm champion of backend, I'm champion of front end. I'm champion. And one thing I later realized based on that experience moving forward as part of my continuous learning as a Scrum Master then was if I'm working with any team right now, I always let them understand. Like, if you have a PhD badge, master badge, put it outside. In this Scrum team, everyone is equal. We are all equal. So communication gap was the problem back then. Collaboration gap was the problem. Those two are major problem on that team.

[B]

I think it's important for us to recognize that these partitioned Kanban boards, where tasks are partitioned by specialty and tickets are passed from people to people with different specialties, instead of completing beginning to end in one go. These are symptoms of handoffs. Let's call it handoffs, right? Like, I'm the tester, you're the developer, you will do the code, you will commit the code and get it reviewed, whatever, and then give me the ticket and say, hey, I'm done, it's your turn. Right? And we know that this is a problem because it delays feedback. And when the tester is finally done with testing those changes, then they will have feedback and the feedback comes and the developer is in the middle of something else. So we end up having this delayed feedback and then consequences of that delayed feedback, which is basically interruptions, lack of context, and so on. So those are the symptoms. But what you're saying is that the real problem is not that the board was partitioned. I mean, in the end, the board is just a visualization. But that the visualization told you that people were not really trying to get something completed end to end together. They were just kind of doing small pieces and handing it over and then asking you do your part in silos. Okay? And that's the. Is that a fair way to represent

[C]

what you just Said yes, it's a fair way to represent it. And also the board, how the boy is being bought, being laid out also have, has its impact on the team as well. So I'm just trying to say like sometimes most problem on a team does not really rely on the team on their own. It's rely on the tools we use sometimes too. The foundation of the problem can be from the tools we use. And I noticed at the end of the day that the foundation of that problem back then was the tools, how we utilize the Kanban board. Because the resolution to that problem was we streamline the board we have we from like nine columns. We reduced it to like four columns to do in progress and done. Three, three columns sorry. To do in progress and done. And Vasco, do you know what happened? Everything in progress now. Now rely on everybody. Qa, back end, front end, senior architect, junior architect, everyone have to communicate to each other. They have to talk because everything is in progress. And if we have stakeholders on the call that want to know what is going on, everyone have to communicate what is going on with a particular ticket. That way a senior developer will actually have a conversation with a qa. A QA want to know, like when is this ticket going to be ready for? Because there is no column on the board to say oh, it's in QA now. So it's your turn to work on this. So everything stays in progress. So everyone have to talk about that ticket. If one ticket is in progress, that means that ticket must lies between developer, qa, senior and architect, front and back end. So everyone have to communicate, everyone have to chat with, with each other like oh, what's what you got going on? When am I going to get this? Oh, tomorrow. Okay, tomorrow. If that is not being delivered to the person want to ask question like okay, you said I'm gonna get this tomorrow. What's going on? What's happened compared to before, the state we were before where if something is in my column which is QA testing, S asum I'm a QA test. I know like okay, this is for me. Now I need to pick it up. But when we streamline the board, the tools we use, then when we streamline the tools, we realize our team started communicating, collaborating because they had no choice

[A]

then this is so interesting.

[B]

Exactly as you said, because they had no choice. So in fact by creating a problem, we solved the bigger problem, right? Like the problem that I mean is by creating the problem of quote unquote hiding status. It's not really because you can have a lot of status, even if it's only one column. But let's forget that for a second. By hiding status, you required everyone to talk to each other, to coordinate, to synchronize and that sparked collaboration.

[C]

Absolutely, absolutely. And it's created more of like, okay, don't let us focus on the tools, let's focus on how people interact. Just like the Agile values individual and interactions over processes and tools, we want to focus on how people actually work together. Because these are people that comes from different background. Right. You put them together or it's so easy for team to say, this is my own path, I'm done, I push it to you do your own part. Whatever happens, no blame on me. Now you're putting them together. To actually have a conversation, to work together, that's like peer programming, right? Where people have to deal with each other, learn from each other. A QA can interact with the back end developer. They have to communicate, they have to like do things together because this ticket is in progress. Leadership want to know where it is right now and to know that everyone have to participate, everyone have to communicate, collaborate. And doing that then help the team to actually, you know, like solve the problem of communication gap and collaboration gap. Because everyone have to talk.

[B]

Absolutely. And that it's so interesting because it's that perhaps counterintuitive reduction of granularity of information that creates the need for people to talk, to coordinate and therefore also collaborate. That was a great story. Thank you for sharing that Aliu.

[C]

Thank you so much, Vasco.

[A]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile Business intelligence, creating product visions, coaching your product owner courses, you name it, you'll get invites to monthly live Q&As with agile pioneers and practitioners. Plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with, with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership so head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. Slack

[B]

we really hope you liked our show, and if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work.

[A]

Remember that sharing is carrying.