Introduction

Ray Arell 0:53

Good morning and good evening everyone. This is the Agile Coaching Network. The Agile Coaching Network is brought to you by Agile

Is Agile killing or helping innovation?

Ray Arell 1:05

Alliance. If you don't know who Agile Alliance is, we're a member supported organization. We've been in existence since the manifesto was signed. So please go give a look over to Agile Alliance.org to get an idea for what we do as an organization because your investment and your time that you've put in into this great community of practice helps us to do things like the Agile Coaching Network and a whole bunch of other different programs to help make Agile better. So I'd like to kick off today's conversation with a couple of articles that I was reading over the last couple of weeks. I was at an agile event in Portugal and there were some conversations on this as well as some of the online conversations. There was a couple of Forbes articles as well. And specifically it was talking about whether or not what's the innovation killer in your business, and one person that I had a conversation with in Portugal was a little bit iffy on if Agile was killing or helping innovation within their company. And so with this, I was thinking about what perspective, if we were thinking about Agile in the context of innovation itself. One of the things that's always been a theory t hat is that we have a set of constraints that are in the system. Those constraints are either beneficial constraints, meaning that they help to focus people on a particular delivery or a particular goal that we need to get to. But in other factors, if these are too constraining, they start to inhibit the system and not allow people to have enough time or resource or other things that it's necessary in order for them to be able to innovate. And in the theory of constraints, it's quite simple, is just how can we systematically improve the constraint system within the business so that it's no longer the limiting factor with whatever we're trying to go accomplish. And in the case of innovation, as you know, we're trying to come up with new ideas a nd new ways of approaching different problems that we have and basically to reach out ways that we can accelerate coming up with new developments itself. And so I started thinking about all of these different methods and we started brainstorming at this one session that I was at is scrum an innovation killer, i s safe an innovation killers is TDD and innovation killer o r any of the other hundreds of different Agile methods that are currently today o r even maybe the Agile mindset itself, are those the constraints that are inhibiting us from using Agile in an effective way for innovation? So I'd like to kick off t he, the question is what part of Agile is helping innovation, and what are some of the areas that we need to improve it in order to be able to improve how Agile helps innovation itself. And Linda, you want to take a crack at the first part of this?

Linda Cook 3:53

Hi Ray? Yes, this is Linda . Hi everybody. Thanks for joining the session today. So I think there's a very interesting question in of itself. There are very few aspects that sort of require innovation, if you would want to say that. So on the plus side, I think we're using agile practices and methods helps us to be more innovative is really through retrospectives as a practice in of itself. It's a time we stopped to reflect and it's in those moments where we allow ourselves that time to think that the, you know, we get the brain muscles moving and we start thinking of how could we be different? That in of itself while was not, you know, defined as innovation to me does create this space for new thoughts and ideas to percolate up and get into the team. So I think by that practice, Agile supports innovation in their methodology specifically safe actually calls out innovation as a defined event and their um, their process. And while we could debate some of the merits of safe and, and not, I would say at a minimum at least they do call out a pause in a very rigorous cycle of activities that's intended for teams to stop and reflect and innovate. So I , I'd say, you know, that's certainly a plus on the, on the downside, I think folks who are consistently using scrum and scrum like practices, whether they have a two week cycle, or a three week cycle or some other cycle, it tends to become a grind. And that in of itself, the repetitive nature o f always being on, always moving from one activity to the next. I think tends to be an inflation downer sort of thing. Innovation, sorry.

Ray Arell 5:43

Sure. Hey, Hendrick, do you have an opinion on this ?

Hendrik Esser 5:45

Of course I've seen the , the effects of introducing capital a Agile and it's a bit like, like Linda was also suggesting here and the Agile implementations, usually what's not on the backlog isn't done. So if innovation is not on your backlog, innovation doesn't happen. That's in short what I've seen in the number of companies. Um, then the safe approach of making a pause every now and then is already a step maybe into the right direction. But generally it's not solid that you can say, okay, every three weeks we just pause and then everybody becomes creative. All of a sudden produces a lot of great new ideas. Usually ideas come. Um, and innovation, the definition of innovation for me is creating value from ideas. And there's two steps in there. One thing is creating these ideas and this is a constant flow of ideas that you need to capture and then creating value out of them. They are actually agile as good at that. So I would distinguish two things. Creating ideas and their maybe Design Thinking is, is the better approach. I wouldn't look too much into agile there . And then creating the value out of the found ideas here. Agile actually can help. So , um, what , what I've arrived at in the meantime is that you maybe need to have two parts of your organization or you need to split this generating ideas and the Design T hinking part maybe from the agile execution of parts of your company. So that's a bit what I've seen and observed and found useful.

