Agile Coaching Network

Why ask permission to be better, the nature of work and frameworks, and assessing Agile maturity

November 22, 2019 Episode 38
Agile Coaching Network
Why ask permission to be better, the nature of work and frameworks, and assessing Agile maturity
Show Notes Transcript Chapter Markers

In this last episode of the year: 

  • (2:24) We explore why people seek permission to improve products, their teams, and themselves
  • (26:52) Do you use different frameworks depending on the nature of the work?
  • (37:42) How do you assess Agile maturity?

Special thanks to the outstanding work of my ACN hosting team.  Thank you so much Hendrik Esser, Jörg Pietruszka, and Linda Cook!

This podcast is licensed under CC BY-NC-ND 4.0

Support the show
Ray Arell:

Good morning and good evening everyone. This is the agile coaching network. The agile coaching network is brought to you by Agile Alliance. If you're not familiar with who Agile Alliance is, we're a nonprofit organization that's been in existence since the founding of this whole agile movement. Go to agile alliance.org that's where you can find out more information about programs that we're running and things that your membership that enables us to do things like the agile coaching network and other initiatives that we help our members to go off and better. This thing called agile. This is the last episode of the year. I'm kind of sad overall for that because we've, we've had I think a tremendous year. I looked at the stats and the numbers on the podcast. We are at the verge of going over 50,000 replays and that could not have happened without everyone that's in this community. I've appreciated all the feedback over the year. I think that as I look forward to coming into 2020 which seems strange to say, hopefully we can only continue to improve and grow this community that we've started and I again, I'm sort of getting choked up a little bit just because of the fact that this has just been a great time for me and I think it's been a great time for others who've joined us. One other thing, if you guys haven't looked at it yet, we do now have a new website up on the agile coaching network.org which is a vanity URL that'll take you over to the agile Alliance site. A couple of things to note is we are now syndicated on just about every podcasting service that there is, so if you miss an episode you can on more than likely wherever it is you get your podcasts, you should subscribe to it now directly from the Agile Alliance site and you can see the past episodes guide there. You can also see pictures of me and as well as some of the regulars that are on the show. One thing to note now also as we're starting to also transcribe those, the transcription service is not exactly perfect. But over all, as I read back through the transcripts of the previous episodes, it's pretty cool to actually be able to go back and if you, if you're more of a reader than you are a listener, it's a good place to actually to kind of catch up a little bit on the things that we're doing. So to start off that, the agile testing days event over in Germany and I had somebody walk up to me and we had a really nice conversation about the stuff that they learned at the event and the person said, you know, as soon as I get back I'm going to go ask my manager whether or not I can implement some of the stuff that I learned. And that actually had me kind of taken a little bit back and, and we had a much deeper conversation about what it is to be agile and what it is to actually, regardless of agile, this whole notion of why do people seek permission to improve themselves or their work or even the product that they're working on. And it always kind of shocks me that when somebody goes off and as an example, when we do story points or we do some sort of estimation process that we tend to yield towards the bare minimum to get the thing out versus the fact that no, I'm also going to improve something along the way, or I'm going to give myself some time to really learn and do this thing correctly. And right. And as you guys know, and I won't read through all of the things that agile empowers people with, but if you go look into not just the manifesto but into the principles, there are a number of different principles there that says that you know, anything from trusting people to get their job done correctly to you know, paying continuous attention to the excellence that we bring into our work and also reflecting and really adjusting our behavior as we go along the way. So the discussion that I'd like to talk about, just to kick everything off is why ask permission to go improve? And as us being leaders with the community, cause there's a number of us that are in leadership positions and I challenge anyone to say that you're not in a leadership position in the company that you're in regardless of level. How do we help to facilitate and to help people to treat them like adults and really reinforcing the empowerment that they have. And Jörg, would you like to take a stab at this first?

Jörg Pietruszka:

I laughed too. So one thought that immediately comes to my mind as an experience we had together in a bigger company where you once said to me, why do you ask permission if it's an alphabet and just do it. And if you sure it's the right thing, just go ahead. And that's something I've now for some time told to a lot of people and a lot of people react, like execute the conversation you explained. But to me this just works because people are surprised but positive results and will notice them. And if you ask permission, they all start to fear. But the why, I think that's just because we're so used to things that are forbidden and then we are challenged about and the drudgery of every day. So just be safe. So I think there are a lot of, I'm just used to it and my, either I'm in my comfort zone or it's too risky to learn. So what should we do as leaders? Make that learning possible. First of all, recognize people who just improve. Saying that's a good step into the small things. Recognize that something has improved in a retrospective. Get that culture in the people start to see this. And one question I like to ask is, did we only do good because we were lucky or did we really do it on purpose? They could challenge I think

