Podcasts about agile fluency

What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike. Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together. References and resources mentioned in the show: Jim York Jim's Blog Jim's Video Library Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies GoatBot Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim. Jim York (00:12) Well, thank you, Brian. Glad to be here. Brian Milner (00:15) Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that. Jim York (00:55) Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So. Brian Milner (01:00) Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things? Jim York (01:34) Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone? Jim York (02:09) Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action. Brian Milner (02:13) Yeah. Yeah. Jim York (02:32) And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about. Brian Milner (02:55) Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team. Jim York (03:25) Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition. Brian Milner (04:18) Yeah. Jim York (04:42) But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing. Brian Milner (04:43) Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah. Jim York (06:17) Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team. Brian Milner (07:14) All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen? Jim York (07:47) Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that. Brian Milner (07:50) Yeah. Jim York (08:08) That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get... Brian Milner (10:01) Hmm. Jim York (10:17) go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and Brian Milner (11:17) Ha Yeah. Jim York (11:38) the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that Brian Milner (12:23) Mm-hmm. Jim York (12:28) If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team. Brian Milner (16:12) Hmm. Jim York (16:24) You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there. Brian Milner (16:24) Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question. Jim York (17:21) Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation. Brian Milner (17:44) Ha ha. Jim York (17:45) But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle. Brian Milner (18:54) Yeah. Jim York (18:54) And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that. Brian Milner (19:02) Ha ha ha. Jim York (19:18) container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it. Brian Milner (19:30) Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know? Jim York (21:06) Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that? Brian Milner (24:55) Hmm. Yeah. Jim York (25:24) Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob. Brian Milner (26:41) Ha ha. Jim York (26:47) in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task. Brian Milner (27:06) haha Jim York (27:16) So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight. Brian Milner (28:16) Hmm, that makes sense, yeah. Jim York (28:36) Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of... Brian Milner (29:05) Yeah. Jim York (29:09) out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a... Brian Milner (29:13) Yeah, yeah. Jim York (29:34) is a key organizational design problem. Brian Milner (29:37) Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us. Jim York (30:08) Well, I've been very pleased to join you, Brian. Thank you for the opportunity. Brian Milner (30:13) Absolutely.

In dieser Episode von Data Science Deep Dive sprechen Mira und Wolf-Gideon über das Agile Fluency Model und dessen Bedeutung im Data-Science-Kontext. Im Fokus stehen die verschiedenen Stufen der Agilität sowie die damit verbundenen Vorteile und notwendigen Investitionen. Wolf-Gideon erklärt, wie man den optimalen Agilitätsgrad für ein Team ermittelt und welche Praktiken dabei relevant sind.    ***Links*** Buch von Henning Wolf und Wolf-Gideon Bleek (2010): Agile Softwareentwicklung: Werte, Konzepte und Methoden (ISBN: 978-3-89864-701-4) it-agile Webseite https://www.it-agile.de/ Mehr Infos zu Wolf-Gideon Bleek auf der Seite von it-agile: https://www.it-agile.de/ueber-it-agile/das-team/dr-wolf-gideon-bleek/ Manifest für Agile Softwareentwicklung https://agilemanifesto.org/iso/de/manifesto.html Agile Fluency Project (EN) https://www.agilefluency.org/ Artikel: The Agile Fluency Model - A Brief Guide to Success with Agile von James Shore & Diana Larsen (EN) https://martinfowler.com/articles/agileFluency.html Buch: Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy von Jutta Eckstein & John Buck https://www.agilebossanova.com/ Feedback, Fragen oder Themenwünsche? Schreib uns gern an podcast@inwt-statistics.de

How do tech leaders learn to lead without blame? Today's guest is Diana Larsen, a truly dynamic and inspirational woman who works with global organizations designing high-performance work systems, and innovating team effectiveness – a theme that is top of mind for most businesses these days. We are chatting about the Agile Fluency model, how Diana supports business leaders in their transition to Agile methods, and her latest book ‘Lead Without Blame – Building Resilient Learning Teams.'All of Diana's books are required reading for anyone wanting to up their Agile game. Her insights into how teams work through the prism of the Agile Fluency model are fascinating, as is her view on how leadership is changing as our technological world is changing. I trust you will enjoy this episode. "It starts with the leaders. Because somebody's gotta at least make that stab in the dark to figure out 'Where are we?... Where do we think we are?... and Where are we really?' ~ Diana LarsenIn This Episode:- What is the Agile Fluency model?- Is there a 'target' team for the Agile Fluency model?- Who decides what level of fluency is for them? - What does Diana see happening when a team member is added?- A success story of a business that has employed Diana's model- How do you avoid complacency once you've implemented Agile Fluency? - How we cultivate more resilient teams - insights from Diana's new bookAnd more!Resources:- Agile Fluency - http://www.agilefluency.org/- Diana's books - https://www.amazon.com/stores/Diana-Larsen/author/B002BM7U7Q?Connect with Diana Larsen:- Website - https://www.futureworksconsulting.com/Connect with Debbie Madden:- Website - https://www.stride.build/- LinkedIn - https://www.linkedin.com/in/debbiemadden1/- LinkedIn Page - https://www.linkedin.com/company/stride-build/

“When blame is our focus rather than understanding what happened, people spend as much or more energy avoiding the blame and less time to be productive, creative, and energetic." Diana Larsen is the co-founder of Agile Fluency Project and co-author of the latest book “Lead Without Blame”. In this episode, we discussed insights from her book about building resilient learning teams by moving away from blaming culture. Diana first described the definition of blame and its characteristics, and explained the negative impacts it can bring to an organization and its culture. Diana advised that instead of a blaming culture, organizations should build a learning culture by adopting the 3 essential motivators (team purpose, autonomous teams, co-intelligence) and the 4 resilience factors (collaborative connection, embracing conflict, inclusive collaboration, minimizing power dynamics). Listen out for: Career Journey - [00:05:30] Understanding Blame - [00:08:58] Blaming Habit - [00:11:50] Leaders & Accountability - [00:18:12] 3 Essential Motivators - [00:21:21] Essential Motivator: Team Purpose - [00:27:19] Essential Motivator: Autonomous Teams - [00:31:21] Essential Motivator: Co-Intelligence - [00:35:36] Resilience Factor: Collaborative Connection - [00:39:55] Resilience Factor: Embracing Conflict - [00:42:55] Resilience Factor: Inclusive Collaboration - [00:46:40] Resilience Factor: Minimizing Power Dynamics - [00:48:48] 3 Tech Lead Wisdom - [00:52:59] _____ Diana Larsen's Bio Visionary pragmatist Diana Larsen is a cofounder, chief connector, learning leader, and principal coach, consultant, and mentor at the Agile Fluency Project. Diana coauthored the books Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; and Five Rules of Accelerated Learning. She co-originated the Agile Fluency model and coauthored the book The Agile Fluency Model: A Brief Guide to Success with Agile. For more than 20 years, she led the practice area for agile software development, leading and managing teams, and guiding agile transitions at FutureWorks Consulting. Through the Agile Fluency Project's programs, Diana shares the wisdom she's gained in over 35 years of working with leaders, teams, and organizations. To serve her communities, she delivers inspiring conference keynotes, talks, and workshops around the world. Follow Diana: Website – DianaLarsen.com Twitter – @DianaOfPortland LinkedIn – linkedin.com/in/dianalarsenagileswd Agile Fluency – AgileFluency.org _____ Our Sponsors Skills Matter is the global community and events platform for software professionals. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags. Like this episode? Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For episode show notes, visit techleadjournal.dev/episodes/118.