Ray Arell 7:19

Sure. Jörg how about you?

Jörg Pietruszka 7:22

I agree with Henrik a lot, so it's really about having those ideas and making them flow. It's not a point in time where you can do this. This doesn't work in any methodology. You can't force really innovation on people. You need to give a bit of space and time and I've seen teams that actually ask for this time actively and they just asked for certain, let's say innovative brainstorming or whatever . You call it, additional time at the end of sprints and that's a good practice. I can advise that. Sometimes you make people aware that this this will happen and that they have a certain say in what they can innovate on a , because the direction as as Hendrick said , what do I want to achieve is the first thing . If you don't approach your goals with the Agile M indset of I need to think about what matters, then you will not discover that innovation matters. But if it's natural and just happening out of the blue and that's not true, you need to listen for it. The good ideas for the go away if you'd all listen. So that's just a standard practice as well and very simple . If you don't have a bit of fun while you're doing your work, you will not be innovative anyway, regardless of method.

Ray Arell 8:27

I fully agree with that. Fun actually does lead to some innovations. Raven, you have your hand up. What would you like to add?

Guest Speaker 8:33

Yes, so hi. Ray. So you know what, I just want to go back to the basics of what the definition of agile means. Uh , and in its bare bone shape is just to create and respond to change. Right? And so, you know, with that said, if you're going to do innovation, innovation is just a new idea. It's a new solution. And in order to do that, you have to create and respond to change. You have to be able to inspect and adapt and you know, receive feedback. So making that feedback or making that information more transparent to others so that you can get more feedback. Too. Perfect or for the betterment of whatever you're trying to create.

Ray Arell 9:12

Okay. Can I, can I ask a clarifying question in that? So I mean if you look at like scrum, sometimes people implement scrum with a more disciplined fashion. So scrum masters and product owners are, are really constraining the system towards the delivery of the existing backlog. Do you think that, is that a plus factor to that or are there people just doing scrum wrong?

Guest Speaker 9:33

So I don't believe I'll say this. This is what I usually say that not everyone practices scrum to all of the rules that have been given. Um, however, if you follow and believe the 12 principles of Agile and you believe in the values of Agility, you can create your own framework. So it is what is best for the organization. And I hope I've kind of answered your question. I don't necessarily look at it as a right or wrong way. As you practice Agility, I look at it as what's best. Maybe portions of scrum work. Maybe we implement a little bit of Kanban to put limits in and maybe that helps us as an organization or maybe we use a little bit of XP. It all depends, but I don't believe in the notion of wrong in Agility.

Ray Arell 10:26

Okay. Very good.

Guest Speaker 10:28

are you there? Yes, So my take on this is like Agile helps innovation because of the continuous improvement that part of Agile and agility. We continuously receive feedback. We are continuously encourage process improvement or technical capability solutions, all that as part of this continuous improvement. And we encouraged the team to be uh , you know, taking this forward , uh , and have the transparency , uh, so that uh, the leadership and other team members are aware of what is required and what needs to be done in a priority order. The other thing , uh, in my organization we practice safe and we have , uh , inspect and adapt print that happens at the end of every program increment . And we have hackathon kind of activities which brings in innovation. People are so excited to be part of it , uh , as they can do something different than what they do. On a regular basis and this has led to a lot of problems solved and a lot of out of the box solution come out due to this hackathon kind of events. The other um , aspect of Agile that I appreciate is about the self-autonomous scene where the team makes their decision that the members are someone who is very close to the problem and they understand and know how to solve it better than anybody else. So they making a decision coming up with the solution. They all bring in innovation, lot of new ideas generated lot of efficiency rather than because of the whole Agile value that we get . He along with this model. Very good.

Ray Arell 12:06

Thank you very much. Bruce, what do you have on the subject?

Guest Speaker 12:09

