How design can address contemporary complexities at the macroeconomic level? This topic was the focus of conversation about the role of MURAL and Agile recently when Adam Kallish, a design practitioner and adjunct at the Institute of Design Illinois Institute of Technology, presented for MURAL.
Adam teaches a seven-week course for masters and PhD students on how design thinking and agile work together. While design thinking is about doing the right work—i.e. solving the right problem—Agile is about doing the right work right.
For the Agile Culture course, students are taught the importance of clarity of purpose—and that all work directly supports the overall value delivered to markets and customers. Agile culture balances the understanding of key Agile principles—values, culture/behaviors, and practices. It goes on to apply those principles through "learning by doing" as peers tackle actual problems and create a prioritized backlog of work.
For Adam's MURAL session, the goal for educators was two-fold:
You can watch a recording of the session from April 24 below.
Adam created a MURAL presentation for the session with embedded links and video to showcase how a custom designed workspace can quickly and visually communicate concepts. Below you'll find 6 murals, starting with an overview and then diving into course materials from Adam's class.
Adam's course begins by laying out an overview of design thinking and Agile culture.
While Agile started out as a way to do better software development, it has branched out into many industries as a way to break down strategy into small tactical sprints and iteration to learn. Both design thinking and Agile focus on users, customers, and teams bringing their diverse skills and experiences together through unity of purpose. Agile takes it further by improving the cadence of teams (velocity), so they can efficiently get tasks done.
Furthermore, Agile SCRUM focuses on how a team, led by a product owner, defines a backlog of work and prioritizes supporting tasks. Tasks are pulled from the backlog by a team, completed in two-week sprints and then communicated in real-time to burn down the backlog which leads to a showcase of what was accomplished. The amount of work that can be completed in a sprint is dependent on a team being able to work more and more efficiently across a series of sprints, using less effort to get more work done.
As Adam shared with MURAL educators, course tasks are moved to done and closed. Then, the team reflects how they think they did over the sprint: What they did right, what they did wrong, and what can be improved for the next iteration.
Apart from learning Agile culture, Adam also establishes the technology required to support the goals of the course. The five platforms Adam teaches are Slack, MURAL, GitHub, ZenHub, and Google Hangouts. APIs link certain platforms together for greater transparency and communication.
Below is the overview mural of Adam's course:
Next, find below five murals from Adam's course.
As Adam teaches, MURAL plays a central role in Agile culture. For example, Adam always starts his courses with a Hopes and Fears exercise. This exercise is based on the course description. It works to reveal each student's motivation for signing up for the Agile Culture course.
As part of the Hopes and Fears exercise, the class uses the voting function in MURAL to determine which hopes and fears were the most important, which lets Adam know as an instructor how to manage student expectations.
Below is an example output of the Hopes and Fears exercise
From the Hopes and Fears the class defines a social contract based on the five values of Agile. Once this is complete, the students narrow down the desired behaviors to make sure all teams honor the course contract. You can see the final result in the "Aggregated IDX 597 Class Social Contract" portion of the mural below:
Adam teaches Agile culture by having students go through IBM's Hills/Sub-Hills framework, which works to break down an abstract goal into real work. While this work is very hard to do, teams are able to iterate and begin to understand the goal at a deeper level all through teasing out the details—the sub-hills—required to achieve the goal.
On completing the Hills/Sub-Hills exercise, Adam teaches teams to size the difficulty of all their stories through relative estimating. MURAL was used as a visual way to do "T-Shirt Sizing," a popular analogy for teams to define what stories are small, medium, and large. Using T-Shirt Sizing, teams can better define their sprint, grouping different combinations together.
Each week, Adam has student teams reflect on their performance linking the social contract to their actual actions and outcomes by identifying what they did right, what they did wrong and what they need to improve to gain greater interdependency and velocity. This is a critical component of Agile, which is about continuous improvement.
Throughout the Agile culture course, MURAL was an indispensable platform for both ideation and definition for Agile Culture. MURAL enabled Adam and his students to quickly map out ideas, explore concepts, collaborate visually, and communicate clearly. In addition, students had improved experiences using GitHub and ZenHub effectively. (To understand how ZenHub was used in Agile Culture, here is an article about it.)
Ultimately, as Adam teaches students how to bring together design thinking and Agile methodologies, students learn how to collaborate visually, doing the hard imagination work required to make progress for their teams and organizations. It's exciting to see as the next generation of innovators learn about the benefits of these social technologies.
We want to thank Adam for sharing his Agile Culture course with our audience.
Ward Bullard: Well. Good afternoon everybody. Welcome to this exceptional MURAL webinar. My name is Ward Bullard. I lead MURAL's education and nonprofits team. I'll be serving as the moderator of the Q and A and chat functions within MURAL, but I'm gonna hand it over to Jeff Eyet to properly introduce him and lead this session here.
Jeff. All you.
Jeff Eyet: Thanks Ward, welcome everyone and happy Friday. If those are still a thing. I, it's, I teach design thinking at UC Berkeley in the Haas School of Business, and Ward teaches design thinking at the d.school at Stanford. And so we just, really we, we firmly believe that this is just an amazing platform to bring people together, in, particularly in these times.
And, you know, my mission here in MURAL is to move it beyond the platform that's merely a whiteboard, a digital whiteboard, to that level where it, it begins to be used for the actual ideation and design thinking process. And then hopefully today's conversation with Adam will lift us up to that level where we really view MURAL as an integral, integral part of our tech stack that we use either personally, professionally, or in the classroom.
And, whether you're, again, a professional facilitator or in the classroom, you know, uncertainty around the fall, why can't MURAL be part of that, going forward regardless? And so Adam is going to give us a little bit of an expert level class, as I'd like to say, on how he's integrated it across various technology platforms, in particular with an eye towards his experience as a dedicated agile practitioner. [00:02:00]
So with that, Adam, I'll turn it over to you. Welcome. Thank you for joining us. And, welcome to, the MURAL lunchtime chat room.
Adam Kallish: Thank you very much, thanks for that. And Jeff, good afternoon or good evening, or would it be a good evening wherever you are. Thanks for making time to learn how MURAL was used at the Institute of Design.
Today the goal is twofold. The first, to orientate everybody on the call on what agile is and the role of teams and breaking down strategy down to the task level. And then secondly to discuss how MURAL was used in agile culture, which is the course I teach. And how it worked with Slack, ZenHub, and GitHub.
I put together this comprehensive MURAL to both showcase what MURAL can do and to have it available, for your future reference. I will not be reading everything in this MURAL, but talking to it so you can always come back to this MURAL, hopefully. And if you have any further questions after this session, you can, get them to Jeff and Ward, and then they'll get those to me.
if you would like, you can press on my icon at the bottom of your screen and follow along with me. I've asked Jeff to watch the chat feed within MURAL. So I'd like to use the chat feed in MURAL versus, in a Zoom, if possible, if there's any questions, and I've asked him to stop me at any time to ask a question that someone may ask, since I won't be...
Jeff Eyet: Oh you've already got a shout out, Adam Ottas says you're the man.
Adam Kallish: Oh, okay.
Jeff Eyet: You are the man.
I'm going to put the MURAL link in the chat for anyone who wants to follow along in the platform and also, Adam, I guess that's probably better than a, oh and our man Jack Crumbly's in the house. Ward are you shocked by this?
Not in the least. Not in the least. All right, Jack, welcome. Thank you for joining us.
Adam Kallish: Okay.
Jeff Eyet: Okay. Adam, back to you.
Adam Kallish: Alright. and then if we have time at the end of the session, we could open up to more questions. So I guess there it is. So we're going to get started. [00:04:00] So I'm going to talk a little bit about why the course was offered.
We, the, the key is we want to go from status quo to continuous improvement. That's really what it's all about. Now the Institute of Design. For those of you who may not have heard of it, it's the oldest design school in the United States at the, at the masters and PhD level. And it focuses on how design can address contemporary complexities at the macroeconomic level for masters and PhD students.
I always like to refer to the U.S. Military, who uses VUCA to describe what is what is facing in an uncertain world. This uncertainty crushes old thinking of attempts at optimizing things as it becomes almost impossible to do so, I guess my, bookmark isn't working here. So, so really the U.S. Military had to rethink its whole structure based on VUCA, which stands for, volatility, uncertainty, complexity, and ambiguity.
So we're, we've moved to a world of resiliency, versus optimization, which builds in continual change. It can address the imperfections. Agile is one way to provide a resilient framework for doing the work, right? What's key in my course and what's key with agile as well as design thinking is design thinking is about defining the right work to do.
It reframes what we think of as a problem with what the actual problem is. That's why we do design thinking. It's called reframing, and then agile is really about doing the work right. Both integrate, thinking, creating, and making, in iterative cycles. That's very, very important. They're not diametrically opposed to each other.
They actually work together. One of my students actually put this drawing together, which I love, and this is really my course at a glance. So agile culture has been offered, four times in two years, and it's only seven weeks long. So it's only half a semester. Masters and PhD students take the course as a counterpoint to their strategic [00:06:00] thinking focus.
And, this diagram, you can see what the course is about. The specific practices that we use, such as a social contract, which I'll be talking about weekly reflections and specific digital platforms that we used in the course. Okay so I'm going to go to what agile is about. And what it isn't about.
The most common misperception about agile is that it's about fast. I hear this all the time in corporations that I consult to as well as people that I talk to. And as we'll, as we'll see today, hopefully it all prove that it has nothing to do with about working fast. The other common misperception is that it's only for developers.
Now, while agile did start out as a way to do better software development, agile is branched out into many industries as a way to break down the strategy into small tactical sprints and iterating to learn. So what is agile about? The agile manifesto, which was written 15 years ago, it really has nine key attributes, and these are the key attributes.
And most of these should sound familiar to you because they've gone actually mainstream. What you see in bold are the key attributes for each one. The nine work together and they address really three things. They address culture, they address methods, and they address outcomes. Now, a scrum is the most common way to do agile, and just quickly, I'm not gonna read everything on this diagram, but you could see it at a glance. A team which is led by a product owner, defines a backlog of work, prioritizes the tasks, and then through two weeks, sprints, team members work on the tasks and communicate in real time, to burn down the backlog, which leads to a showcase of what was accomplished.
This is that move to complete. The team does a reflection of how they think they [00:08:00] did over the spread, what they did right, what they did wrong, and what can be improved for the next iteration. So, the most common, is a set as the agile scrum framework and all other flavors of agile build on the scrum framework.
There's like nine other flavors of agile, but the scrum is the foundation and a sprint's, depending on the maturity of an organization, are usually two weeks, but at Google, they're one week. And at immature organizations, sprints can be four weeks long. Okay, so the key principles of agile are fairly simple.
They're about customers. They're about teamwork. They're about cadence and they're about done. So both design thinking and agile focused on users and customers that the teams bring their diverse skills and experiences through unity of purpose. Unity of purpose is very important in agile.
Agile takes it further by improving the cadence of teams, and this is called velocity, which I'm going to talk about in a few minutes, and they efficiently get their tasks done. Okay. So this is very, very important that there's a shared definition of what done is an agile. Now, really my course in design thinking agile is really about continuous improvement.
And so you can see in this diagram, design thinking defines the goal, breaks down the goal into hills or what we call value proposition statements and gets granular on people, objects, environments, messages, and systems to achieve the goal. Then agile takes over. It flips, after the sub hills, and it takes the level of granularity and breaks these into epics, which are really fanatic bodies of work, stories, and then tasks.
Now it's critical that the smallest task has to map back to the goal. Okay. [00:10:00] And so when you break things down, it's called decomposition. And when you map things back, that's called traceability. So every task has to be traceable back to the goal or an agile, they don't actually have to do the work.
So if they can't trace it, they won't do it. That's very, very important.
Jeff Eyet: Hey Adam, can I interject for a second? Do you mind uh doing three things for us? One is if you can just turn off the buzzing bee cursors, if you can go to the bottom and maybe just stop the follows, if that helps. The second is, can you call everyone to your view just so that they're all following you?
Everybody that's in the MURAL.
Adam Kallish: Yeah. Yeah.
Jeff Eyet: If you would, I think words enabled it, if you wouldn't mind sharing your screen. I think there's some folks who may have limited accessibility at the moment and they'd like to see your screen.
Adam Kallish: Okay, sure. Yeah, absolutely. Yeah.
Jeff Eyet: Why don't you, man, you know, just the 15 minutes in quick tuna?
Adam Kallish: You see, we're already doing continuous improvement,
Jeff Eyet: okay?
And if anybody on this call thinks this wasn't planned, there we go. Alright. So this'll be better for the recording too, Adam. Thanks.
Adam Kallish: Exactly. Okay.
Jeff Eyet: All right. Cool. Thank you.
Adam Kallish: Okay. Any time.
Ward Bullard: Adam, to jump in here, the image that you're showing in the Zoom is not showing up on the MURAL, at least in my view. I don't know if others are having that.
Adam Kallish: Cause I'm sharing the actual thing.
Jeff Eyet: Yeah. For some reason it's not showing up on the MURAL, but it's showing up in the Zoom. That's weird.
Adam Kallish: Yeah. I…
Jeff Eyet: Well we've gotta record, if you do the uh, if you do the screenshare Adam, we got the record up. You know, we can always link back to it.
Adam Kallish: Alright, well I appreciate it. I'm going to share my screen...
Ward Bullard: I just did a refresh and it works okay Adam, so…
Adam Kallish: Okay. Thank you. You've got me paranoid there for a second. Thank you. So just when you think you know about the technology, you don't. I think we can all attest to that. Okay, so now what I'm gonna talk quickly about, I'm going to get [00:12:00] over here and I don't know why it's not working, but there we go.
I'm going to talk about teams because agile teams are extremely important. They're important in general, but in agile, if you don't have a healthy team that's aligned, they're not going to get any tasks or work done. So a product manager, whose the owner, they essentially run a team and they're the link between the markets and the strategy and the actual teams that actually do the work.
It's very, very important. Now most teams that I've been exposed to in my career aren't really teams. They're really groups of people that only do enough individually to get the work done so that the team is responsible for the output. Okay. And agile, the product managers, the commander. And as I said, it's the link between the market and the outcome.
They work with the core team and defining the epics of genetic bodies of work, stories and tasks to get the work completed. Without a focus team work can easily break down into chaos. Okay. And in agile, they don't like chaos. Okay. They want clarity of purpose, which they expect to the goal through traceability.
Okay. So I told…
Jeff Eyet: Adam, quick question. There was a question in the boxes that, you know, a product manager versus the product owner and, you know, in their definition they're two different roles. How do you see it?
Adam Kallish: Yeah, and that's a fair point. It depends on the structure of the organization. Sometimes, the product manager and the product owner are synonymous.
Sometimes they're two different roles. At IBM where I was, they were the same person. Okay. And then you actually had the sponsoring executive or the executive sponsor who actually led the actual strategy. So I think it depends on the organization, but it is a fair question. Any other questions or should I keep going?
Jeff Eyet: Okay. We're good. Keep rolling.
Adam Kallish: Okay. Thank you very much. Okay. I talked earlier that agile is not about speed. It's [00:14:00] really about velocity. And this is what I show my students. And this is based on just 25 years of experience of leading teams on products is, you know, a team has specific skills, they have experiences, and then they have a certain dynamic.
Team velocity is impacted by the units of work that are defined and that are agreed upon is done, and that they aim the skills. The aim, they understand the level of complexity or difficulty and the time, and that determines the amount of effort it's going to take to actually complete the sprint.
So when, in, in agile, they talk really about the velocity of teams and teams can have different velocities, even though they may, they have the same level of complexity of work. Because the different teams have different skills, experiences, and dynamics. Okay. And just based on our experience working in teams, they would be empirically true.
A team takes ownership of the backlog and determines what work is done and in what order. The amount of work that can be completed in a sprint is dependent on a team being able to work more and more efficiently. There were a series of sprints to use, less effort to get more work done. Okay. Now I want to also address meetings because this is very important.
The agile is anti-meeting, because all work is visible. Okay? So you don't necessarily need to meet because everybody knows what's going on. So agile views meetings differently than a bunch of people meeting in a room for an hour at a time, because that's a time waster. Agile views meetings as points of contact between two or more people in five to 15 minute interactions.
They do a daily 15 minutes stand up where the team discusses what they will do for the day. In my course, students use Slack for quick interactions. like communications, they use Google Hangouts for 30 minute working meetings and had in person onsite working meetings for an hour a week. So that's how, so this diagram actually comes [00:16:00] from my course to try to put in context what the role of contact time and meetings are.
And this actually helped the students become much more effective and really protecting their time. Oh, okay. Alright. And then I'm going to go to, shared platforms. Okay. This is really important because obviously without shared platforms, agile would fall apart as most, mostly everything would. So, everyone on this call uses some type of digital platform to communicate, to share, and to get things done.
Google is the most popular platform that weaves together individual programs like Gmail, Google Docs, and other things. Okay. For my course, we used five platforms that did very specific things in order to support the goal of the course. So we use your all for ideation. We use ZenHub, which actually tracks work in a combine.
We use GitHub as the main repository to generate issues and tasks and GitHub and ZenHub work together. Okay. So they're owned by Microsoft, they, they bought them a few years ago, so they work together. Slack was used for threaded discussions and Google Hangouts was used as our telepresence platform.
Okay. Now, what's very important with these platforms is that you had a, what they call API integration. And the great thing about MURAL,
Jeff Eyet: Hey Adam before you jump into API integration, if you don't mind, just a couple of questions that came in here. The first one, is this just a quick review of what velocity is?
Adam Kallish: Okay. Okay. Velocity is the ability of the team. And I'll, I'll go back to velocity because it's right here. Okay. Right here. So velocity is determined by the specific skills or experiences and team dynamics, okay. That's the context. So what teams do is that they will take units of work. They [00:18:00] will look at their skills, the level of complexity of the work and the time to complete the work, which is usually done in a sprint.
Okay. That determines the amount of effort that it's going to take to actually complete all the task's items in a sprint. Usually this is done through what they call story points. But I don't like story points, for people who know what story points are on the call. They're there. They use the Fibonacci series as a way to evaluate how difficult the task is.
So the higher the number, the more difficult task. Okay. I use what's called relative estimating, and I'll talk about relative estimating in a minute because relative estimating is the more intuitive way to understand how big a task is to get completed. So did that help?
Jeff Eyet: Yeah, absolutely. Thank you. And so, a quick, a quick clarification is, for the, these, these, you know, when you're running an agile project, who, so who's like, who's the point person who's the main leader in that?
Adam Kallish: Well, it's, it's actually, the team actually determines who does the day to day leadership, and that may switch from day to day. That's really the product manager who actually has the final say. So the product manager is the commander because they are the interface between the market and the company and the actual team doing the work.
Jeff Eyet: The product owners sits above the product manager, is that right?
Adam Kallish: In some cases yes, in some cases, no. It depends on the company and the structure.
Jeff Eyet: And then finally, scrum master, is, is that, is that, that's not, is that a role or is that just a certification?
Adam Kallish: Very good. Yeah. You can get certified to be a scrum master.
Absolutely. Through the Agile Institute, et cetera. A scrum master essentially is the person who controls the, sort of the efficiency of the sprint. Okay. They're not the product owner. They're focused on, we have, we have, we have a, we have a backlog of work and our team's getting the backlog of work completed in the [00:20:00] commitments of the sprint.
So that's the role of, of a scrum master. And then, and, and, then you have, sometimes what they called the scrum of scrums. So that's a person who, there is actually a scrum of scrums, who actually looks at all the actual, sprints, sprint teams, for example, the Spotify model, for those of you who use Spotify, the music service, they actually have the Spotify model. The Spotify model actually uses many, many, scrum masters, who then report up to the scrum of scrums.
Jeff Eyet: Got it.
Adam Kallish: Yeah, absolutely.
Jeff Eyet: Now that, that, that was helpful just to, there were a few questions that came out and then, so I had to frame it as, as one box. I'll ask this question to get you back on track.
I mean, these, I love, love the use of the digital platforms and the integration. As Google's, you know, with so many organizations on Zoom
and Google Hangouts, is Google Hangouts always the default? Is Google moving to Meet? Is that changing? How does Zoom fit in?
Adam Kallish: Yeah, that's a good question. Yeah. Yeah. Teams should really use whatever platforms they're most comfortable with.
So I want to be very clear there. So if you want to use Zoom or another telepresence play from like Skype or I don't know, BlueJeans or, I don't know, whatever, then everybody should use that. But there should be a telepresence platform that the team uses, whatever it is. And actually, for example, Slack actually has telepresence built it.
So you could actually use the telepresence in Slack too. Right. But some people don't like to do that. They want to use, for example they want a telepresence platform that's separate. That's fine. Go for it. You know?
Jeff Eyet: Cool. Alright, let's learn about APIs.
Adam Kallish: Okay, great. So, APIs allow for the horizontal integration of services.
That's really what APIs do. Without APIs, our digital world would fall apart and the amount of software development would go way up. Okay. So here is a diagram in my course. So for example, MURAL has APIs [00:22:00] that feed into other platforms, GitHub, for example, feeds right into MURAL. ZenHub and GitHub and MURAL.
There's an API through Slack, so all that stuff goes into Slack. So you can see the information sloshes between platforms, depending on the work that's been done. So for example, in Slack, if something was done in MURAL, we would get, we would get a notification in Slack. That's something that happened in MURAL.
So the great thing about it is it allows for the fluidity of understanding of a team, of what's happening in what platform, and when. Because there's redundancy between the different platforms in order them to horizontally work together. That's the beauty of APIs, and I wanted to show this because this is very important that people understand that you could actually horizontally integrate your digital platforms together to get better efficiency.
Are we cool? Okay. Now, another thing is, we live in a mobile world, right? I don't think this should come as any surprise to any, anything. An agile culture, my course, the premise is that work can happen 24 hours a day, seven days a week. There is no traditional work cycle. You can be up at five in the morning, three in the morning, do stuff.
That's fine. Students use their mobile phones to do work and communicate. So actually people were actually using MURAL on their mobile phones. Okay. People were using GitHub and Slack on their mobile phones. So the work was happening all the time, even if they didn't have their laptop with them or anything like that.
Mobile really helped us, increase, greater velocity. Okay. So what I want to do, so I'm going to stop here because that's, that's, that's sort of the talk about, about agile and design thinking and the rationale for the course, et cetera. And I'm going to talk about individual [00:24:00] methods that we actually used in MURAL, but I'll take a temperature check, Jeff.
Jeff Eyet: Yeah, thanks. Thanks, Adam. I appreciate it. I've got a question that came in is just sort of a, and maybe you're going to get to this in your MURALs, but the API discussions, great. I myself could probably explain it maybe to my daughter and then she'd get bored. And I would feel like I knew what I was talking about, but I really...
Adam Kallish: Or she'll explain it to you.
Jeff Eyet: Yeah, exactly. That's the trick. How about a question that came in was this idea of how to get APIs. Do you have an example of an API in action or how it works specific to these platforms maybe in your world?
Adam Kallish: Well, APIs are essentially just packages. You know, you don't have to build, I mean, you can build an API if you want, but essentially if you go into Slack, they actually have, oh, dozens of APIs. Google has dozens of APIs. They're already prepackaged, and what you can do is you can connect it directly to the service without knowing any code you essentially turn it on and your single sign on your SSO, essentially. We'll then connect it together. We'll connect your account with the service.
It's that simple. There's no complexity to APIs, so depending on the platform, depending on the platform you're using, you can do a search and actually find out all the APIs that they offer to other services and you can stitch together your digital ecosystem.
Jeff Eyet: Nice. I like that analogy. Stitching together the global ecosystem.
Adam Kallish: Yeah. Cool. Other questions?
Jeff Eyet: Let meclear the boards. I don't know if anyone has any other questions about APIs before we take a deeper dive into MURAL. And, also if you, if you notice on Ward's name, on his, next to his name, he has that one star. It was kind of a cool system we came up with to help us understand where everyone's at.
And so if you, you know, if you don't mind renaming or just even dropping in the chat, you know, give us three stars or you three-star kind of Ninja at MURAL two, are you just kind of rolling it out? One, you're just exploring, just give us a real temperature check. The more stars, the more experienced. The [00:26:00] more stars, the more experience will help us know how deep to go and to Adam if you don't, before we, while folks are putting that information in, do you mind just scrolling back to the API graphics, somebody was having a little bit of difficutly.
Adam Kallish: Absolutely. More than happy to do that. Here we are.
Jeff Eyet: Alright, there we go. Thanks. Yeah, thanks Jay.
Adam Kallish: Cool.
Jeff Eyet: Alright. Yeah, we're good. Thank you, Don. All right, perfect. Okay. Right. That's a good example. Thanks, Adam. Adam K?
Adam Kallish: Yeah. Thank you. What I'd like everybody to do where it says specific course MURALs. There's five MURALs. You could either follow along with me and look at it through a Zoom, or you can press on the first one, which are the hopes and fears.
So I'm going to go into the hopes and fears MURAL right now. And, what I do in all my courses and even in all the working sessions that I do, I do a hopes and fears. Which actually, students fill out before the first day of class. And this allows me to understand what their apprehensions are and what their hopes are.
This is done and a lot of companies now, it's sort of gone mainstream, which is great. And then what I did was I actually then clustered them into themes or, or we would call ethics. Actually, they use agile bodies of work. So there were lots of hopes around understanding, preparation, people, process, application, and leadership.
Okay. It's fairly common in my course. Then there were fears about the application of agile, about this agile, really support collaboration is agile, all talk and no action, about the struggle of using agile and then about follow-through. And so I want to make sure that, that the empathetic human dimension of agile is addressed, because it's not just a mechanical exercise.
It's about team culture and their ability to work together to get work done. Okay. And, and, and MURAL was a great tool for [00:28:00] this. And then we voted on the hopes and fears. So we actually did a vote on all of them. And then we created a short list. And then that we actually used in our reflections, those that voting we actually used.
And I'll talk about where reflections are in a minute. Okay.
Ward Bullard: Adam, can you, do you mind just going down and hiding cursors again on this MURAL?
Adam Kallish: Yeah I'll be more than happy to, yeah. Yeah, I just, I just did. Yeah, I got it. Thanks Ward. Anyway, so, so, and this was a customized MURAL, you know, and, and I created this, and then I created a template that I actually used for other things.
Okay. So if you go back into the specific course MURAL, I'm going to talk about the social contract. So in agile, it's, teams have what they call a social contract. And the social contract is based on the five values of agile. It's based on trust, openness, courage, empathy, and respect. Those are the five values of agile.
And you can see the definitions right here. Okay. You know, so they're actually defined. All right? So it's not subjective. And then what the, what the teams do is they actually talk about what beliefs do we want to have and what behaviors do we want to have about trust and about openness and about courage and empathy and respect.
So we had a series of values and beliefs and behaviors, and then what we did was we created a short list, and this is our aggregated social contract. Okay. So trust was defined as the ability to create reliability and dependency. Knowing when you can be open and you don't have to be judged. Learning about each other in the system.
Willingness and then openness was the willingness to explore new things or the willingness to understand where a person's opinion is. I'm not going to read all of these, but you can see these, but the point was of [00:30:00] the social contract is to align a team on the behaviors that they want to have as a team.
And then when we actually did the work and then we actually reflected on the work, we use the social contract as a yardstick. Okay. That's very important. Okay. That determined the behavior. All right. So if we go back, we're now going to talk about, the goal hills and definitions and sub hills. Okay. So, this actually comes from IBM.
I worked at IBM for five years in systems, and, we used hills as a way to actually help product owners and management determine the goal of a project. The hill statements have a who, a what and a, wow, who is a persona? What is the, is the enabling task and the wow is the business value. And so there are three hill statements for every goal.
No more than three. And then what the students did was they actually chose one hill statement. So this one was held to, they actually took that hill statement and they actually broke it down and they defined every term in the hill. They actually broke it down and they created definitions of what each term was.
And that was a way to get subjectivity out of the hill statement and to actually get them aligned on the details of how the hill was captured. And then what they did was they actually took, the definitions and they actually broke those down into sub hill statements and they actually color coded them and map them back to the hill.
So this actually is a system of teams to, to decompose the goal into hills, into definitions and into sub hills, and then to easily trace back the detail of a sub hill back to the hill and then back to the goal. Okay. If you want to learn more about this, you can go to IBM's website. It's open source, and you can learn all you want about [00:32:00] hills and sub hills and things of that nature.
I'm not going to get you guys trained on this...
Jeff Eyet: I was going to say, this is a, this is a, you know, professional level MURALing here, just with the design even in and of itself is beautiful. But definitely, and you're outlining…
Adam Kallish: By the way without MURAL, this would be very difficult to do. It would be very hard to do. You'd have to use Excel or, you know, I don't know, whatever.
Jeff Eyet: This would be an unbelievable Excel document.
Adam Kallish: And I've seen them believe me, Jeff, I have. Okay. So then, in, now we're gonna actually talk about user stories. So if you press on the user stories link, that will take you there. And by the way, I did, I did not create this MURAL. One of the teams did. So this is a, this goes to Jeff and Ward.
Teams actually found new uses from MURAL. I mean, I sorta got them started, but they were creating their own MURALs. That's absolutely incredible teams. So what I love about this MURAL was they actually took the hill statement, which is on the, on the left vertical, and they actually then created the story statements.
Oh. So they had 10 story statements and they created essentially a grid. And they could look at them at a glance. This was a fantastic use of MURAL. I mean, I love showing this MURAL because it's incredible. Yeah. It really shows,
Jeff Eyet: We look at it vertically. So say story number one was a project manager that got their goal and then they have their rationale.
Adam Kallish: Exactly. You got it. That's exactly it. That's it.
Jeff Eyet: And then what's the, to continue. So they develop all these stories and just sort of grounded in your, in your process, these stories is, I'm sensing are to build empathy with your user, to explore different viewpoints and different users, how they would access your product or service.
And then what if that's true, then what would be the jumping off point?
Adam Kallish: Not necessarily Jeff. Really stories are a way to make tangible the actual, sub hill [00:34:00] statements. So, stories and agile are very specific as, as a user, I want to achieve something so that I can get a benefit. That's that's like an agile story and I don't care where you are in the world.
That is an agile story. So these agile stories provide specificity, Jeff, for teams to actually be able to then create tasks. So if a story that there's a program manager, I want to receive performance report of game sites over time so that I know which one needs to be improved. You could then essentially develop a series of tasks in order to make that story happen in your backlog.
Jeff Eyet: Nice. That's the question that came in is just the, you talked about IBM and a lot of their methodology being open source there. Does IBM offer the MURALs, or are there, is there any way for the users?
Adam Kallish: The short answer is, no. I, I will let Ward maybe address that a little bit more because, I was at IBM when MURAL was, was, brought a board as a platform and we actually helped MURAL create the enterprise version of MURAL.
And this is what it was called. This is when it was called MURALLY. It was not called, MURAL, it was called MURALLY. Okay. So I was there when that happened. And so IBM really embraced MURAL as a way to quickly ideate and organize people's thoughts. That was, that's the power of MURAL. And, Ward, there actually may be certain IBM practices that actually you can find as templates on, on MURAL.
I don't know, that very well may be the case, but I would go to ibm.com, to their design thinking section, and they may actually have some certain templates. I don't know.
Jeff Eyet: Well, and, and, and to build on that, Adam, and I think Ward that's probably a great teacher's lounge for next week, is to leverage some of these agile, templates and, and talk about those.
So I will plug the teacher's lounges at the end, but [00:36:00] it's, a way, just a more informal setting to kind of let you play with some of the advanced features of MURAL.
Adam Kallish: Wonderful. Okay. Okay. We're on the home stretch then. We, we actually did sizing, cause I talked to, everybody talked about the story points.
That was a little while ago, but I talked about ways to estimate the difficulty of something and they give them story points. So if you press on the team sizing. We actually, I actually created this MURAL as a template and it's, it's done by t-shirt sizing. So either either stories can be small, it could be medium or can be large.
It's a very simple way to sort of categorize their stories. Like this is a small story. It's easy to get done. Not a lot of effort. This is a large story. It's going to take more people more time, more level of difficulty, so you can categorize your different stories in small, medium, and large, and then you can group those together in your sprint in order to get the work done.
So the only way a sprint could actually get done as to understand how many small, medium, and large tasks can be done in two weeks. That's really what story sizing is all about. Okay. And that helps, that helps prioritize your backlog. And then the last MURAL that I'm going to show you today is called the team reflection.
Okay. The weekly reflection, I'm going to go into that right now. And what's very important in agile is that after every major deliverable in a sprint, the team is supposed to reflect on how they did as a team. Very important. And so there's three key questions in the agile and a reflection that you ask as a team.
What did we do right? Or what worked, what did we do wrong, or what didn't work, and what can be improved for the next sprint? That's the continuous improvement aspect of agile. Okay. And so, my, my course had four teams. And the teams would actually fill this out before, [00:38:00] we met as a team, as, as a class.
And then we would actually, the team would get up and they would describe their struggles and their successes, and the other teams can actually hear that. Okay. And so teams didn't feel alone if they were having a difficult week because maybe all the teams were having difficulty that week. Okay.
So it's very important that an agile, for agile to work, you have to have team reflections. If I've actually gone to corporations that don't do reflections, I'm like, how do you know how teams are doing as a team if you don't do reflections? Reflections are a way to continuously improve the performance of a team, which improves the velocity in a sprint.
Okay. Very, very important. And then lastly, what I'm going to do is I'm going to actually show a video. I actually have a video, which there's a link, in, in, in MURAL, and, and this is an actual team reflection. So I'm going to play it for you. It's a couple of minutes long, so just bear with me.
Okay. And, I put this on YouTube, you know, so if you press on it, but I'm going to play it in, in, in Zoom and I'll turn up the volume hopefully, and you can hear it.
Unknown: Feedback from the last reflection really boosted the teams. Everyone created e qually in Slack, too.
Yes. And then we got it back from everyone, everyone tossed ideas around...
I think, [00:40:00] yes, I think he's very happy and doing amazing, Tammy's not here, but it doesn't matter this week.
Yeah. Wherever you want, okay?
Adam Kallish: Alright. I can, I could go, you could actually watch this video, the full length of it, you know, but gives you a flavor of what a reflection is. And the first person who talked was the product manager. So the product manager would actually start out the reflection.
Okay. And then all the other team members would then chime in or talk about issues that they were facing, either in terms of what went well, what didn't go well, and what can be improved. And then the next reflection to let you know the next reflection, which was the next week, you start out with the three things that you said you were going to improve.
The previous reflection. You always start there, did you improve or didn't you improve, and why? And then there's new issues, for the next sprint, right, that need to be improved. And then so on and so forth and so forth. And, and team, team members who had never done this before, really felt this actually helped with team harmony and working out issues and actually improving the velocity of the team.
And then, just to let everybody know, I actually put, in MURAL, if you want to find out more about me, about the Institute of Desig n, there was an actual article that was written in Microsoft about the use of ZenHub in my course, so you could actually learn how ZenHub was used in my class.
And then I actually, I'll put a blog post that I just wrote called the Dispatch from Human Centered Design, you know, about some of the writing that I actually do. And so with that, I'll turn it over to Ward and Jeff, if there's additional questions or if we want to open it up for additional questions or comments. Let's do it.
[00:42:00] Jeff Eyet: Thank you, Adam. One of the questions that came through, I guess to get it started and then please drop your other questions in the Q and A or in the chat. But, you know, what do you think about rules for a retrospective or reflection section? You know what is said in the room, what stays in the room, those types of things.
Adam Kallish: Yeah, that's very important. Usually the first reflection that a team has is that this is the most difficult because the team is new. And, and remember we go back to the social contract, remember how I talked about that? They actually use the social contract as the art spec. So in the beginning they talk in code to each other because they don't want to get each other upset, you know, type of thing, if something didn't go very well. But by the seventh, by the seventh iteration, because my course is seven weeks long. By the seventh iteration, the trust level's very high. The, the, the, the, what went right, what went wrong and what could be improved. It's very natural at that point because I've done seven iterations of it at that point.
So it really becomes almost like rote, and it becomes much more meaningful, as retrospectives, much more honest, as well, and the teams could actually hear the other team's retrospectives. This isn't just one team talking to me. All the other teams in the room could hear each retrospective and so they could realize, Jeff and Ward, that they weren't alone.
They weren't the only ones having that problem. Other teams were having the same problem. Very important that you don't feel alone.
Jeff Eyet: Yeah. That's massively important, particularly in an academic setting or you know, when you're new to a process. And, I find that a lot of times you're trying to overlay a process with the technology and when you're learning both at the same times, that can be tough.
A quick question, from, from Adam is to, from Adam to Adam. If you're using Azure DevOps or Jira, how do you see MURAL used in tandem.
Adam Kallish: The same way. I mean, those are all just [00:44:00] flavors. Jira, Bitbucket, you know, they're, they're all there. There are equivalents to, for example, GitHub, you know, Bitbucket and GitHub are the same.
You know, they're, they're equivalencies and there are other platforms. So, so you would use MURAL, in my opinion, the same way, I don't think it would change at all.
Jeff Eyet: Yeah. Cool. So what about when you're talking about the agile teams, you know what, what are some cool ideas? Born agile team, one of the examples they gave was like a pair rotation where only two of the team review a code or feature and not multiple ones.
What's your response?
Adam Kallish: Yeah, that's called peer programming , and that's very important in agile and in any business is the people doing the work shouldn't check the quality of the work because they're too close to it. So you actually have somebody else that has similar skills. Check the work, and that goes back to the Kanban that I talked about earlier.
Kanban is essentially a Toyota framework for tracking work. And that's what, that's what, ZenHub is. ZenHub is essentially a Kanban, that's really what ZenHub is. And so, for example, you, you not only have done that, you also have closed, there's two levels of done. There's done,
Jeff Eyet: Right? Okay.
Adam Kallish: There's, there's done, then there's QA, which is the pair programming aspect, Jeff, that you just talked about. Yep. QA, and if something doesn't match the task, it goes from done back into in progress. I see. Okay. It's kicked back and then it's resubmitted as done. And if it needs QA, then it's actually closed and closed means like done, done, done, done.
You know, it's like if it goes out of the backlog. Okay, so there's two levels of done in agile, but there's clear specificity of what done means and what closed means. It isn't subjective. [00:46:00] Okay.
Jeff Eyet: Yeah. Very cool.
I think one of the, one of the questions was, just, you know, specifically like, is there, any of the courses that you teach or anything,
I mean, I think some of the specific, some of the other instructors on the, on the call are looking for some of your sauce. I don't know if you don't mind if we share your email address individually, are you free? Give it out to the others. It's...
Adam Kallish: Please do. Um sure if people want to contact me they can.
By the way, this course is the only agile course offered at the Institute of Design. And the, the course has become so popular because the students virally market it to each other because it's based on electives. This is an elective course. It's not required that actually now faculty, I did an actual faculty working session on aspects of my course so they could actually integrate the agile into their courses.
Jeff Eyet: Wow. And what, what, what was the, with the range of disciplines, I mean, is designed focused obviously, but it is, that seems like it's a really exciting step to think that other instructors are looking to incorporate that into their
Adam Kallish: It is because the pressure on the semester is getting greater and greater and greater.
And so the real question is, what is the role of contact time? So if you, if you have a course that's three hours a week contact time now, that's your responsibility. That's not really enough for learning. So the great thing about agile and the tooling, everything I've talked about today is that really the course becomes a conversation over the whole week.
It isn't just about the three contact hours, it's about actually, answering questions and feedback all through the week because there's no hidden work in agile. So when I would actually go into my class, my physical class, Jeff, for the hours. I didn't ask teams like how was your week or what did you get done?
I already knew everything going into the court, [00:48:00] going into the classroom. So the classroom becomes a laboratory to improve the work, to improve the thinking. You see my point, it's not about lecture. It's not about pushing information to the student because that's done outside of class. The class becomes a laboratory for experimentation and improvement.
Jeff Eyet: Yeah. And I want to touch on that, Adam, because that came in as a question here. As you know, there's a, one of the participants is a teacher and they're looking to take their class online this fall. And it's, so some of the potential challenges either with tools or other students, I can share from my experiences that I'm, I'm dubbing it, the Eyet theorem of online education is, it takes half the time to get, it takes twice the time to get half the work done.
Adam Kallish: Absolutely.
Jeff Eyet: It becomes an, an exercise in subtraction, at least from a lecture standpoint. And, and what really makes an online course successful, and I've gotten this feedback from my students, is that they are actually doing the work, but your students could be sitting on their, you know, on their backsides for four to six hours a day.
And you're coming in, obviously thinking of your classes as the center of their world, but you could be the third subject they've had that day. And so how do you really make it impactful, make it stick? It has to be interactive, which is what MURAL allows us to do.
Adam Kallish: Absolutely. And I can tell you, Jeff, that MURAL by far is the most virally marketed platform at the Institute of Design.
So there's a lot of accounts that have been opened up by individual students. When they see what MURAL can do because you don't have to explain MURAL. Once you see MURAL for a couple of minutes, you already get the value of you already get it. I will say this, and I agree with you, Jeff, that an agile, remember I talked about the perception of agile is that it's about fast.
It's not about fast. It's about velocity, which is different. Velocity is very different than fast. [00:50:00] They say Agilists will say, if you're going to do agile, you have to slow down in order to speed up. So that goes directly to what you decide. And you have to do twice the thing. You have to do all the work and twice the time in order for you to get better at it, and then you can get more efficient.
Okay. That's exactly what agile is about. You have to slow down in order to speed up.
Jeff Eyet: Nice.
And let's, let's land with this question here is, Well, one of the questions that are coming in here is this idea of do you have any experience with scaled agile frameworks in terms of managing a bigger organization in an agile way?
We're talking about teams and project focused with that agile. Any bigger picture thoughts on agile or is there another platform or methodology you suggest?
Adam Kallish: Well, well, no, I mean, obviously when I was at IBM, we were working on enterprise solutions, right? What millions of users. So we, we actually had, you know, projects, with teams around the world.
And we had, like for a scrum, we may, we may have had 30 to 40 teams working in, working in a sprint. No, they're individual items in a sprint and you had all these individual scrum master's job who were actually tracking the velocity of the teams and all that work had to roll up into something that was understandable.
Okay, so agile at scale, the one that, one of the things about agile is that it can scale just like a platform can scale in terms of scale up and scale out. Agile is perfect for that. Now, design thinking is not good for that. Okay. Design thinking does, does not scale up and scale out the same way that agile does.
And that's why agile and design thinking are essentially two sides of the same point. Think of a coin, heads and tails. Design thinking is heads and you know, the back of the coin, the tails is, is, is agile. They work together.
Jeff Eyet: Yeah. I, I totally agree. And as much as divergent thinking is thought [00:52:00] of, as a key skill within design thinking.
You're ultimately coming to a prototype or an experiment, to run. So the output is actually a converging, exercise, as I like to say. And, and particularly when I teach design thinking in an entrepreneurial context, it's that product market fit. But once you have that product market fit, design thinking does not scale.
And so that's why I totally agree with you that agile is a natural follow on to that. So, all of the design thinking instructors on the line, if you want to double your course load, just pair it up with some agile. Ward, did you want to add anything here as we're kind of coming into the home stretch?
I think there was one last question and maybe I'll just toss it up to both of you for any last second comments, is that, you know, MURAL compared to other online collaborators. I know Adam, you talked about it being very viral at ID, you know, just, and I mean, it's very evident from the work that you've done.
And besides MURAL being free for educators, easy plug, but anything else?
Adam Kallish: No, I mean, there, there are, there are other, I think about MURALLY, which then became MURAL is, it was really, it was really one of the first, and then it scaled incredibly. Okay. So it's a very successful platform. There are lots of imitators out there, which I, which I think we should embrace.
I mean, I think there's lots of room for lots of people offering something. MURAL, to me is a great balance that what MURAL has been able to do is that they've added capabilities without adding bloat. So bloat is bad in a platform because it becomes more complex to use. MURAL I think, MURAL has done a great job of keeping it simple, but adding more sophistication.
The one recommendation I've made some MURAL, because I also, I've talked to product managers of MURAL, is that they need to integrate AI into MURAL. It's not a farfetched thing. It's data. Okay. So I [00:54:00] think they need to make MURALs smarter, in terms of what AI can do for your MURAL? I think it would become a way more powerful platform if they use the actual machine learning and, and, you know, but I'm sort of jumping ahead there, but, but I think MURAL is, is a great platform and it's easy to deploy.
It's easy to scale. And for educators, it's very friendly from a, like what Jeff was talking about from a pricing standpoint and, and, my students love it.
Ward Bullard: No, I'll just, and I'll just add, Adam, thank you for that. That I think the, I mean, I, I've, I've been using MURAL in my classroom also since the MURALLY days, Adam back five years ago. So, so, so, so, we're, we're OG MURALists. I think they, as you pointed out, there's a number of great solutions out there.
I think that, you know, really, I remember when I was working at SAP, I would literally, graffiti various posters in our, in our development halls that would say like, what new feature you added today. And I would say, actually, I what, what feature have you taken away? Like, you know, from your product, right?
It wasn't being used, it was causing exactly what you described as bloat. The, the, the real differentiator for MURAL in terms of why I've always thought it to be so attractive within the classroom context is the real simple and easy onboarding that we just experienced today around that anonymous user function.
We weren't stuck in having to become, you know, members or guests were immediately able to get into the MURAL, and while we weren't necessarily participating in this one, in a, in a live brainstorming session. The fact is it's a real easy way for people to jump in and get, get going. So, I mean, that to me has been something that I've enjoyed really since the onset.
Adam Kallish: Right. Thanks for sharing that. I think we're at the top of the hour, Jeff. We did it.
Jeff Eyet: It's like we're professionals or something. That's again, a thank you Tim Beer. Thank you very much. Christina, thank you for the kind words, Thorton, [00:56:00] we appreciate it and we will make the recording of this available and we'll be doing our best to distill this into a blog post as well to capture some of Adam's real high level thoughts.
But in the meantime, please check out the resources he made available through the MURAL board. And we just want to extend a warm thank you to Adam for taking the time today. Next week we are going to be having office hours on Tuesday, Wednesday, and Thursday. You can learn about those at mural.co/webinars, where Ward and I will be taking a deeper dive into different aspects and if you have a pro, program specific questions, we'll be happy to, to lift those up and answer for you.
Ward Bullard: Until next Friday session too. Don't forget,
Jeff Eyet: Next Friday, Adam will be on the other side of the screen as an attendee, when Ole Sorenson will be, bring, coming to share his tips for using sketch and iconography in MURALs to kind of lift up and make them, increasingly engaging Ole, the author of Visual Collaboration.
So there we go.
Adam Kallish: Oh, I'm coming to that for sure.
Jeff Eyet: There it is, man. I can even get you a backstage pass Adam.
Adam Kallish: Good job, my man. Alright, everybody have a great weekend.
Jeff Eyet: Bye bye.