Dans cet épisode Nous voyons un modèle d'évolution agile et ses quatre niveaux de maîtrise.00:30 - Introduction03:04 - La focalisation06:18 - La livraison08:46 - L'optimisation10:46 - Le renforcement12:05 - L'Agile Fluency Model et les cadres de travail13:25 - ConclusionNotesLe site web officiel du Agile Fluency modelhttps://www.agilefluency.org/Le ebook en françaishttps://www.agilefluency.org/perch/resources/downloads/agile-fluency-french-version.pdfL'article de Martin Fowlerhttps://www.martinfowler.com/articles/agileFluency.htmlÀ proposJe suis Denis St-Michel, passionné d'agilité depuis 2006. Je possède les certifications PAL, PSM II, PSPO II, PSD et CSSCWB. Je rends les équipes hautement performantes et j'accrois la valeur des produits numériques.Rejoignez-moiSur LinkedIn - https://linkedin.com/in/dstmichelPar courriel - stmichel.denis@gmail.comLa page LinkedIn d'Agilibriumhttps://www.linkedin.com/company/agilibriumMusique originale"Folle", une création personnelle que vous pouvez retrouver sur mon album "Underscore", disponible sur Spotify et Apple Music.Spotify https://open.spotify.com/album/4sfnhseocnThIDf9hOFDUn?si=rVBt3wb7TmSj79bubv8W7A

Wieder ein spannendes Interview! Dr. Jürgen Hoffmann hat seit 2003 Erfahrung mit agilen Methoden und Scrum. Nach der ersten großen Scrum-Einführung in Deutschland bei der WEB.DE AG hat er in den Rollen als Coach, Trainer, Product Owner, Scrum Master und Teammitglied in unterschiedlichen Branchen und Firmengrößen gearbeitet. Diese Erfahrung aus Branchen wie Automotive, Energie, Finanzen, IT & Internet mit Soft- und Hardwareentwicklung fließen in jeden Beratungsprozess ein. Heute arbeitet er als Geschäftsführer und Managementberater bei der Emendare GmbH & Co KG, die er 2013 mitgründete. Als Certified Scrum Trainer (CST) und Certified Enterprise Coach (CEC) ist er Teil einer starken Gemeinschaft von über 300 Scrum-Trainern und Coaches der weltweiten Scrum Alliance, die in ständigem Austausch miteinander ihre Trainings und Beratungsideen kontinuierlich verbessern und um aktuelle Fragestellungen ergänzen.

Celebrating Women in Agile with Padmini Nidumolu and Diana Larsen E5 The Lurnist Show E5 with Padmini Nidumolu and Diana Larsen generated powerful conversations that ranged from topics about mentorship, coaching, Agile, women in the Agile space, and important advice for young adults. Are you struggling to find your path or don’t know where to […] The post Celebrating Women in Agile with Padmini Nidumolu and Diana Larsen E5 appeared first on Business RadioX ®.

Diana Larsen (@DianaOfPortland), Lakshmi Ramaseshan (@LakshmiRamases2), Chris Hurney (@chris_hurney) and Colleen Kirtland (@purposecreator) join Vic (@AgileCoffee) at a seasonal (and virtual) coffee shop to discuss the following topics: What new opportunities have you discovered in these pandemic times?Building Values and Principles as a Collaborative Activity with TeamsThe Doughnut Economics Journey Continues...Virtual Coaches and Distanced Coaching: What's Working for Us?Exploring Agile Fluency Please HELP support us by becoming a Patron: patreon.com/agilecoffee Books and resources mentioned in this episode: AgileFluency.orgLiftoff: Start and Sustain Successful Agile Teams (book) by Diana Larsen and Ainsley Niesalso check out Agile Retrospectives: Making Good Teams Great (book) by Diana Larsen and Esther DerbyWorks by Mariana Mazzucato:What is economic value, and who creates it? (video TED talk) The Entrepreneurial State: Debunking Public vs. Private Sector Myths (book)The Value of Everything: Making and Taking in the Global Economy (book)Lakshmi's presentation on The Power of InceptionsVic's old post about InceptionsBrian Marick and Micro-Scale Retro-Futurist Anarcho-SyndicalismThe Art of Agile Development (book) by James ShoreHuman Systems Dynamics InstituteHigh Performance Tree (Lyssa Adkins) Agile Coffee is Proud to be a part of the Agile Podcast Network Looking for MORE Scrum videos? We've got you covered. Tune in!

If all you have is a one-size-fits-all "Agile Hammer," then everything looks like a nail! Alternatively, is there a way to find a level of #Agile Fluency that best fits the business' needs? What impact does #EnsembleProgramming or #MobProgramming have in the "Delivering" zone of #AgileFluency? What is the role of #Retrospectives in #EnsembleProgramming and #AgileFluency? Chris and Austin discuss these exciting topics and more with Diana Larsen (https://twitter.com/DianaOfPortland) in this episode of the Mob Mentality Show.  Video and show notes: https://youtu.be/Lmx5Zd_SARE 

Teams need diversity and care to perform well says Diana Larsen. In this conversation Diana talks about the relevance of Agile Fluency beyond the boundaries of teams reaching into social issues like racial inequity. Diana talks about fear being the driver of American business culture and conflict avoidance the greatest threat to society. In avoiding the trust and skills to learn from conflict is the US escalating the tension to violence? In the context of a pandemic and forest fires in Oregon, Diana shares her view on how what is being on with teams applies to wider issues. Find Diana at AgileFluency.orgIntro music by Mark Romero at MarkRomeroMusic.com Host: Dawna Jones See acast.com/privacy for privacy and opt-out information.

In this Episode, Diana joined Shahin to talk about Agile Fluency and other related topics. We conversed about and around the following topics: Agile Fluency® Model (Resources, Community & Game); and it's reference Language Fluency  Group coaching compared to Individual coaching Retrospective Facilitator Gathering & Open Space Technology Continuous Learning & Continuous Improvement; Advice and Tools for newer people to Agile Coaching in the Zones & Improvement Kata We referred to and/or mentioned the following people: Rebecca Wirfs-Brock - Linda Rising - Esther Derby - Klaus Leopold (LeanOnAgile Show with Klaus) - Joshua Kerievsky - Ward Cunningham - Norman Kerth - Allison Pollard - Alistair Cockburn - Ron Jeffries - Arlo Belshee - Martin Fowler - James Shore We cited the following resources: By Diana & Co-Authors: Agile Retrospectives: Making Good Teams Great (Amazon US - Amazon CA) Liftoff: Start and Sustain Successful Agile Teams (Amazon US - Amazon CA) The Five Rules of Accelerated Learning (LeanPub) By Other Authors: Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption - Jutta Eckstein & John Buck (Amazon US - Amazon CA) Project Retrospective: A Handbook for Team Reviews - Norman Kerth (Amazon US - Amazon CA) Love is Letting Go of Fear - Gerald Jamposky (Amazon US - Amazon CA) Checklist Manifesto - Atul Gawande (Amazon US - Amazon CA) For more details please visit http://podcast.leanonagile.com. Twitter: twitter.com/LeanOnAgileShow  LinkedIn: linkedin.com/company/lean-on-agile

This month on the Cucumber Podcast we welcome Diana Larsen a world-renown author, speaker and co-founder of The Agile Fluency Model. Show notes: - CukenFest Remote - June 3rd-4th -https://cukenfest.cucumber.io/ - Agile Fluency - https://www.agilefluency.org/ - Upcoming events - https://www.agilefluency.org/workshops.php - Virtual Open North America - https://www.eventbrite.com/e/virtual-open-north-america-tickets-101659959676 - Books - https://leanpub.com/u/dianalarsenauthor