I would just like to add to what people are already talking about out there. I like what I'm hearing. Uh , I think part of it is how empowered is your development team? Uh , if there kind of constrained on how it is they approach things. If you have a product owner who is focused on delivery delivery, delivery of bits and parts and pieces that they will be able to use, it's going to be very difficult for them to sit back and learn new approaches and investigate things. They might, you know, they're being forced, like I said, to work on delivering. The bottom line to me is does your product owner value refactoring or not? If they only look at the value of , uh , things that, that they can see, they are unfortunately going to be learning very late in the process that things take longer to build because they , uh, developers weren't allowed to go back and fix things in order to stop then learn perhaps new approaches to things. So don't have an empowered dev team at the P O doesn't understand what refactoring , uh , values that give , gives them as value on down the road. You're going to really stifled the innovation.

Ray Arell 13:12

So in this particular case, if you're trying to push everything out the door and you are not building Slack into the system by having clean code and refactoring it often so that you can build things quicker than you're saying that this is how an overpowering product owner who just has one thing on their mind, just deliver , deliver, deliver, can impact them. Is that kind of a good summary?

Guest Speaker 13:34

Yeah. I say, do they value, do they look at this as, as Slack or do they look at it as, as something where they are going to continue to benefit on faster and quicker business value delivery in the future?

Ray Arell 13:47

Sure. Thank you. Thank you for that . That Presonna.

Guest Speaker 13:49

Yeah. Hi. So kind of like what I 'm getting from all the people here. Like I just want to add, u h, to, u m, what e veryone's saying. Like it's like, u m, i dea, Agile does not kill anything. It's, I mean i t's been a recent trend on a l ot of different topics that's coming Agile kills this , Agile kills that, Agile... It's basically a how we kind of adapted and use it as fo r k illing or making things. So I mean, Ellen has a gr eat b log on like di scover t o d eliver stuff, right? So I feel like th e d iscovery part of things, that's where a lot of innovation happens and then Agile helps you deliver the, wh at y ou have discovered faster. And the re cent t hings about like design combining, design thinking and the lean st artup m ethods, problem solving phase, and then combining that with the Agile methods on like faster an d i ncremental delivery and uh , f ocusing on the learnings and pivoting based on what we get. That's kind of, I guess that wi ll k ind of go hand in h and an d e nabling the, u h , i nnovation rather than killing it. So it's, the Agile focuses more on the building, the, u h , p roducts th at I h a d o r t he things right. And then we need to focus on other things. I u se other techniques for building the right products. Right. So that's wh at I t h ink.

Ray Arell 14:57

Thats very good. Mohammad .

Guest Speaker 14:59

Hi. Thank you. I believe that , uh, one very important , uh, factor is the self organizing characteristic of a scrum. So that's in itself compared to a traditional organization help people become more creative and innovative. I understand that the overall culture of the organization is very important as one of the participants, you know, commented a few minutes ago , but I guess that just the characteristic of self-organizing is very powerful in scrum and Agile.

Ray Arell 15:35

I fully agree with that. I'm pleased to hear the Agilest on this call , uh , take the impression that we can be at least of the constraints that we build into our own

Is there value in determining metrics based on cycle time? What metrics are other organizations using to provide leadership visibility into team performance?

Ray Arell 15:46

systems. And I think that in the case of innovation work that I've done in the past, we understood that the constraints of the system where you're using, and we knew that in certain cases that perhaps scrum wasn't the best methodology to go use for maybe the big front end ideation stuff. It was different methods that allowed us to learn quicker. Let me go ahead and switch off to the main questions that are over on Slido. So the top question we have up here is from Cindy. This is another metrics question. We get a lot of metrics questions over the number of years that we've been doing this, but we'll go ahead and go for this. Again. Is there a value of determining metric base metrics based on time cycles? What metrics are the organization's using and providing to leadership for visibility on team performance, Hendrik or your org or our Linda, do you want to take a first crack at this one? Okay .

Hendrik Esser 16:40

I think a first crack for me is that the teams should own the team's performance. It's not the manager assault with a team performance. And that sense I'm very allergic against using metrics to see like, I mean especially when you're , I've heard this fro m a couple of companies, fortunately doesn't happen in the company. I work for that people that use velocity burned on beat and so on for measuring and comparing teams. And that makes, I think the workplace extremely unsafe. So I think that's defiantly not a good idea. And I think how performance measure measurements should rather be on the outcomes , um , of an organization rather than individuals or teams.