Ray Arell:

help me with this. So I told you that how many years ago, I'm just

Jörg Pietruszka:

Oh man, how many years is it was either end of 2012 or 2013.

Ray Arell:

Wow. I'm honored that that had such a large impact on you man. Um, and not only me. Well thank you. I appreciate that. Hendrick, what do you think?

Hendrik Esser:

Yeah, I acknowledge totally what you're saying, but to ask for forgiveness then for permission, that's maybe a good rule when you're in the old state and when you want to learn something new and new kind of behavior. But I would like to also address another problem that I've seen now a couple of times and that is that is this narrative of the evil command and control and manager that we are all the time discussing. And because we are discussing this, we are, we are creating command control managers in our heads. So I think part of the problem might also be because we are creating the idea of the command and control manager and we are empowering that idea. So an example, I mean when, when when I want to change something in our company, I use my brain, like Jorg was also indicating, I mean I think, okay it's this for the benefit of myself or the benefit of the organization. And of course involved in, I drive an improvement. I involve those people who are affected or impacted and sometimes my manager is affected because he's orchestrating some work or has a certain thing. So of course I talk to that person, but this is more a conversation and not necessarily asking for permission, but the narrative tells us managers are command and controller. So it's always a permission thing. So no, I think that there is a psychological effect here that we should not underestimate. And what's that? Yeah, that we, we think that all the managers are command and control, but I think not as, you wouldn't be surprised how many managers there who are just okay with you would take an initiative.

Ray Arell:

But do you think that in that context, I mean, you know, having been a manager f or, for a number of decades, that it's important for the manager to step forward and to clarify exactly what somebody is asking of them. C ause I, I've had multiple times where somebody will come up to me and I'll ask them, are you asking for my opinion or are you asking for my permission? And what I find i s, is that in, you know, back to Jorg's comment about some, the way that I impacted h im a number of years ago is that, you know, I will purposely tell people that, Hey look, it's, it's your, it's your job to improve yourself. It isn't, isn't my job to go off and do that. That's always curious to me that somebody would, maybe you're right, w e're, w e're always painting in the context of putting people into a position where they shouldn't be.

Hendrik Esser:

You have exactly this experience. I have also been a manager and people came to me much more often asking for permission than I thought they need. Interesting. You have the same experience. You wonder, Hey, and I told you just go ahead.

Ray Arell:

Yeah, exactly. Go ahead and see what happens. And then if you want, you can, you can review this stuff with me. I'm, I'm cool with that. Damian, what do you have?

Guest speaker:

Well, I think this was just a fascinating question because I run into the same issue, whether it's kind of at the team level from an iteration or you know, a sprint and there's that pressure to we need to produce outputs, right? Functioning code or whatnot in a software environment. But just overall in general, this culture that we always fight, uh, it's easy to keep doing the same thing you've always done. And that pressure of, Hey, I want to take personal time to improve. And we all know that's the longterm benefit. That's how the entire company improves. But it's just so hard to sometimes break that culture, uh, you know, for like a, an older company especially. Um, so I, I find that to be a big challenge. It's hard to change process. Um, and just have that, that culture of, look we're adults kinda like you said. And part of our job is to improve our, our passion and our process and all of those wonderful things. But it just seems like there's that pressure of delivering

Ray Arell:

and I, I agree with that. And then have you, have you taken steps late in your company though to, you know, from a reinforcement perspective? Have you tried to help people to understand their empowerment?

Guest speaker 1:

Uh, yeah, so I mean, the current company I'm at, I'm kind of the more of a product owner role and so it's important for me to, my response is always try it, you know, and, and not fill up the sprint with just kind of a death March mentality, right? But really just leave Slack in there and encourage people to try new things and then when they fell, celebrate that as well. It's kind of like the Google approach of, you know, we celebrate our failures, quote unquote because it's just part of the learning process and that's what we're here for is to learn and inspire each other. Awesome.

Ray Arell:

Raji show.

Guest speaker 2:

Yeah. Uh, I feel this culture happens when we do it on a daily basis. Our habits, our disciplines everyday, how we behave, how we model our behavior. That when you add it up or a period of time becomes a culture and a way of doing things or habits. And, uh, as coach, I feel I try the more at most to make this to at my scrum masters, uh, how we can encourage, engage, enable, and then empower our team members, particularly doors who are not too open about it or in that rut of, uh, asking permission and being open with them and encouraging them.[inaudible] like in retro, I could come up with different games. They, we stand up, reward them. Who all volunteers, you know, bringing some idea, maybe a handle or a nice book about, uh, someone who's contributing to ideas that will make people open up. Uh, do I try what I still find? Uh, it's always, uh, an improvement, which is never a perfect the, the world rather than being a speed, we're trying to be better and better. But other than sometimes I feel there could be still something left. That's one of the ways that I have, right.

Ray Arell:

Maybe there are many more ways I would wish to learn from all of. Wonderful. Thank you. Chris, what do you have?

Guest speaker 3:

Hi everybody. Good morning, afternoon, evening, wherever you are. So my name is dr Chris Lee and I have, I'm fascinated with this conversation. It's my first time on one of these calls, so thank you. The question, the question when it comes up about why people seek permission for things that we don't quite understand why I feel that way. I do think it's a cultural dimension of many organizations and it's also, I'll say clearly defined rules around decision making since you're making an organization seems to be sort of informal and an ad hoc sometimes. And I do think understanding the parameters in which people can make decisions about certain things or maybe about certain budget amounts, certain level of effort, that type of thing. If those are better defined, people have an easier time. I'm moving within those parameters. So I think there's some organizational work that would facilitate more a free feeling of you know, people are trying new things and you know we're, we're talking about creating violence of, of innovatio n. Those are just a couple of thoughts that are in compliment. What I've heard

Hendrik Esser:

in a compliment, we are setting the Naveli constraints. Basically we are setting the frame within which people can operate and the purer we are about these frames and as much a s as wide as we can make them, that enables t he safety o ff of taking a own initiative.

Ray Arell:

And I think I mentioned this on a previous episode but you know what? We had a culture of, of, you know we would go through and do a budgeting process and we would get approvals and each of our managers would get then the known amount of money that they had to go that they had to spend in the next year. And I was always shocked that throughout the year that they would come back, managers would come back to me and ask permission again to continue to spend the money that they've already been approved for. And it, it is even within boundaries that we said, sometimes I think that older cultural norm of maybe I've gotten in trouble before, you know, then I don't want to get in trouble in the future. Uh, I'm not sure where some of that comes from. Uh, Darrius well,

Guest speaker 4:

you know, the culture is a complex phenomenon and I think there are multiple contributing factors to the why question and one of them probably prevailing factor is historical. The way we run companies is model after you know, of Winslow Taylor tradition of uh, decomposing things into some system, optimizing and making this into a well oiled machine. And this is how the military works. This is how military officers who are employed by, by industry in America and over the world form the culture. This is command and control. And no matter how your slices, this is, this was not always like this, but this is relatively recent phenomenon. The last 120 years. And before that people self organize. And today the reason we, I believe we are discussing it, we are feeling both starvation pressure that this is inadequate and military knows it. The military already revamped that. I know you probably know the term Volcker, right? In the quickly changing volatility, uncertainty, complexity, ambiguity, environment, command and control is[inaudible]. It will prevent you from reaching your goals. So we feel the stress already, the starvation and the pressure. We did not make a paradigm shift and some companies which did that, they switched completely towards civil organizations. They don't even have to consider this question.

Ray Arell:

Interesting. Oh, so do you find that sometimes we speak purely from a Western lens when we talk about this culture, do you think that say this is a problem, that it would exist, say an um, I don't know, Scandinavian and Norwegian countries versus further down in European union or other countries? Or do you think it's just, it's just widely systemic to the whole area? Everything?

Guest speaker 4:

Well, that's, that's a really good question, right? Because I think Scandinavia is a phenomenal place where things are different. Even though it's a Western culture, it's vastly different because they do experiment lively on self-organization. But I would say that even Asian countries, China and others, they rely heavily on the colonized mindset, which is really commanded control, the well oiled machine. In fact, it's not a well oiled machine. We have to shift our thinking from this to the ecosystem, which is resilient. And the resilience in the fast changing environment or VOCA world can only be handled with distributed combination. You don't have enough fast managers to do that. But if you distribute cognition, people cancer for organizing smaller groups, they will have solutions before you know that you have a problem.

Ray Arell:

Well, thank you for that. Uh, Randall, what do you have?

Speaker 10:

Yes. Um, one thing that I would like to bring out and uh, I think especially when you have organizations that follow certain frameworks, and I, I don't want to go into that conversation, but so many of the roles and responsibilities are clearly defined and in some cultures at some organizations, people don't want to step outside of that, that definition. Oh, that's not my, that's not my role. That's not my, this or that. And I think that if we can break those down, and I, I'm not a big fan of, of those clearly defined roles and responsibilities because it's kind of like that, um, uh, that one movie, uh, it was the cartoon robots where it's the, you know, you see a need fill a need and you know, that's, that's the, the type of attitude and culture I would like to see. But sometimes when you have these,