Agile Fluency: https://www.agilefluency.org FREE Agile Fluency book: Read the eBook Workshops and events; https://www.agilefluency.org/workshops.php

Agile Fluency: https://www.agilefluency.org FREE Agile Fluency book: Read the eBook Workshops and events; https://www.agilefluency.org/workshops.php

In this podcast recorded at Agile 2019, Shane Hastie, Lead Editor for Culture & Methods, spoke to Diana Larsen about the origins of what became agile development, where business agility is header and the agile fluency project . Why listen to this podcast: • There is a deep history of business improvement initiatives that predates the agile manifesto • It was a part of a cultural movement that was moving more toward more humane workplaces that could deliver more value • When you give people a good environment and good support to do their work, you get better work and better products • The ideas of business agility predate the work in agile development – engaging support structures in organisations to enable change • You can't change one part of a system without it having effects on other parts of the system • The Agile Fluency Model is a tool to help teams diagnose themselves and to expose the system to leadership More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3acIJwf You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3acIJwf

Dr. Dave: So I sent you a few questions today. Let’s just begin. Let’s start talking about, tell us about your role in Agile Fluency, and the Agile Fluency model. What is, yeah.   Diana: Well, so I’m a co-creator, co-developer of the model. James Shore and I a number of years ago were noticing… The post EAFH23: Delivery Value with Diana Larsen, Agile Fluency Model appeared first on Leaders share how-to practices - KnolShare with Dr. Dave Podcast on GrokShare.com.

In this episode, Ahmed Avais discusses the Agile Fluency Model. He shares what it is, how to use it, and where to go to get more information about it. Here are some of the resources Ahmed recommends https://www.agilefluency.org/ and https://martinfowler.com/articles/agileFluency.html Connect with Ahmed on LinkedIn https://www.linkedin.com/in/ahmedavais --- Support this podcast: https://anchor.fm/tom-henricksen/support

Episode 37 of the Modern Agile Show features an interview with Diana Larsen, co-founder and chief connector of the Agile Fluency project, co-author of the books, Agile Retrospectives, Liftoff and Five Rules for Accelerated Learning. Diana is an expert in helping people learn. She and Joshua discuss the story of the learning that resulted from a large team's end-of-project retrospective, including how HR's 42-page individual performance review had choked productivity in the team. Diana discusses the vital practice of Chartering, she explains her Five Rules for Accelerated Learning and discusses how important learning is to being agile. Diana tells the story of how the Agile Fluency game helped a leadership team figure out how they needed to collaborate and understand each other better. Diana and Joshua discuss how to get to your edge in learning instead of staying in your comfort zone. Check out AgileFluency.org for more information and Diana and her work.

Pour voir la version vidéo : https://youtu.be/jdZAGIouy_4 ----- Quand peut-on dire que la transformation agile est complète ? Agile Fluency propose un modèle où la notion de transformation n'est pas tant par étapes mais plutôt par niveaux. Dit autrement, on peut choisir de n'être "qu'un peu" agile. Car ça coûte cher d'être vraiment agile !!! Découvrez-en plus dans la description ci-dessous

In this podcast recorded at the Agile 2018 conference Shane Hastie, Lead Editor for Culture & Methods, spoke to Diana Larsen about the evolution of the Agile Fluency model, the rate of adoption of new ideas in organisations, organisation design and being an ally. Why listen to this podcast: • The ideas around agile fluency have evolved through feedback and use in the field • New ideas take time to be adopted in organisations and agile is far from prevalent • Agile ways of working will become “the way we do things” but it will take time • There is a diagnostic instrument which allows teams to undertake self-reflection and explore areas they want to improve • The organisation design community have a lot of knowledge about things that the agile community can learn from • Diversity and inclusiveness are still issues in the agile and broader IT community, but things are improving • The single most powerful tool to combat racism/sexism and help diversity and inclusion grow is the action of bystanders More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2OYTIOM You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2OYTIOM

Panel: Charles Max Wood Guest: James Shore This week on My Angular Story, Charles speaks with James Shore who is the author of the book, “The Art of Agile.” James is a thought leader in the Agile software development community. He combines deep technical expertise with whole-system thinking to help development teams worldwide achieve great things! Check out his complete biography here! Chuck and James talk about Agile development, James’ background, and future projects! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:48 – Chuck: Welcome! James was on a past episode, which was show 205! Give us an introduction, please! 1:05 – James: I have been involved with the software industry since 1991. I have written a book and it’s fairly evergreen. 1:30 – Chuck: Yeah, I remember that’s when the Agile development was getting really, really hot! 2:09 – James: Yeah in the early 2000s there was this energy to do software really well, and it seems like it’s turned into this bureaucracy. I find that to be depressing a tiny bit. 2:50 – Chuck: Yeah, I agree. 3:01 – James: Going back to a perspective where excellence is no longer the priority; excellence in your craft. 3:31 – Chuck. 3:34 – James: Yeah that was Bob Marten.  James talks about the Agile movement. 4:22 – Chuck: This show is a walk back throughout your story. Let’s talk about HOW you got into this stuff. 4:40 – James talks about his background. 4:58 – Chuck talks about his Grandpa and his experience with technology when he was young. 5:10 – James: ...it had a whopping 2K of memory! That’s really how I got involved into programming. Later on I got a Trash 80 then an Apple 2, so I had programming in through my blood. 6:01 – Chuck. 6:08 – James talks about switching between computer and antenna, and his black and white T.V. He also talks about the electrical engineering program at the university. 7:16 – Chuck: I studied ad received my computer science degree. 7:28 – James. 7:34 – Chuck: You have been in the industry since 2001 and you are a bit older than me. 7:50 – James: My first job was in 1994. Then I wrote some things with Fido Net. Fido Net was this early online form thing. Sort of like Used Net / Used Groups (online bulletin web forms) via the telephone dial-up. They were hobbyists running this out from their home. It was basically chat forms. Once you have some experience (doesn’t matter your degree) – it’s...have you done this before? 9:30 – Chuck: This is RIGHT in-line with what I say in my eBook that I am developing now. 10:00 – James: I didn’t even post that I was looking for a job, but I got very lucky. 10:15 – Chuck: What is your journey look like and how did you get into Agile development? 10:30 – James talks about his Kickstarter, knowledge in JavaScript, programming experience, and more here – check it out! 13:16 – Chuck: How did you get to Agile development? 13:31 – James: I was programming throughout my teens. I was working on a really complicated project. I still play Dungeons and Dragons (D&D). It was the most complicated program that I built at that point. I had it in my head and then I didn’t understand it anymore. The program collapsed. To me that was really transformative b/c it’s not writing the algorithms but how it all works together. Then this taught me how to communicate the design to the other members on the team to make it work. 15:50 – James: Have you heard of Rational Rose? You don’t hear about it anymore b/c it was a complete flop. 17:20 – Chuck: Wow! 17:33 – James: It was actually detrimental to get it done. It really was a crisis of faith. I ran into this book: Object Modeling in Color by Peter Coad. Extreme Programming is mentioned, too, by James’ coworker! 21:10 – Chuck: It’s so interesting to me. We focus so much on the technological side, we forget to talk about the people, and the other sides to this. It’s easy to overlook this other stuff. 21:47 – James: There is so much silver bullet thinking within this industry. The original communication from person-to-person is so crucial. It’s so important to software development. Ultimately, the computer doesn’t care, but the collaboration is the real trick and the real challenge. 23:10 – Chuck talks about his brother and his computer science courses experience. 24:27 – James: It could be that 1 team could solve a problem but nowadays it’s working with multiple teams. People want to water things down to help facilitate – but don’t do that. There is a huge large scale Agile that is large interdependent teams. 25:19 – Chuck: MFCEO is a podcast that I am listening to now. He says that nobody wants to sit down and dictate what each member will be responsible for. Chuck reads a quote from an episode from MFCEO – check it out! 26:54 – James: It’s something that people have lost track of. I still program daily even though I do this Agile stuff as well. I have been programming for 25 years and Extreme Programming was the most effective thing for me throughout my career. James: I think XP is the time (now) to have a comeback! 29:41 – Chuck: That was my experience, too. We pushed one team to go to Agile, and then we went to our boss. Chuck: We’d sit down every two weeks and have an Agile-Perspective (what is working and what isn’t working). We are talking about HOW we are writing the software, and that is really what we are after. 30:54 – James: You are building the TEAM that builds the project. Of course, you need to have consistencies across the team, and every team is different b/c every member has different personalities. Mod Programming is we are going to work as a whole group around a screen. Personally, that is not my style but I would TRY it. If it worked for that team then I would do it. 32:00 – Chuck: That is the beauty of it. With this set of programmers x, y, and z may or may not work, and that is O.K. 32:25 – James: I heard about Extreme Programming and I thought it was nuts!! 32:40 – Chuck. 32:44 – James: The more I tried it, and the more it worked. Try Extreme Programming b/c it’s totally a different experience. It’s my book that I wrote 10 years ago but it still is applicable today. Try it for a few months (3 months) or so, b/c it takes time to figure out the different terms and such. Go try out a bunch of new different things, but figuring out HOW to make it work for me. 34:05 – Chuck: Yeah, you need data. Look at the data. Go experiment. 34:47 – James: Try it for real. Check out this essay: “We tried baseball, and it didn’t work.” James: Many things only work in context!  What we do is we change the context in Agile. 35:58 – Chuck: What are you working on now? 36:00 – James: I am actually working on AgileFluency.org. It’s a set of tools for coaches and leaders to CHANGE their context. How can you find those constraints and invest on changing those. 36:31 – Chuck: Where do they go to find you? 36:40 – James: My website - it’s the ugliest website, but it’s been working since 2003. 36:54 – Picks! 37:05 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Slack Zone.js GitHub – Zone.js Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Timex Sinclair FidoNet VHDL Book: Java Modeling Color with UML Pivotal Labs Book: The ART OF AGILE DEVELOPMENT BY JAMES SHORE James Shore’s Website Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Chuck Podcast: MFCEO James Package Management Tool: Nix.org