Jörg Pietruszka 17:23

I strongly agree. It's totally different to observe. Whether you do what you intend to do as a team and learn from it as to somebody from the outside trying to look at a metric and making a decision from this. If you want to know how the teams are doing, maybe be more part of the results. So see whether the people who are really getting the deliveries are satisfied or if they need something different and if they do them maybe should join sprint interviews or whatever meetings you have to clarify w hether expectations are met.

Hendrik Esser 17:56

There's another aspect to this question because the first part of the question actually is something that I like determining metrics based on cycle time. Of course we should measure a lot of stuff . The team to improve its performance meets certain data so a team should observe it cycle times and maybe other things that help the team to learn and improve. But those measurements should not be owned by the management.

Linda Cook 18:19

Agreeing with what the gentleman have said so far. I'd like to add that I'm , one of the values that I have found useful in using cycle time is helping to understand your team's backlog health. And I can say I've seen it recently where you know when I look at the product backlog and when I look at the full cycle time from the time an item hits the backlog as we intend to work on it, it's sometime to when it actually gets done, there are things that are well over eight, nine, ten, eleven months old. So that's an indication that it's time to revisit that backlog and determine which of those things really do have value and you're actually going to bring forward understanding your backlog. Health I think helps improve planning effectiveness as well as efficiency. So yes, I do find some value in it and of course unfortunately many of us have witnessed where metrics are used as a weapon against their own employees. And of course that's when the metrics take a a wrong turn.

Ray Arell 19:22

They take an evil twist.

Linda Cook 19:23

And in teaching teams how to use those metrics I think is another important role of who's ever leading the team. Whether that's their scrum master or they have a coach, but someone should help educate them on, you know, what types of questions and should we be asking ourselves based on the data that we're seeing and are there indicators here that would lead us to um , better outcomes?

Ray Arell 19:45

Agreed. Randall, what do you think?

Guest Speaker 19:48

Yeah, I've uh, I've just recently been , uh , looking at cycle time in depth and using it , uh , with the teams that I'm working with. Uh, the one thing I do like the metric, but the one thing again is like what we've been saying is that it is a single data point. It is, you should not act as strictly on the cycle time because the cycle time does not tell you are you building the right thing, are you doing the correct things? It just tells you how long it's taking you to do something from beginning to end. It's , but it's not really telling you what is the value to the customer of this thing. So I think it is, it's something that we have to use in conjunction with other metrics and just not stand alone.

Ray Arell 20:24

Okay. I agree with that as well. Daniel, what do you think?

Guest Speaker 20:27

Every time I see it, this some way to measure team performance, I start thinking how to , how the team may start gaming this metrics and isn't that dangers. If they start breaking things o r stories and in t he way that they are not e xactly i ncrements but they are just steps for a real story and they d ecrease the cycle time and say yeah look w e d ecrease the cycle time or the time and a half. They are not as actually doing the things t hey a re just gaming the metric--isn't dangers

Ray Arell 21:03

So, do you believe that there is a healthy gaming, meaning that you know setting a goal and actually legitimately moving towards that or do you think that most people are just in the mode of okay, here's what you want me to live up to, I'm going to cook-the-books for that. I mean what , what's your view on that?

Guest Speaker 21:21

Actually I don't know if there is a health metric, but just know there is always someone trying to get a promotion and loose . They'll think how to game , how to skip the metrics and give you, what do you want to say? A I need this type of time cut in half. Yeah. Okay. I'll give

Ray Arell 21:41

Interesting, interesting.

Guest Speaker 21:42

One thing with my teams, one problem that we had was we were taking on two larger stories and when I instituted , uh , the cycle time, they consciously brought those stories down into smaller bite size chunks that which is what I wanted. So in this situation I did get a , a very positive reaction, you know, or effect of me, you know, measuring the cycle time. So in this situation, and I totally understand, it's easy to game it, you know, any metric, especially this one. But in this situation it was the behavior I was looking for.

Ray Arell 22:13

Okay. So and in this particular case the team rose up and said, okay, yes, I accept this challenge and I'm going to move towards it, which is, which is good. Which is good. Pamela, what do you have?