Speaker 11:

you know, some of these corporations, the roles are so clearly defined that people are afraid to step outside of those boundaries.

Ray Arell:

And do you think that contributes to more of a learned helplessness within the organization? Because I've seen, cause I've seen many a time where there's a problem right there. I mean, you don't need me to go set up a meeting and be the program manager for it for that. Anyone could be the program manager for that to go get that fixed.

Speaker 11:

Exactly. This is a very fascinating topic and actually very close to my heart also, instead of mandating the transformation, we actually invited folks to join the transformation. So, because when, based on all the conversations that have happened before me here, one thing I've noticed is the mandatory approach where like, you know what, they're doing, transformation, everyone fall in line and that's more Scott's the aspects that management would, would, uh, would start with. And what happens is they don't fall in line, they just ask everyone else to fall in line. Um, and what happens is basically the same thing, the whole command and control. Uh, they do it halfheartedly, uh, everyone, all the teams and everyone goes through the transformation. But the management still sticks, uh, the same way and they're still sitting in their ivory tower so and so forth. So the way we did it is we actually invited everyone to an invitation based approach, probably tout. If it works for you, then you can become our champions. Take the information that I can go in detail, but I don't want to, I think they had any questions.

Ray Arell:

No, no. I think, I think that's really good. And I think the, what I've learned at least in doing transformations that, you know, first starting off with informing people about what we're doing, what we, what we are expected goals are, what the business reason for that. And then coming back through and asking who wants to help, you know, enlist young people to the cause was a far better way of doing transformation than just the beat that person over the head and saying, you know, you know, I think we did it a couple, couple episodes back where we just said, you're now your favorite color is blue and I hope you like blue because it's now that's your color. And we just need to, I think in that empowerment wise and getting back to our topic here, treating people and empowering them to know, embrace that I think is part of what leadership's about.

Speaker 11:

Absolutely. And they won. I'll just add one thing. I give the example of the movie, the member of the Titans in that movie, it's actually, they make it so they, they, they don't invite everyone. They invite few folks. They actually become the champions. They empower themselves. And while doing that, everyone else who was sitting in the who were not, who are not actually consciously contributing, they started contributing also. And that's the mindset I always try to embed then when we do the call coaching ask.

Speaker 12:

That's wonderful. Yeah. So I wanted to add to that, um, because oftentimes I'll see that companies say that they'll empower the teams and power the people, but as soon as the decision is made, as soon as that person who's given that empowerment makes the decision and it's not exactly how the manager wants that instead of celebrating the learning experience is celebrating the failure, they come down with like a punishment where they come down very hastily on the person and which gives that culture of fear again now. And that person doesn't want to make a decision because they don't want to be reprimanded.

Ray Arell:

Right. And that's a tough position to be in. I remember having a manager, he'd managed with fear and I remember one time he asked me, could you give me honest feedback about my job performance? And I said, do you really want me to give you an honest feedback of your job performance? And he said yes. And I said, okay. And I laid it out for him and he stood up and he pounded his hands on the table and he said, you know, you're wrong. You know, and I'll let me tell you all the reasons why you're wrong. And he kept going on for at least 20 minutes. And then afterwards I said, I'm never giving you honest feedback ever again. That's it. You know it's it. Have you seen that?

Speaker 12:

Yes, that's, that's the, that's the crazy part because they want you to be transparent. But if you give them feedback that they don't agree with, then you know, you're made to feel ashamed that you don't agree with them or you're not saying what they were expecting to hear. And again, that just turns off the trust. It turns off the safe space.

Ray Arell:

And what I've told managers before, a lot of times is, is if you're accepted, you have to be prepared for the feedback that you're about to get. And I've had many people come in and says, can I give you feedback on, on something? And I'll say, you know, right at this particular point, my mood for whatever I may have came out of a budget meeting. I might've came off from some, some, you know, big hairy technical problem that we were dealing with. And I've told people, I said, I'm not ready for this conversation. Right? Can we do this tomorrow? That would be a better time for me. And I think more people need to, to control their, you know, you own your response to things. And so if you're not ready for a conversation, you know, put it off. But also have you invite people to ask for feedback. You've got to be careful not to respond. Absolutely. Matthew. I, there are

Speaker 6:

a few things, I mean there are a lot of things that people said they're really interesting but weaving together a few of them. I think it's clear that sometimes learning is constrained either explicitly by say management in general or managers saying, you know, you can't have that time or implicitly by the culture, but my company actually is sort of the opposite extreme where leadership is all but begging people to take time to learn. And in thinking about this topic as people, you know, bringing up their various situations, it occurs to me that, you know, we have, we have this problem where even when we make that space, uh, we, we give people permission. They're not taking advantage of it a lot of times. And so in looking at why that is, I mean, I think one thing is you have to make room, right? If you say, yeah, you can do all the learning you want, but then you make it so they have zero time to do anything, of course they're not gonna take that choice. Um, uh, but the other question is whether in terms of, is there some way to create pressure to induce learning and right to say, Hey, this is something you really need to do. So, for example, if your manager takes responsibility for saying, Hey, what are you learning? Where, where are you going and really holds you to that, then I think that that can drive some of that learning. And it's a little bit of a question of do you treat learning as sort of a perk where you say, Hey, it's the ping pong table, you can use it or not. If you want to learn, you can. Or is it something where you say, no, this is part of what we do here and it is valuable not just to you but to the company in general. And we're going to say, you need to do this work and we're going to put in place incentives that drive, uh, drive pressure towards actually taking advantage of that learning. Not simply saying, well, you can take it if you want it, but we're not going to really make room for where, where we're not gonna, we're not going to hold you to it.

Ray Arell:

Hmm. Interesting. You know what, I think if you look at, um, you know, the review and stacked ranking and all of the other mechanisms we've had for, you know, centuries that seems like that I think is one of those things where we're trying to at least motivate people from where you're at in the job ladder. And if you want to get higher, you know, there's, there's these, there's these boundaries you have to go through. But what I find is, is that there are certain people within the environment, they're perfectly fine with where they're at and, and they don't, they, they, they, they may have family at home or they might have other things and they're just content with what they're doing. I found that at least from what you know, triggered this question for me was here was a person legitimately wanting to go off and change, but they felt that they were blocked because of somebody else or cause a company rules and[inaudible]. That to me signaled that, you know, in two half's of that coin, one half of that coin is maybe your company is oppressive and if you want to go learn, maybe you need to go June joined a different company or you really don't want to do it, then you're just using that as an excuse which is, which is, uh, which I hopefully that wasn't the case. And if that person's listening, I'm open to further conversations on what we talked about. Well, it looks like we are going off to the main questions. And the top question up here is in agile transformations, have you used different frameworks based on the nature of the team as an example, product and platform teams use scrum and service-based type projects. Do you use Kanban? Rick, would you like to start off this one? Hold on, let me get my little check Mark box done. Okay, next question.

Hendrik Esser:

So w why, why is the answer yes. Um, I mean agility is about the ability to, uh, use the right approach and the right situation. And, uh, I always, I mean the two of us, Ray had this discussion a couple of times about capital a agile and small, a agile. So is it agile in the name of scrum only or you use your favorite scaling framework or whatever or is it about agility and more and more as you mature more and more in our agile journeys, it's much, much more about agility, which means it everything needs to be fit for purpose. So if you are in the very front end with high uncertainties in the work that you are doing, you are, for example, having a new business idea and you're exploring now how to, is there a customer, how to address them? Can we earn money with this in high levels of uncertainty? You better use something like design thinking when you have a product then you intuitively want to add features incrementally and learn your way forward. Agile and agile practices like scrum are extremely helpful. Then when you are more um, having something like a routine work and I would think service-based is very much a way. There's not so much uncertainty and you can start making the flow optimal. So they're coming based systems work. Right? So it's a fit for purpose question.

Ray Arell:

And I fully agree with that. I mean what I look at is is how much do we know about the product or the feature or the thing that we're trying to go off and do. And when you think about service based businesses, even in service-based, you know, types of issues, the complexity of what's coming in could be a higher complexity than you might have knowledge on. So yes combined might be a better choice, but I would even think that in the Kanban model, you know, safe to fel experimentation with some sort of tracker, some sort mechanism that I can know where the status is at is good. But yeah, would I go pick scrum for Dean or paint the world with it? Absolutely not. I, I think that even in products and platforms, early ideation phase, I don't have enough information to write a user story. And, and as you know, a user story is required in order for me to do a planning meeting. And if I can't get through the planning meeting cause we're all just saying, Hey, that's going to be another spike, another spike, another spike, another spike. I have no control over my system at all.

Jörg Pietruszka:

Allow me to add something to link this to the last question. I actually prefer if the team understands what it's asked for and picks the method. So I was very happy to have a team. Me scrum doesn't fit because anyway, it stuck with the scope. So let's get through this fast and then good quality and stop doing scope discussions that lead nowhere because competition is the head. And so we have to do it.

Ray Arell:

You mean take it to the team and ask

Jörg Pietruszka:

[inaudible] they actually decided to tell me that they wanted to change the method. I didn't have to ask them. They were smart enough to notice that they were spending things in, in a way that something else would be most useful. So they switched from scrum to Kanban

Speaker 11:

and they're asking you for permission?

Jörg Pietruszka:

No, actually they ever just telling me that that wasn't their way. They asked me for advice.

Ray Arell:

Referring to the last question.

Jörg Pietruszka:

Yes, I just wanted to underline it.

Ray Arell:

Just want to make sure you weren't putting yourself in that control control area.

Speaker 11:

So this question is quite literally the million dollar question and a, that's literally how big management companies like McKinsey and all make their money enduring in the name of transformations. Sorry, I said that loud. Um, but the aspect, but the, the aspect here is, is actually more of lean agile transformation. The question is, are you following, do you actually understand the values of the lean agile transformation? Do you understand the principles, the values that you're getting out of it? What is it that you're trying to accomplish? Scum, Kanban and scrum bond or a safe, yes. I knows for some that's a bad word, but say for less or whatever it is, there's so many different frameworks available in the market, but they're, but they all serve different purposes. Uh, we can say like, you know, we are going to only use this because that suits us better. It's more in terms of what suits the, uh, the environment, what suits the teams and the team members. I think it was our, Hey, I think if, I'm sorry if I'm pronouncing your name incorrectly, but I like his approach. It's, it's the whole Shuhari aspect of it. Uh, where the, the, the shoe is basically the first aspect. Where does the team, let's, uh, let's invite them and understand where they are and where they want to head, and then we experiment a little bit in the high leery aspect. Uh, and then it could be a merge of all these different frameworks. It doesn't matter. It's, it's all about are we able to provide value or not. Right. I agree with that. Uh, what do you have?

Speaker 13:

Yeah. Uh, on the same lines, I feel that, uh, different teams have different needs, uh, based on what information they have, what decisions they care, how much planning they can do. If they can't, then Kanban is quite good enough to just go with the flow of request and keep servicing them. Uh, there is, some teams have to do a lot of planning. Uh, they need to consult on estimates and stuff like that, but it's all, uh, based on the need of the project. And yes, definitely. Uh, we have to keep an adapting. There's done, uh, which platform sells the best for the scrum can, Barnard from barn or whatever. Uh, and uh, as we go along, uh, sometimes some meat we may bottle some of the best practices. There is no best practices. What is good for the team, uh, which can be borrowed and done partially and so on. I know we, uh, we shouldn't be doing[inaudible], but often, uh, something which is more useful, we can do more of that and less of some things. Uh, so sometimes, uh, we ha we have, uh, been doing some implementation of crumb, which is, uh, not really ideal of crumb, but it has, uh, being more like Kanban, being less of planning, even though we do planning, but it's not really scramble. But, uh, we have to go along with the attitude, the environment, and the need of the project.

Speaker 11:

Thank you for that. David, what do you have

Guest speaker 4:

when people say framework, they kind of forget what that means, right? It means do what makes sense. So the way I explain any kind of framework, be it scrum or safe or dad or last or whatever or nexus or whatever is it's like playing chess. First you have to learn the rules of the game, which is how you move the pieces, right? Though the knife makes a little L and the Bishop goes diagnosing the queen does whatever she wants, but once you understand how to play the game, how do you play? The game is completely up to you. So you put in what I call the gut, the guy up the guardrails, right? That you know, okay you push, you should probably sprint when it's when, when a team that's spring comes to me and says they want to do a Kanban, I asked them why and the invalid answer is cause we don't like scrum, right? The proper answer is do what makes sense for the team. Now some teams are more event driven and condom makes sense for them, but some teams need to really understand the frameworks to read and how to get better at it as opposed to, you know, changing things. So, yes, we do just use different frameworks based on the nature of a team, but also the requirements of the business too. You have to keep that in mind as well.

Speaker 11:

Yeah, no, I agree with both of those. I think that a lot

Ray Arell:

of times when people come up to me and they say that they hate a particular framework or the framework's not working for them and in particular way, and I asked them, well, what are the alternatives? What, what do you want to do? I've had some people say we want to go back to the old way, but what I found was, is that the old way was no framework, no methodology at all. And so to me that's unacceptable. It's, it's more or less how do you go and arrange your work in a way that's most effective. And I think you hit it on the head, which is not just what's good for me, but it's also what's good for my customers as well. Jonathan, you've had your hand up for a little bit. What do you have?