Panel: Charles Max Wood Guest: James Shore This week on My Angular Story, Charles speaks with James Shore who is the author of the book, “The Art of Agile.” James is a thought leader in the Agile software development community. He combines deep technical expertise with whole-system thinking to help development teams worldwide achieve great things! Check out his complete biography here! Chuck and James talk about Agile development, James’ background, and future projects! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:48 – Chuck: Welcome! James was on a past episode, which was show 205! Give us an introduction, please! 1:05 – James: I have been involved with the software industry since 1991. I have written a book and it’s fairly evergreen. 1:30 – Chuck: Yeah, I remember that’s when the Agile development was getting really, really hot! 2:09 – James: Yeah in the early 2000s there was this energy to do software really well, and it seems like it’s turned into this bureaucracy. I find that to be depressing a tiny bit. 2:50 – Chuck: Yeah, I agree. 3:01 – James: Going back to a perspective where excellence is no longer the priority; excellence in your craft. 3:31 – Chuck. 3:34 – James: Yeah that was Bob Marten.  James talks about the Agile movement. 4:22 – Chuck: This show is a walk back throughout your story. Let’s talk about HOW you got into this stuff. 4:40 – James talks about his background. 4:58 – Chuck talks about his Grandpa and his experience with technology when he was young. 5:10 – James: ...it had a whopping 2K of memory! That’s really how I got involved into programming. Later on I got a Trash 80 then an Apple 2, so I had programming in through my blood. 6:01 – Chuck. 6:08 – James talks about switching between computer and antenna, and his black and white T.V. He also talks about the electrical engineering program at the university. 7:16 – Chuck: I studied ad received my computer science degree. 7:28 – James. 7:34 – Chuck: You have been in the industry since 2001 and you are a bit older than me. 7:50 – James: My first job was in 1994. Then I wrote some things with Fido Net. Fido Net was this early online form thing. Sort of like Used Net / Used Groups (online bulletin web forms) via the telephone dial-up. They were hobbyists running this out from their home. It was basically chat forms. Once you have some experience (doesn’t matter your degree) – it’s...have you done this before? 9:30 – Chuck: This is RIGHT in-line with what I say in my eBook that I am developing now. 10:00 – James: I didn’t even post that I was looking for a job, but I got very lucky. 10:15 – Chuck: What is your journey look like and how did you get into Agile development? 10:30 – James talks about his Kickstarter, knowledge in JavaScript, programming experience, and more here – check it out! 13:16 – Chuck: How did you get to Agile development? 13:31 – James: I was programming throughout my teens. I was working on a really complicated project. I still play Dungeons and Dragons (D&D). It was the most complicated program that I built at that point. I had it in my head and then I didn’t understand it anymore. The program collapsed. To me that was really transformative b/c it’s not writing the algorithms but how it all works together. Then this taught me how to communicate the design to the other members on the team to make it work. 15:50 – James: Have you heard of Rational Rose? You don’t hear about it anymore b/c it was a complete flop. 17:20 – Chuck: Wow! 17:33 – James: It was actually detrimental to get it done. It really was a crisis of faith. I ran into this book: Object Modeling in Color by Peter Coad. Extreme Programming is mentioned, too, by James’ coworker! 21:10 – Chuck: It’s so interesting to me. We focus so much on the technological side, we forget to talk about the people, and the other sides to this. It’s easy to overlook this other stuff. 21:47 – James: There is so much silver bullet thinking within this industry. The original communication from person-to-person is so crucial. It’s so important to software development. Ultimately, the computer doesn’t care, but the collaboration is the real trick and the real challenge. 23:10 – Chuck talks about his brother and his computer science courses experience. 24:27 – James: It could be that 1 team could solve a problem but nowadays it’s working with multiple teams. People want to water things down to help facilitate – but don’t do that. There is a huge large scale Agile that is large interdependent teams. 25:19 – Chuck: MFCEO is a podcast that I am listening to now. He says that nobody wants to sit down and dictate what each member will be responsible for. Chuck reads a quote from an episode from MFCEO – check it out! 26:54 – James: It’s something that people have lost track of. I still program daily even though I do this Agile stuff as well. I have been programming for 25 years and Extreme Programming was the most effective thing for me throughout my career. James: I think XP is the time (now) to have a comeback! 29:41 – Chuck: That was my experience, too. We pushed one team to go to Agile, and then we went to our boss. Chuck: We’d sit down every two weeks and have an Agile-Perspective (what is working and what isn’t working). We are talking about HOW we are writing the software, and that is really what we are after. 30:54 – James: You are building the TEAM that builds the project. Of course, you need to have consistencies across the team, and every team is different b/c every member has different personalities. Mod Programming is we are going to work as a whole group around a screen. Personally, that is not my style but I would TRY it. If it worked for that team then I would do it. 32:00 – Chuck: That is the beauty of it. With this set of programmers x, y, and z may or may not work, and that is O.K. 32:25 – James: I heard about Extreme Programming and I thought it was nuts!! 32:40 – Chuck. 32:44 – James: The more I tried it, and the more it worked. Try Extreme Programming b/c it’s totally a different experience. It’s my book that I wrote 10 years ago but it still is applicable today. Try it for a few months (3 months) or so, b/c it takes time to figure out the different terms and such. Go try out a bunch of new different things, but figuring out HOW to make it work for me. 34:05 – Chuck: Yeah, you need data. Look at the data. Go experiment. 34:47 – James: Try it for real. Check out this essay: “We tried baseball, and it didn’t work.” James: Many things only work in context!  What we do is we change the context in Agile. 35:58 – Chuck: What are you working on now? 36:00 – James: I am actually working on AgileFluency.org. It’s a set of tools for coaches and leaders to CHANGE their context. How can you find those constraints and invest on changing those. 36:31 – Chuck: Where do they go to find you? 36:40 – James: My website - it’s the ugliest website, but it’s been working since 2003. 36:54 – Picks! 37:05 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Slack Zone.js GitHub – Zone.js Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Timex Sinclair FidoNet VHDL Book: Java Modeling Color with UML Pivotal Labs Book: The ART OF AGILE DEVELOPMENT BY JAMES SHORE James Shore’s Website Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Chuck Podcast: MFCEO James Package Management Tool: Nix.org