Guest Speaker 22:24

I haven't questioned because we are in our organization, we are trying to show velocity versus actual actual completion. I was just wondering what other metrics people are using to show that projects are better off using Agile in addition to Agile self is a benefit over waterfall. I know internally, you know it's improved because we found a lot, lot of defects and we were able to fix them there and then rather than waiting until all the developmental is done. But how do you measure that? Okay ,

Ray Arell 23:08

I'll take a first dive at this. I mean one of the things that I've found going from a waterfall culture to an agile culture, one was everything delivered at the end, which you know, it , nothing was done until everything got tested and was ready to go into the shipment. Versus in the case of Agile, if you're doing incremental slices of functionality, value can be measured throughout the entire system itself. Meaning that after a , you know, a few increments, I could have something that I can demo and I can get customer feedback and understand whether or not my investment was actually a wise or not a wise one. And the way that I used to measure it is, is did we finish early? Did we manage scope creep better where the number of customer requests for those more towards the front end of the process and less than the back because we've been listening to the customers as we went through, a slew of metrics associated to when we met minimum viable product, you know, to be able to say that we could ship, we want to and we could ship earlier than normally a waterfall run. What I found with the waterfall stuff is, is it like all projects, they fit perfectly to the deadline that was set and we would go spend dollars on a, on a low value feature that nobody wanted and nobody would get rid of it. Um , and then we ended up having to go maintain it for seven years. So I don't know what other's perspective is on that as well. Jorg do you have an opinion that

Jörg Pietruszka 24:37

always try to approach it as , as you explained from the end result ? So what are we delivering, whatever getting paid for? Ideally I even tried to, to get feedback from the market, what is really used in, in what extent from a delivery. Uh, and if this is improving over time , uh, that's a clear indication that things are going the right way. A good metrics actually checking how people are selling your product. So talk to the sales people and if they are aware of things you are putting in there and sell this to the customer, that is obviously you're doing something that creates value for them. Uh, and probably revenue that's more easy than seeing what people really use. So I'm trying to think backwards from usage and seeing ways where you can grab it and then compare it to whatever you want to compare it to , waterfall data and whatever. Making the most money out of the time you spend on the product. This is one of the best ways to do it.

Ray Arell 25:39

Okay. Shauna , I just activated your microphone. Now you are one of the colleagues that was with us over at the business agility lab at agile.What do you have on this?

Shawna Cullian 25:48

One of the things, the question was what can we provide leadership on? It comes to metrics. I think what we need to understand is typically leadership is looking for metrics. When either a team, when they, there is a perceived notion that the team is not delivering something or maybe they're , they're needing to start new work; So, leadership is like, who can we, who can we tag to give new work to ? So when that happens, I think from internally the team wants to know how can we continuously get better. And I think that those agile metrics are really, really good for the team internally as what's been said before. But when , uh , once we can answer the question when it comes to are we working on the right thing and we can understand what's the adoption rate of our product and how has it been used in the market? Leadership typically starts pivoting away from the team

What practical techniques can help improve the cohesiveness of a team in an Agile environment?

Shawna Cullian 26:43

and start looking, start working up the value. So I don't know if that helped .

Ray Arell 26:47

I think that helps quite a bit. The person who had the question number three here, he actually said that he wanted to be present here during the next Agile Coaching Network when that one was red because he wanted it to give more context to it. So I'm going to do him a favor and I'm going to go ahead and not do that question and we'll go ahead and defer that to next week. Um, so the next one is, Oh , what are the practical techniques , uh , that can help to improve the cohesiveness of teams in agile? Jorg do you want to take that one?

Jörg Pietruszka 27:17

Yeah, definitely. I like to start with this one sort of cohesiveness. In the terms of day they are working on one thing. They are putting the same measures on what makes success. So from pong quality to listening to customers too , whatever you define, if you have a common view, cohesiveness is often very helpful in terms of they're ordering the same thing in the same way. It's the threat actually off making it very blind to developments in the word and um, to the benefits you have from diversity. So , um , these are the two points. But if , if you look at the positive side, give them shared experiences, celebrate success together. Maybe even be angry if something goes really wrong. Get, make it feel like a team thing. Don't make it feel like a personal thing. Try to get some joint experiences, maybe even outside of work, however you feel about this, that is definitely depending on culture. Uh , but one important thing that I find as a coach, address the team if you mean the team and don't try to speak to a single person maybe that forces you to get up out of a chair in a meeting and walk around the room so that you're looking into the eyes of everybody at one point in time may or trying to explain something. But to me it's, if you treat them like a team, they , they behave like a team. If you treat them like individuals, they'd be here for like individuals and if they treat them like individuals forming a team, they probably gonna do the best thing.