Speaker 12:

Yes. Um, I wanted to also kind of add, and I guess this kind of shows my, uh, geek side, but when you look at the star Trek world, Oh yeah. There was this prime directive for like cultures that are, or people that they came across that wasn't technology advance, was that ready for that next level. They weren't going to introduce that technology to them. So as much as I do not, uh, desire safe, there are places where organizations that are trying to get between that management can't fully trust their employees because their employees just doesn't show that discipline doesn't show that responsibility to be, to be empowered. That safe kind of adds that middle layer. Um, I don't think that, you know, it allows them to really experience the whole agile experience. But yeah, I do agree that there's a time and place for each framework. Um, as well as some cases, you know, you, you may want to prefer waterfall, especially if it's a labor intensive, um, uh, product you're producing.

Ray Arell:

How about just use waterfall with the agile principles and I bet your waterfall is going to be a lot nicer. So, um, well shall we, um, PennDOT from this question, are there any other comments on this? Okay. Um, let me go ahead and let's, we have another assessment questionnaire. How do you assess agile maturity? You are in QA to take that one.

Jörg Pietruszka:

Yeah. My, my reflex was to say, uh, say just by, by, by the age of use, but only with a smile. No. Um, actually the best thing is self reflection I think. And if self-reflection says this a way where we want to go, that's probably the best maturity you ever can get. Being ready to do the next thing. There's nothing like perfection. And if you recognize that there's something that you can improve, one to improve a curious it, and that's part for the next step. Why care for maturity? What do you want to measure with that? The only thing is if you meet new people and want to know the experiences, talk to them. Ask about their thing, what they've seen. That sounds

Ray Arell:

good. Matthew, you're have your hand up.

Speaker 6:

Uh, I, this is largely a restatement of what was just sad. I mean, oftentimes when we, when people say they're, they are embarking on what we call an agile transformation, they say, Oh, we want to go agile. My first question is why? I often cringe a little bit. So we're like, what? What is it you're hoping you're going to get? And to me, the maturity question is a similar one in that, uh, I would say, what, what is it you're going to get out of that information? What if I tell you, you are mature, you're eight out of 10 or a two out of a 10. What, what are you going to do with that information? Um, if the, you know, if the answer is you know that you're going to Pat yourself on the back, then I say, well, you need other reasons to Pat yourself on the back if you're, if it, to me, it really lies in the relative question, right? When you embark on an orig original, um, agile transformation, the reason hopefully is because you hope to improve something. There's something that you don't like currently that you want to make better or something that maybe you like, okay, but you want to like it even more so you're going in a direction and I would say that even after you've adopted agile, the question of maturity really is about, you know, do you want to be more like, do you want to go further in this direction? Do you want to expand? You want to improve in this area and that that should be the real, the focus is is where do you want to go from where you are? But really if anyone asks that question, I would say, what? What are you going to do with the answer to that question? They're like, what? What is it going to serve? And because I think that in the answer to what someone would do with the agile maturity score or data is going to be some really telling sense of, of whether it's actually a valuable,

Ray Arell:

yeah, I agree. I what I've, what I found in, in most businesses that I've walked into and asked the question, what do they want to accomplish it you'd say, do you tend to sometimes get this robotic answer, I want to be agile and well, no, what do you want to accomplish? Why I want to be agile now? What business goals are you trying to go achieve by doing the agile transformation itself? And to me the maturity is buried in maybe some of the shortcomings that you might already have with your customer and delivery today or maybe your employee satisfaction or your go figure out what this bigger global goal that you're trying to go change, which is, you know, how am I improving people loving and falling in love with my products and, and, and employees falling in love with working at this place. You know, those are all the key things. Raven, what do you have?

Speaker 14:

Um, I have a question actually. Uh, in regards to your response, when you, when you say, you know, why do you want to go agile? Um, what would be your response if a person said and answered your question? Say the reason why I have to go agile is because my manager stated that all 15 of my teams have to go agile. And if we don't do it effectively that,

Ray Arell:

Ooh, that I do not like the framing of that, um, at all. Um, I think leadership, and this is another thing, if we've got people who are in leadership positions on the call, you need to really frame this in the elevator pitch of the business goal that you're trying to go accomplish, which is we were moving this way because of a competitive threat because our, our, um, because of our, our competitors are there, they're working in an agile way and they're cleaning our clock or whatever. Whatever the urgency that you want to go push onto it so that people feel that, that urgency is something that they can take up as a goal. But if you put it in buried in the, you know, you're not going to get a raise. Oh my, that, that, that really is troublesome. Hendrick, have you ever done that all the time? I hope not. Man. Um,