Panel: Charles Max Wood Guest: James Shore This week on My Angular Story, Charles speaks with James Shore who is the author of the book, “The Art of Agile.” James is a thought leader in the Agile software development community. He combines deep technical expertise with whole-system thinking to help development teams worldwide achieve great things! Check out his complete biography here! Chuck and James talk about Agile development, James’ background, and future projects! In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 0:48 – Chuck: Welcome! James was on a past episode, which was show 205! Give us an introduction, please! 1:05 – James: I have been involved with the software industry since 1991. I have written a book and it’s fairly evergreen. 1:30 – Chuck: Yeah, I remember that’s when the Agile development was getting really, really hot! 2:09 – James: Yeah in the early 2000s there was this energy to do software really well, and it seems like it’s turned into this bureaucracy. I find that to be depressing a tiny bit. 2:50 – Chuck: Yeah, I agree. 3:01 – James: Going back to a perspective where excellence is no longer the priority; excellence in your craft. 3:31 – Chuck. 3:34 – James: Yeah that was Bob Marten.  James talks about the Agile movement. 4:22 – Chuck: This show is a walk back throughout your story. Let’s talk about HOW you got into this stuff. 4:40 – James talks about his background. 4:58 – Chuck talks about his Grandpa and his experience with technology when he was young. 5:10 – James: ...it had a whopping 2K of memory! That’s really how I got involved into programming. Later on I got a Trash 80 then an Apple 2, so I had programming in through my blood. 6:01 – Chuck. 6:08 – James talks about switching between computer and antenna, and his black and white T.V. He also talks about the electrical engineering program at the university. 7:16 – Chuck: I studied ad received my computer science degree. 7:28 – James. 7:34 – Chuck: You have been in the industry since 2001 and you are a bit older than me. 7:50 – James: My first job was in 1994. Then I wrote some things with Fido Net. Fido Net was this early online form thing. Sort of like Used Net / Used Groups (online bulletin web forms) via the telephone dial-up. They were hobbyists running this out from their home. It was basically chat forms. Once you have some experience (doesn’t matter your degree) – it’s...have you done this before? 9:30 – Chuck: This is RIGHT in-line with what I say in my eBook that I am developing now. 10:00 – James: I didn’t even post that I was looking for a job, but I got very lucky. 10:15 – Chuck: What is your journey look like and how did you get into Agile development? 10:30 – James talks about his Kickstarter, knowledge in JavaScript, programming experience, and more here – check it out! 13:16 – Chuck: How did you get to Agile development? 13:31 – James: I was programming throughout my teens. I was working on a really complicated project. I still play Dungeons and Dragons (D&D). It was the most complicated program that I built at that point. I had it in my head and then I didn’t understand it anymore. The program collapsed. To me that was really transformative b/c it’s not writing the algorithms but how it all works together. Then this taught me how to communicate the design to the other members on the team to make it work. 15:50 – James: Have you heard of Rational Rose? You don’t hear about it anymore b/c it was a complete flop. 17:20 – Chuck: Wow! 17:33 – James: It was actually detrimental to get it done. It really was a crisis of faith. I ran into this book: Object Modeling in Color by Peter Coad. Extreme Programming is mentioned, too, by James’ coworker! 21:10 – Chuck: It’s so interesting to me. We focus so much on the technological side, we forget to talk about the people, and the other sides to this. It’s easy to overlook this other stuff. 21:47 – James: There is so much silver bullet thinking within this industry. The original communication from person-to-person is so crucial. It’s so important to software development. Ultimately, the computer doesn’t care, but the collaboration is the real trick and the real challenge. 23:10 – Chuck talks about his brother and his computer science courses experience. 24:27 – James: It could be that 1 team could solve a problem but nowadays it’s working with multiple teams. People want to water things down to help facilitate – but don’t do that. There is a huge large scale Agile that is large interdependent teams. 25:19 – Chuck: MFCEO is a podcast that I am listening to now. He says that nobody wants to sit down and dictate what each member will be responsible for. Chuck reads a quote from an episode from MFCEO – check it out! 26:54 – James: It’s something that people have lost track of. I still program daily even though I do this Agile stuff as well. I have been programming for 25 years and Extreme Programming was the most effective thing for me throughout my career. James: I think XP is the time (now) to have a comeback! 29:41 – Chuck: That was my experience, too. We pushed one team to go to Agile, and then we went to our boss. Chuck: We’d sit down every two weeks and have an Agile-Perspective (what is working and what isn’t working). We are talking about HOW we are writing the software, and that is really what we are after. 30:54 – James: You are building the TEAM that builds the project. Of course, you need to have consistencies across the team, and every team is different b/c every member has different personalities. Mod Programming is we are going to work as a whole group around a screen. Personally, that is not my style but I would TRY it. If it worked for that team then I would do it. 32:00 – Chuck: That is the beauty of it. With this set of programmers x, y, and z may or may not work, and that is O.K. 32:25 – James: I heard about Extreme Programming and I thought it was nuts!! 32:40 – Chuck. 32:44 – James: The more I tried it, and the more it worked. Try Extreme Programming b/c it’s totally a different experience. It’s my book that I wrote 10 years ago but it still is applicable today. Try it for a few months (3 months) or so, b/c it takes time to figure out the different terms and such. Go try out a bunch of new different things, but figuring out HOW to make it work for me. 34:05 – Chuck: Yeah, you need data. Look at the data. Go experiment. 34:47 – James: Try it for real. Check out this essay: “We tried baseball, and it didn’t work.” James: Many things only work in context!  What we do is we change the context in Agile. 35:58 – Chuck: What are you working on now? 36:00 – James: I am actually working on AgileFluency.org. It’s a set of tools for coaches and leaders to CHANGE their context. How can you find those constraints and invest on changing those. 36:31 – Chuck: Where do they go to find you? 36:40 – James: My website - it’s the ugliest website, but it’s been working since 2003. 36:54 – Picks! 37:05 – Fresh Books! END – CacheFly Links: jQuery Angular JavaScript Vue React Slack Zone.js GitHub – Zone.js Chuck’s Twitter Chuck’s E-mail: chuck@devchat.tv Timex Sinclair FidoNet VHDL Book: Java Modeling Color with UML Pivotal Labs Book: The ART OF AGILE DEVELOPMENT BY JAMES SHORE James Shore’s Website Sponsors: Get A Coder Job Fresh Books Cache Fly Picks: Chuck Podcast: MFCEO James Package Management Tool: Nix.org