Ray Arell 28:53

Yeah. I , I found that I'm part of the experience of, of especially when our agile adoption was , was happening, we, we were very much an individual culture and then coming into a team culture, doing team activities together I think was very helpful. The other one, and I think you pointed on it a little bit there, Jorg, was that as a, as a manager, we would never just go point out one person on a team that might just delivered something and said that you're the MVP and you did, you know, all of this yourself or make sort of this kind of declaration to the rest of the team members that they didn't somewhat have a part because of the way that the award system was. And so what we learned to do is we rewarded people as teams and we let individuals within the team or reward team members, meaning that they could go off and give a person an award because they were the MVP, but don't single one person out.

Hendrik Esser 29:48

My experience with teams is that cohesiveness is pretty much about a team's daily experience. So , um, the question is really, I mean you can have team building events and so on, but often I've seen this to be around the artificial. So I now comes the fun part and then after the fun part we go back to work and the cohesiveness has not so much increased. So um , I think it needs to become really more personal. And for that, I think it's more something for retrospectives or a coaching , um, towards the team to increase the cohesiveness. That's a bit what I've seen. I mean the events are a good thing on top of that, but they don't often generate a cohesiveness. They are deepening.

Ray Arell 30:34

Okay. I believe that too.

Jörg Pietruszka 30:35

Maybe allow me just to add to this, because sometimes if you do small events every day than they'd have such a positive character. Like well , bringing the first cup of coffee to all the team members then or sharing this or whatever, that makes a big difference. Just the one time, show, I agree with Hendrik

Hendrik Esser 30:56

There is in, in Sweden, a very nice originally you could say in almost all companies, it's the Friday Fika it's , it's on Friday off renewal . There's always somebody bringing a cake. So, and it's sort of round Robin thing . Also every week, somebody else has the responsibility to bring the cake to the team. And then you sit there and have a coffee with a piece of cake and you are chatting with each other. And it's rituals like that I think create more cohesiveness.

Ray Arell 31:24

I definitely like cake. Shawna what do you have? s

Shawna Cullian 31:29

One of the things that I really like doing in teams is when we kick off the project using an agile inception. And um, for those of you who haven't used an agile inception, it's a two to five day , uh , kickoff that you do with the team where you you know, you align on the mission, on the goals, on the pain points that the team is trying to solve and you , uh, as, as you're a good said before, it's about the shared experience. So taking the team through the end to end journey on what they're building, why it's important, and even having both customers and stakeholders come in and explain to the team why it's really exciting that they get to , um, solve this problem and what it means for the organization. And by having that shared experience with the team, it really helps build cohesion and both motivation as well as alignedperceptions. And we talked about innovations and how they might innovate to solve that problem together. Um, and it's really, really brought a lot of my teams together.

Ray Arell 32:36

So give me, give me an idea of what the typical agenda would be in that as you, as you walk through and kick that off. Um, and how long does this take?

Shawna Cullian 32:45

Sure. Um, so what I typically like to do is have product use the lean canvas or a business canvas , um, you know, in , and almost like a , uh , story forms . So they go through that with the, with the team and, and really talk about why this is important to the business and the impact will make. I then we'll typically have, you know, the CEO or somebody come in and talk about why this problem is so critical to be solved for the business. And then what we do is if there's pain points that already exist, I'll actually have the team work with a customer. Sometimes maybe it'll be customer service calls, you know, and , and get the team involved. So maybe that's watching the customer with a timer, having some way that we can see how long does it take, what's the workaround that they currently have? So that way we can really be involved together. Once we understand the problem as a team, you know, maybe we'll do a hope , some fears exercise to kind of break out the risks. Then we'll do a quick sketch to draw up what the user journey might look like with our UX partners. And then finally, once we get to the end, you know, this will be a couple of days , we'll actually as a team break out the user stories. And so going through this entire experience together really, really helps gel the experience of what it is, why we're doing a nd, a nd, and it helps us not say, well you product owner needs to write all the user stories because that's your job. Instead it's like, this is our problem to solve and we get to do this together as a team.