Guest speaker 4:

Jonathan. Yeah, it's, it's, it's one of those things that I, I worry even when people ask, you know, what's your velocity is like you guys had said before, what are you going to use this for? Are you gonna weaponize it? Are you gonna, you know, use it for people's reasons to increase their salary or are you really trying to improve yourself? And I, and I can't remember who said it, um, just previously, but doing retrospectives or having the team, uh, do self checks. You know, we're, we're, we, uh, two sprints from today. You know, what, where's our goals? Do we set to improve? Did we accomplish that? To me that is the better assessment. Then I'm trying to use some type of a maturity model. So the question, how we assess maturity is just a question about tools or people you think it is. Okay, go ahead. I think it is because what happens is without people, you don't have anything. Right? And if it is a doubt, most people, my question will be, how do you assess the maturity of an adult? Does it even make sense? I don't think it does because you know, you may have an adult who will at times behave like a child correcting jokes, which will be completely appropriate. Right? And talking about movies, play, et cetera. So does it learn the maturity? I think that is like some people suggested really that you should, Oh, are we um, satisfying the way we are delivering does it's really do we harvest what we potentially can or are we stuck

Ray Arell:

as humans? I think sometimes we want to see conformity and I also want to benchmark myself against others. Am I living up to something, you know, and some people really thrive for having some form of reference. I mean we went through a decade of CMI and and other assessment tools that were in certain cases inflicted on organizations. And my fear always when I see questions like is there now suddenly going to be the next round of maturity models that are going to inflict things onto people where you have pretty much snuffed out the fun on agile. And I don't like it anymore because all I keep getting is, is another assessment that's saying that I'm a four and I should be a 10.

Guest speaker 4:

Yeah, and I know that you would agree with that, that you'd all, all the monitors are wrong. Some of the models are useful. If I am measuring something because I want to check if my child has a fever, the the measurement, the metric is useful, but the moment the metric becomes a target in itself, which I think everyone was referring to it, it's useless, right? People are going to game the metric and for what purpose do you use that? Right? If I feel, if I feel that I am doing what I can potentially, then I'm satisfying you find, think that we can do better or differently to deliver more, then we should go this route. And if we find a useful metric to check the temperature, I'm not going to deceive myself. What's the temperature of my child? Uh, it's useful.

Ray Arell:

Right? And I agree with that. Unfortunately we are at the top of the hour and this being the last episode until the new year. I'm just going to make a big heavy sigh right there. I want to thank everyone for this year again. We've had I think, a tremendous impact on a lot of people. I get a lot of comments via email, but it's not just, you know what the regulars and others that are on the show that do that. Everyone who participates in this call, regardless if you add your voice to it or if you're just on there wanting to listen to this or making some differences within the greater agile community. If you want to see me, I'm going to be over in December at Erickson. I'll be hanging out with Hendrick over there. What are the dates on that? Hendrick, what do we want? What are we going to Dean's 14th and 15th of December and we'll be in Stockholm. Yes. And so if you are in that area and you just hang out with us for a little bit, uh, just reach out to me on my email and we'll, we'll get something going after that in February. I'm going to be over at agile today over in India. It should be a, I think a pretty cool event. I think a, I'm seeing the lineup, they haven't announced the actual schedule, but I got an early copy of it and I think it's going to be pretty cool event overall and then after that there's a chance that I'll be over at agile in the out and we'll be able to meet them. Also, if you guys didn't do this yet, the call for papers for agile 2020 is now open. Please submit, get those in early. What I find is is that you know, they, they do get a tremendous amount of paper that come in, lots of great submissions but get it in early so that you know, you can get some consideration. They do provide you feedback on your submission so that if you want to modify it throughout the open submission period, you can, and I know that also that registration is going to be soon open for that as well. With that, I would like to say to all of you, I hope you guys have a happy holidays and I hope that you and yours have a great new year. This podcast is provided by Agile Alliance for educational and informative purposes only. To find out more information about the member supported agile Alliance, please go to agile alliance.org to find out about more upcoming events as well as different programs that are available to help you with your agile journey.[inaudible].

Introduction
Why people seek permission to improve products, their teams, and themselves
Do you use different frameworks depending on the nature of the work?
How do you assess Agile maturity?
Wrap up