Today, Phil chats with James Shore. James teaches, writes and consults on Agile development processes. He is a recipient of the Agile Alliance’s Gordon Pask Award for Contributions to Agile Practice, co-creator of the Agile Fluency Model, and co-author of “The Art of Agile Development”. James has also been named as one of “the most influential people in Agile” by InfoQ. KEY TAKEAWAYS: ­­­(0.31) – Phil started by asking James to tell everyone a bit more about himself. James explained that he started his I.T. career as a programmer. In 1999, he was introduced to what was known as Extreme Programming (XP), which is the most prominent of the Agile software development methodologies. At first, James was not convinced, but when he tried it, he was hooked. So much so, that he decided he could not work any other way. At the time, he could not find anybody else working the XP way, so he decided to teach the method himself. That is how he became an Agile consultant. (2.45) – Phil and James discuss the fact that Agile is not new. It has been around for just over 20 years now and the movement is really gathering pace. However, James does point out that “a lot of what people call Agile is not really Agile.” The quality of implementation varies quite a bit. (3.26) – Phil asks James to share a unique IT career tip. James responded by saying you need to “make a point of understanding the business impact of what you're doing." He went on to remind everyone that a typical software team costs circa $1 million to run. A cost that has to be covered by the value the team adds to the business. He highlighted the fact that a 5% improvement in a team’s performance is worth at least $50,000. When you ask for something to improve efficiency remember to make the business case and explain the cost savings clearly. (4.44) – Phil asked James to share a business experience from which he learned something important. For James that happened 20 years ago. At the time he was working for the firm that provided the robots used by Intel to move silicone around on its chip production line. James was part of a team who worked on a distributed system that had multiple services running on different computers. Each service worked in its own environment, but when they hooked it all up the problems began. At the time, the waterfall or phase gate development method was the norm for software development. It was supposed to be a flawless development process. But, in reality, it was not. That project and several others James worked on that followed the standard “waterfall” method were disasters. At that point, James realized the futility of a development method that tried to predict everything in advance, lock things down and come up with the entire design. He also saw how dangerous it was to wait to the very end to validate the work and make the biggest decisions. It was then he understood the flaws of the way development was managed 20 years ago. It was this experience that helped him to recognize the true value of Agile development methods when he was introduced to them. (8.51) – Phil asks what James considered to be his best career moment. James explained that about two years ago he consulted for a start-up that had just gone public and had growing pains. They had 40 teams, so keeping tabs on what they were all doing was impossible. Plus, there was a lot of interdependency between teams, so everything took forever. James discovered that waiting around for another team to do something was causing 95% of the delays. On one project, during a 3-month period, only 3 or 4 days of real work could be done. This stop-start, multitasking way of working, was terrible for focus too. James minimized the teams and got the firm to start by working on the smallest projects that added value, first. These changes minimized the amount of inter-team dependency and got everyone working together and actually delivering working projects fast. He also encouraged teams to solve more of their problems internally. The net result of his changes was that they reduced the delays from 95% to 0%. Most MMFs were completed in just a week or two. The company thrived and grew very quickly. (12.49) – Phil wants to know what excites James about the future for the IT industry. James explains that the fact the industry is so young is exciting because it means change is possible and can happen quickly. Agile is the exact opposite of the Waterfall way of working, yet in less than 20 years people have adopted this new way of working. That is a 180-degree change. In an older industry that just would not happen. In I.T you can suggest new ideas and people will actually be willing to try them.  (15.05) – What is the best career advice you have been given? James responded with three words “be well-rounded”. (15.11) Phil asks if you were to begin your I.T. career again, right now, what would you do? James says that he would focus on networking and finding a mentor. (15.20) – Phil asks James what he is focusing on, right now. James says he is really focused on his business The Agile Fluency project. (15.29) – What is your most important non-technical skill, the one that has helped you the most in your career, so far? James says my “curiosity, flexibility, and a desire and willingness to experiment.” (15.40) – Phil asks James to share a final piece of career advice. James says that if you are working somewhere that does not enable you to do your best work you should try to change that from within. If you discover that is not possible, you need to move on and work for another organization. BEST MOMENTS:  (3.13) - James - “A lot of what people call Agile is not really Agile.” "The actual implementation tends to vary in quality by quite a bit." (3.25) - James - "One of the most valuable things that you can do for your career is to make a point of understanding the business impact of what you're doing." (11.50) - James - "We went from 95% delay for most teams we got it down to zero delays, no delay at all." (12.12) - James - "It's a big cultural mindset change. And making that sort of change requires making sure that everybody's involved and understands how they benefit from this change." (13.15) - James - "Every single company of any size whatsoever needs software. Anybody that's larger than tiny needs custom software." (13.25) - James - "It's a young industry. It's open to new ideas and ways of working." (13.37) - James - "Best practices, at the time, was waterfall, which is basically the exact opposite of agile and now 20 years later, agile has taken over the world." (16.08) - James - "Don't put up with mediocrity. Don't put up with a lousy work environment, just because it's got a great salary."   CONTACT JAMES SHORE:   Linkedin – https://www.linkedin.com/in/james-shore-7475b6/ Twitter – https://twitter.com/jamesshore@jamesshore Website – www.agilefluency.org Personal Website – www.jamesshore.com  

Panel: Charles Max Wood Alyssa Nicholl Joe Eames Special Guests: James Shore In this episode, the Adventures in Angular panel talks about Agile Fluency with James Shore. James is one of Charles’ favorite people to talk to about Agile development because he is one of the people who really understands how people work, instead of the methodology proliferation that is more common. They talk about how Agile got started, the Agile Fluency Project, and how Agile has changed over the years. They also touch on TDD, the things people can do to solve the problems with Agile misconceptions, and more! Show Topics: 1:10 – James has been on the shows previously on Ruby Rogues Episode 275 and My Ruby Story Episode 48. 2:00 – He does a lot of work with agile, but actually got started with something called Extreme Programming. 3:14 – When Agile started, it was a reaction to the management belief that the right way to develop software was to hire armies of replaceable programmers and a few architects to design something that was then sent off for these programmers to work. 4:34 – Agile is turning into the “everything” thing. It is being used in many different spaces and leaving developers behind in the process. This goes along with “the law of raspberry jam.” 6:55 – The agile manifesto states that they value “Individuals and interactions over processes and tools.” 7:28 – The Agile Fluency Project is focused on software teams and they created the Agile Fluency Model, which is a way to describe how teams tend to learn Agile over time. They want people to be able to see what all they can really get out of Agile through this project. 10:05 – Alyssa is more confused on the subject of Agile development and is interested more in what people lost by not using Agile anymore. 11:45 – Agile changed from a grassroots movement driven by developers to a management structure that programmers ignore unless it affects their day-to-day. 14:18 – Test driven development is a way of writing your code so that you have confidence to change it in the future not a way you can get unit test code coverage. 17:36 – Joe defines TDD as a way to help him design better code and he finds value in using TDD and then once the code is done, throwing out the test and still find value in it. 19:50 – TDD creates better code by forcing you to think about the client who will be using it and it forces you writing code that is inherently testable, and therefore, better code. 22:22 – The values of Agile development have not been communicated to the programmers who are forced to use it, which accounts for the push back against it. 24:40 – The issue across the board is when people take and idea and think they can read a headline and understand it fully. 28:17 – The way to combat this problem is to dig into some of the things that was happening 15-20 years ago and you can look into DevOps. You can also look into the Agile Fluency Project and the Agile Fluency Model. 31:24 – To get started with talking about how you should do Agile from the trenches, you can look into the books Fearless Change by Mary Lynn Manns and More Fearless Change by Mary Lynn Manns to help you to learn how to make change within your organization. 35:18 – Planting seeds allows you to make change within your organization and make a difference in a small way. 36:10 – The easiest way to remove some of these obstacles is to get together with your team and get them to agree to a trial period. There are more ways as well to get over obstacles. 43:07 – The reason he became an Agile developer is because after his first job working with it, he never wanted to work any way else. So, he decided to start teaching Agile in order to keep working with it in his career. Links: Ruby Rogues Episode 275 My Ruby Story Episode 48 Extreme Programming Agile Fluency Project Agile Fluency Model Smalltalk Best Practice Patterns by Kent Beck Refactoring by Martin Fowler UML Distilled by Martin Fowler Fearless Change by Mary Lynn Manns More Fearless Change by Mary Lynn Manns The Art of Agile Development by James Shore jamesshore.com @jamesshore James’ GitHub Sponsors Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Get a Coder Job Course DevChat Merchandise Code Badges DevChat.tv YouTube Joe Framework Summit Pluralsight James Deliver:Agile Testing Without Mocks: A Pattern Language Jake (build tool) The High-Performance Coach The Expanse by James S. A. Corey