Ray Arell 34:26

Very good. Thank you for giving us some insight on how you run that

Linda Cook 34:31

I want to give thoughts to this around when you are trying to create cohesiveness. No, this isn't a one and done sort of thing. Creating cohesiveness is something that takes care and feeding on a regular basis. And by that I really the care and feeding of your team, I'm looking out for their needs and making sure one that they're heard and we're practical , um, needs are met. The other part is , is that um, the more people you have on your team, the more challenging it can become to create cohesiveness isn't much just because of the multitudes of factors of personalities and cultures and communication styles and things. So it , uh , you know, it clearly is easier to create cohesiveness where they smaller team than if you have a very large team. Those of you who might struggle with , uh , justifying smaller team size, creating cohesiveness I think is one of those , uh , factors.

Ray Arell 35:27

Interesting. So let me, let me ask you a question on the , on the measurement system. Because I think sometimes when a team is not cohesive, the silent people who don't feel a part of the crowd. Um, sometimes don't speak up. Is there any method that you use to be able to help to identify the individuals who don't feel that it's a cohesive team?

Linda Cook 35:49

So, sure. I think there are two primary ways. One is that , uh , you don't start by calling them out in a group setting. It's that kind of thing where it's, it's a good time to offer to have coffee or tea with someone and just have a conversation about, you know, how they're feeling with their role in the team and are there any concerns that they have sort of thing. Give them an opportunity to open up and express that, you know, your intention is to help create a cohesive team and you've noticed that they don't tend to speak out as much as some of the other people and just learn from what they'd say about that. And then other than that in a group setting, using techniques for people to voice their opinion is always helpful and helps keep the most vocal person in the room from having all of the vote or say on an item

Ray Arell 36:41

Allowing them to give up the microphone. Mohammad you put your hand up. What , what do you have?

Guest Speaker 36:45

Just want to build and expand on what Linda said is the very insightful, I think a is besides the activity is the relationship itself within the teams that really promote cohesiveness. So as Linda said, that, you know, sometime , you know, if you offer people within a , within a group setting, the immunos speak up. But if you have a relationship, if then, you know, they gradually become more part of the nine have experienced this, that , uh, people who are very quiet and not contributing actually have lot to contribute.

Has there been much success in introducing agile and practicing Agile in K-12 classrooms?

Guest Speaker 37:27

And once the relationship develops it , they feel comfortable, they trust the team members, especially the leader, then there is a definitely more cohesion. And definitely in a smaller team setting, it's much easier than an a bigger team setting .

Ray Arell 37:45

Very good. Um, we have about , um, less than about 10 minutes left. We could , uh, go into this next question. That question is from Judy. I've actually went to the bottom of the list because sometimes it takes a little bit to get things up, u h, through the list. And I thought this one was kind of interesting. Has there been much success in introducing Agile and, and practices i n the K-12 classrooms? I'll go ahead and kick this one off. I c an say that my own daughter in the Montessori environment, she went in and actually taught other kids o f h ow to go do Kanban and personal Kanban within their environment and had a lot of great success and lots of great pictures of people, you know, the managing, you know, these young children managing their workflow. Are there others that m ight've seen some success in the K through 12?

Linda Cook 38:36

Ray, this is Linda again. So I have a colleague in Broward County in Florida who's been working with the department of education there and actually bringing formal agile training into the K through 12 classroom. I wish I had more specific um, information other than that. She knows she's reported that it's gone quite well and they're looking to grow it across other counties in Florida. So yes it is happening in some cases. I don't think people have written much about it as yet an area that would be worth pursuing.

Ray Arell 39:10

Oh, one other, one other place for people to go to for this is um , the five Saturdays project. That's an initiative with the agile Alliance. You go to the agile alliance.org you'll find that under initiatives and that particular program is targeting, how do you use agile methods in a primarily in the high school years? How do we, how do we use agile practices in order to breed success for studying and other different ways of using it within the curriculum itself. And that's pretty cool. Any other last comments on this one? As we approached the top of the hour,

Hendrik Esser 39:45