Panel: Charles Max Wood Alyssa Nicholl Joe Eames Special Guests: James Shore In this episode, the Adventures in Angular panel talks about Agile Fluency with James Shore. James is one of Charles’ favorite people to talk to about Agile development because he is one of the people who really understands how people work, instead of the methodology proliferation that is more common. They talk about how Agile got started, the Agile Fluency Project, and how Agile has changed over the years. They also touch on TDD, the things people can do to solve the problems with Agile misconceptions, and more! Show Topics: 1:10 – James has been on the shows previously on Ruby Rogues Episode 275 and My Ruby Story Episode 48. 2:00 – He does a lot of work with agile, but actually got started with something called Extreme Programming. 3:14 – When Agile started, it was a reaction to the management belief that the right way to develop software was to hire armies of replaceable programmers and a few architects to design something that was then sent off for these programmers to work. 4:34 – Agile is turning into the “everything” thing. It is being used in many different spaces and leaving developers behind in the process. This goes along with “the law of raspberry jam.” 6:55 – The agile manifesto states that they value “Individuals and interactions over processes and tools.” 7:28 – The Agile Fluency Project is focused on software teams and they created the Agile Fluency Model, which is a way to describe how teams tend to learn Agile over time. They want people to be able to see what all they can really get out of Agile through this project. 10:05 – Alyssa is more confused on the subject of Agile development and is interested more in what people lost by not using Agile anymore. 11:45 – Agile changed from a grassroots movement driven by developers to a management structure that programmers ignore unless it affects their day-to-day. 14:18 – Test driven development is a way of writing your code so that you have confidence to change it in the future not a way you can get unit test code coverage. 17:36 – Joe defines TDD as a way to help him design better code and he finds value in using TDD and then once the code is done, throwing out the test and still find value in it. 19:50 – TDD creates better code by forcing you to think about the client who will be using it and it forces you writing code that is inherently testable, and therefore, better code. 22:22 – The values of Agile development have not been communicated to the programmers who are forced to use it, which accounts for the push back against it. 24:40 – The issue across the board is when people take and idea and think they can read a headline and understand it fully. 28:17 – The way to combat this problem is to dig into some of the things that was happening 15-20 years ago and you can look into DevOps. You can also look into the Agile Fluency Project and the Agile Fluency Model. 31:24 – To get started with talking about how you should do Agile from the trenches, you can look into the books Fearless Change by Mary Lynn Manns and More Fearless Change by Mary Lynn Manns to help you to learn how to make change within your organization. 35:18 – Planting seeds allows you to make change within your organization and make a difference in a small way. 36:10 – The easiest way to remove some of these obstacles is to get together with your team and get them to agree to a trial period. There are more ways as well to get over obstacles. 43:07 – The reason he became an Agile developer is because after his first job working with it, he never wanted to work any way else. So, he decided to start teaching Agile in order to keep working with it in his career. Links: Ruby Rogues Episode 275 My Ruby Story Episode 48 Extreme Programming Agile Fluency Project Agile Fluency Model Smalltalk Best Practice Patterns by Kent Beck Refactoring by Martin Fowler UML Distilled by Martin Fowler Fearless Change by Mary Lynn Manns More Fearless Change by Mary Lynn Manns The Art of Agile Development by James Shore jamesshore.com @jamesshore James’ GitHub Sponsors Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Get a Coder Job Course DevChat Merchandise Code Badges DevChat.tv YouTube Joe Framework Summit Pluralsight James Deliver:Agile Testing Without Mocks: A Pattern Language Jake (build tool) The High-Performance Coach The Expanse by James S. A. Corey

Panel: Charles Max Wood Alyssa Nicholl Joe Eames Special Guests: James Shore In this episode, the Adventures in Angular panel talks about Agile Fluency with James Shore. James is one of Charles’ favorite people to talk to about Agile development because he is one of the people who really understands how people work, instead of the methodology proliferation that is more common. They talk about how Agile got started, the Agile Fluency Project, and how Agile has changed over the years. They also touch on TDD, the things people can do to solve the problems with Agile misconceptions, and more! Show Topics: 1:10 – James has been on the shows previously on Ruby Rogues Episode 275 and My Ruby Story Episode 48. 2:00 – He does a lot of work with agile, but actually got started with something called Extreme Programming. 3:14 – When Agile started, it was a reaction to the management belief that the right way to develop software was to hire armies of replaceable programmers and a few architects to design something that was then sent off for these programmers to work. 4:34 – Agile is turning into the “everything” thing. It is being used in many different spaces and leaving developers behind in the process. This goes along with “the law of raspberry jam.” 6:55 – The agile manifesto states that they value “Individuals and interactions over processes and tools.” 7:28 – The Agile Fluency Project is focused on software teams and they created the Agile Fluency Model, which is a way to describe how teams tend to learn Agile over time. They want people to be able to see what all they can really get out of Agile through this project. 10:05 – Alyssa is more confused on the subject of Agile development and is interested more in what people lost by not using Agile anymore. 11:45 – Agile changed from a grassroots movement driven by developers to a management structure that programmers ignore unless it affects their day-to-day. 14:18 – Test driven development is a way of writing your code so that you have confidence to change it in the future not a way you can get unit test code coverage. 17:36 – Joe defines TDD as a way to help him design better code and he finds value in using TDD and then once the code is done, throwing out the test and still find value in it. 19:50 – TDD creates better code by forcing you to think about the client who will be using it and it forces you writing code that is inherently testable, and therefore, better code. 22:22 – The values of Agile development have not been communicated to the programmers who are forced to use it, which accounts for the push back against it. 24:40 – The issue across the board is when people take and idea and think they can read a headline and understand it fully. 28:17 – The way to combat this problem is to dig into some of the things that was happening 15-20 years ago and you can look into DevOps. You can also look into the Agile Fluency Project and the Agile Fluency Model. 31:24 – To get started with talking about how you should do Agile from the trenches, you can look into the books Fearless Change by Mary Lynn Manns and More Fearless Change by Mary Lynn Manns to help you to learn how to make change within your organization. 35:18 – Planting seeds allows you to make change within your organization and make a difference in a small way. 36:10 – The easiest way to remove some of these obstacles is to get together with your team and get them to agree to a trial period. There are more ways as well to get over obstacles. 43:07 – The reason he became an Agile developer is because after his first job working with it, he never wanted to work any way else. So, he decided to start teaching Agile in order to keep working with it in his career. Links: Ruby Rogues Episode 275 My Ruby Story Episode 48 Extreme Programming Agile Fluency Project Agile Fluency Model Smalltalk Best Practice Patterns by Kent Beck Refactoring by Martin Fowler UML Distilled by Martin Fowler Fearless Change by Mary Lynn Manns More Fearless Change by Mary Lynn Manns The Art of Agile Development by James Shore jamesshore.com @jamesshore James’ GitHub Sponsors Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Get a Coder Job Course DevChat Merchandise Code Badges DevChat.tv YouTube Joe Framework Summit Pluralsight James Deliver:Agile Testing Without Mocks: A Pattern Language Jake (build tool) The High-Performance Coach The Expanse by James S. A. Corey

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Steve Holyer about collaboration, culture and teams, and the state of the Agile Fluency projects. Why listen to this podcast: • Diverse lived experiences make people better individuals and team members • How important psychological safety is for teams • We all have unconscious biases and our language reflects this • The value in the Agile Fluency Model is the outcomes we can produce by using it • The Agile Fluency Model helps teams and organisations figure out how to identify value and prioritize work • The product owner as the facilitator of conversations so the shared understanding of value can emerge More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2jUipyu You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2jUipyu

At the Agile Professional Learning Network - Chicago Chapter's 2017 conference, and I had the opportunity to talk with about the Agile Fluency Project. Ahmed had almost literally just finished his presentation on the Agile Fluency Model when Paul sat him down and asked him about it. Ahmed told Paul about the 4 zones of Fluency Focus on Value Deliver Value Optimize Value Optimize for Systems The Agile Fluency is different than Maturity Models in that one team cannot be compared to another (therefor weaponizing the model) Ahmed also explains Fluency through the Tarzan example. Tarzan matured relative to his environment - swinging on vines hanging from trees, etc. But, his language fluency never quite developed, and his vocabulary very limited - “Me Tarzan. You Jane.” With a larger vocabulary and more practice at speaking to other humans, Tarzan has a chance to communicate with humans. Without the necessary practice he will either continue at his current fluency level, or his fluency could even diminish. You can catch up with Paul Madison on Twitter at @ You can catch up with Ahmed Avais on Twitter at @

At Agile 2017 Diana Larsen sat down with Dave Prior to talk about the Agile Fluency model. In this interview she explains what it is (a way of thinking about what benefits an organization needs to get from it’s teams) and how she and James Shore co-founded the Agile Fluency Project with the hope of moving past the question of whether or not a given team, practice, etc. was Agile or not. They wanted to shift the focus to a more positive approach that would help teams develop routine, skillful ease as they move further down the path of adopting agile practices with the ultimate goal of providing enough benefit to the organization so that they, in turn, receive the organizational support for continuous improvement. If you’d like to learn more about Agile Fluency, please check out the following:Your Path through Agile Fluency https://www.martinfowler.com/articles/agileFluency.htmlThe Agile Fluency Project http://agilefluency.orgAnd if you’d like to learn more about Diana Larsen check out:FutureWorks Consulting - https://www.futureworksconsulting.comHer books on Amazon: https://www.amazon.com/Diana-Larsen/e/B002BM7U7QDiana on Twitter: https://twitter.com/DianaOfPortland

** This conversation stems from an earlier episode when Janelle joined the panel: Episode 028: Brains, Feedback Systems, Demons, and Goats. 02:03 – Retrospectives ** “Software work is learning work.” @DianaOfPortland— Greater Than Code (@greaterthancode) May 3, 2017 OODA Loop (https://en.wikipedia.org/wiki/OODA_loop) 11:07 – Documenting Feelings and Emotions 17:40 – Following Through With and Solving Action Plans 20:08 – Focusing, Lists of Action, and “Best Practices” 30:27 – What is value in the context of software development? / Measuring Waste 33:39 – Taking Things in Small, Bite-sized Pieces: Refactoring Mob Programming (https://en.wikipedia.org/wiki/Mob_programming) 55:58 – Agile Fluency ** Your Path through Agile Fluency on Martin Fowler’s Blog (https://www.martinfowler.com/articles/agileFluency.html) Reflections: Janelle: Thinking about the focusing step and how much effort goes into those things versus the benefits of focusing on things from the recent past. Taking human emotions into consideration. Diana: Managing learning and collecting data, and issues around value. Sam: Different forms and cycles of feedback. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Diana Larsen.

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

Craig and Tony at the Agile Australia conference sit down with James Shore, best known as for his work as author of “The Art of Agile Development” and co-creator of the Agile Fluency Model and talk about a wide range of Agile topics including: “Java Modeling in Color with UML” book mentioned Feature Driven Development (an Australian … Continue reading →

In our journey to help create "more productive, humane, sustainable work places", we in the Agile community often have a tendency to look for a one-size-fits-all solution. But Agile transformations are as unique as the snowflakes requiring them. Diana Larsen's Agile Fluency model, which the industry veteran and pioneer discussed with us at Agile2015, offers a range of possible ways of operating to suit client and even practitioner needs.But first she wanted to clear up a common misconception: The Agile Fluency model isn't a maturity model. Diana shared. "It's a best-fit model... Getting to the end of the scale isn't necessarily the right place to be." The Agile Fluency model, then, can be thought of as having four bus zones: you have to go through each zone to get to subsequent zones -- but Zone 1 may be the best place for you to be, in which case you get off the bus and thrive there. The Agile Fluency model aims to help organizations identify the benefits and tradeoffs they are willing to make and then help them locate the zone in the model that maps best to the identified criteria.

I detta avsnitt behandlas Agile Fluency Model, en modell som Diana Larsen och James Shore hittat på för att beskriva en grupps färdigheter inom mjukvaruutveckling. Ola och Tobias pratar om själva modellen och nyttan med den. Det blir såklart en inzoomning och två kortkommandon.Modellen finns beskriven här: http://martinfowler.com/articles/agileFluency.htmlNågra hållpunkter:3:30 Tobbe sålde sin bil till…4:30 …och Ola har bott granne med…7:50 Projektledarna får en släng av sleven… igen16:50 Vad är affärsvärdet i att kunna logga in?19:25 Dags att leverera värde23:00 Ola lär oss hemligheterna i dubbel i badminton35:10 Vi tänker på segelbåtar41:50 Ola skämtar för döva öron

I speak with Diana Larsen and James Shore at the Agile 2012 conference about their recently released Agile Fluency model.  This model looks at team and organizational Agile adoption and provides a framework for looking at where you are and where you want to be. The article is here: http://martinfowler.com/articles/agileFluency.html Comments and input can be given at: http://jamesshore.com/Blog/Your-Path-Through-Agile-Fluency.html http://www.futureworksconsulting.com/blog/2012/08/08/your-path-through-agile-fluency-a-brief-guide-to-success-with-agile/ As usual I loved talking with both of them again and hope you will enjoy listening to their conversation with me. Bob Payne