That's maybe one thing that I came across here in Europe and that is education scrum. And so there is a, is a movement that is called education scrum an educational contexts . And it came from the Netherlands. Um, there a teacher was starting to use scrum in his classroom teaching. So he was

What are you reading?

Hendrik Esser 40:04

the product owner and the students in the class are um , the teams and then the, the learning curriculum is split into backlogs and , and executed accordingly. So he has done a couple of keynotes actually at conferences, Agile conferences. So education scrum.org or something like that is the web addres s if you're interested in that.

Ray Arell 40:28

Awesome. Thank you for that. I'm going to go ahead and ask that question that we did last month and it was pretty popular. What are you reading? Are you reading right now? Because I'm going to the agile testing days conference and about a week I'm rereading agile testing different books about agile testing. How about others?

Guest Speaker 40:45

Hi Ray, this is Muhammad here. The book name is a Simpler Way . This is written by Margaret J. Wheatley. And if I t ry to, you know, summarize it, it's about t heir pieces of philosophy is t hat the l ife, the world itself is self organizing in nature. So life t ends to, you know, although t hrough messy processes or messy ways, it tends to see meaning. I t t ends to seek systems. So what it means is that we need to encourage those things and not bring constraints. So I think it's a, it's a beautiful, it's kind of a meditative short book. It is very, I think i t would be very inspirational for Agile p rofessionals.

Ray Arell 41:48

Thank you. And give me that full name one more time.

Guest Speaker 41:51

A Simpler Way by Margaret J. Wheatley and M yron Kellner Rogers. I'm not sure I'm pronouncing their names right.

Ray Arell 42:03

That's, that's okay . But thank you. Uh , another person on the comments online says that their readings Agile in scale , uh , they did not put the author name there. Others you want to contribute what book you might be reading.

Linda Cook 42:14

This started reading a book titled lab rats. How Silicon Valley made work miserable for the rest of us by Dan Lyons . Yes, as I said , up just getting started. And I can tell you that is a thought provoking and disturbing account of what the, some of the impacts we've brought on society with the advances in technology and the creation of all the millionaires that have come out of the new technology companies that have, you know, gone out of the last 20 years. And it actually does take two a account agile and some of the practices we're doing in the agile lean community pokes a lot at Lego serious play. So if you're interested, challenged about what you believe about agile and how we're for helping society , uh, it's worth a listen.

Ray Arell 43:02

One interesting thing about that book is yes, I read that as well and my knee jerk reaction was, and I posted that up on Amazon as a review was it felt to me that the , the person who authored the book was only superficially looking at agile, but I had to reread it again because, and you know, that's the Mark I guess of a decent book is that you don't have to agree with it. But yes, I do agree with you know , some of the contexts that you bring out . Any last minute books anyone wants to throw out?

Shawna Cullian 43:34

Sure. Uh , I'm reading the book. Uh, I just started reading the book EDGE — value driven

Wrap up

Shawna Cullian 43:40

digital transformation. A dear friend L inda L ou as a coauthor of it. And it's really about how difficult agile transformation is when there's things like budgets, budget planning and portfolio planning and how might we look at changing the way that businesses, u m, p lan their, t heir budgets and they themselves need to act more agile.

Ray Arell 44:04

Oh, very good. Well, we are at the top of the hour. I'd like to thank everyone for contributing this hour and for those of you who are lurking, that is okay too. But again, thank you for all the comments. If you want to visit me, I will be at the agile testing days conference in near Berlin , uh, starting next week. Um, I'm going to actually be teaching a Kanban class. They're actually a combined journaling class, which means using Kanban from a journal. So it's a, it's an experiment. Hopefully it'll go over well after that and it won't be a for a formal event, but I'll be with the supporting agile adoption team over. Where's that Hen drick again? Where are we going to be at? We're going to be in Stockholm, correct. I'll call him at Erickson . And we will enjoy this . Sweetest winter. Yes. And if you guys are in Stockholm, you know this is going to be in December, you know, we will send out, maybe you guys can meet us at a, at a local pub or something. It'd be great to have a conversation with that. Thank you.

45:07

This podcast is provided by Agile Alliance for educational and informative purposes only. To find out more information about the member supported Agile Alliance, please go to agilealliance.org to find out about more upcoming events as well as different programs that thank you. are available to help you with your agile journey.