Episode Description
This week, Dan Neumann, your host, is sharing what he has learned from his continuous learning journey that brought him to acting classes several months ago and that now involves him getting a part as an actor in a play. Dan learned from his acting classes a lot of wisdom that can also be applied to Agility and in the delivery of value to the organization and he is sharing it in today’s episode.
Key Takeaways
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now, here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann. And I want to take a moment to really appreciate each and every one of you who are listening to this podcast, it’s the engagement that we get and your listenership that keeps us going. So thank you very much for that. At this point in a lot of shows, I’m introducing the people I’m collaborating with at AgileThought and this episode is going to be a little bit different. For those who have been listening, there have been times over the last several episodes where I have mentioned that as part of my continuous learning journey, I am taking part in some acting. So I signed up for an acting class thinking that would be a good, both personal and professional development opportunity for me. And as part of going through the learning and the classes with theater, I ended up auditioning for a show that we’re going to be doing here at our local community theater.
Dan Neumann: [01:13] And, it’s kind of an honor to have been selected as one of the caster members for a show that we have coming up as part of being an actor in a show for the first time, I am getting a tremendous number of nuggets of wisdom, little bits of insight, curiosities that are not only helping me for what we’re doing with our production, but they also help me for thinking about agility and the way teams deliver value for their organizations. And so I want to take the time with you, the listener here, to explore that over the duration of this podcast. So there won’t be a kind of a single theme to this one, other than the theme being the lessons that I have learned and want to share with you. So here we go.
Dan Neumann: [02:03] The first one that I want to share with you is really related to having some role clarity as part of this production. I am an actor in the show. I am not the director. There is a director. The director makes it clear that the actors are not the director, the stage managers not the director. The director is director, my role in this particular show for the duration from the beginning of the rehearsals, until the show closes is to be that actor. It’s a temporal role. I won’t be playing the part forever, but for the purposes of this particular time box, I will be doing that. And so there are expectations about what is appropriate and what is not appropriate for me in that role. One of the places that comes through loud and clear is in decision making authority. So if you’re not the director, you aren’t the decider for how the show is going to be produced. Of course, the actors are bringing themselves to the characters that they’re acting. And there are times when it’s appropriate to go to the director with an idea for maybe how scene could be interpreted or how somebody could engage with the scene. But ultimately it’s up to the person accountable for the show happening to make that decision. And I think of that with our, with our software development teams. As a lot of times it can feel like every decision maybe should be made by in consensus where everybody on the team has to agree. And that’s just simply not the case. If you’re doing the scrum framework, there’s a scrum master, there’s a product owner, there are developers. If you are a developer on a team, you are not the scrum master. You’re not the product owner. Yes. Take your ideas to the product owner. Maybe share some of the thoughts that you want included in the product backlog, but ultimately accountability for that product backlog is the product owners. So just kind of having a lot of clarity about roles, one of the phrases I think I heard, I don’t believe I’m making this up in the theater is theater is a collaboration, but rehearsals a dictatorship. There are things that are going to happen that aren’t going to be driven based on how I would want them to go, or maybe how I think I see them going because it is somebody else’s accountability for what happens in that space at that time. Of course, there’s an opportunity to give feedback. There is a working agreement that we have, take ideas to the director individually. When we have our whole cast meetings, it’s not appropriate to address everybody’s every curiosity or question or idea in that big forum. There’s a time and a place for sharing ideas and getting really clear about that is super helpful.
Dan Neumann: [05:05] Take it to the director. If it’s something for that part, take it to the stage manager, if it’s something about the mechanics, but being careful to really use the right forum for that feedback. One of the phrases that stuck with me is when you have an idea in a large forum, does it need to be said whatever the idea is you have, or the thought does it need to be said by me? And does it need to be said right now? So that kind of walking through those three questions can be entirely appropriate for deciding when, and in what form you share some feedback. So those are some thoughts about feedback that might be applicable to the entire group. I also want to explore a little bit about feedback that you might want to give that I might want to give in my context to a fellow performer, to one of the people helping with the backstage logistics. And that is, first of all, make sure there is an invitation for feedback or an openness for the other, from the other person to hear that feedback. You can simply ask, Hey, I was observing something and do you mind if I share that with you? Do you mind if I share that with you now? Or would it be more helpful to have it at a different time? Really being conscious of when you’re giving the feedback not just if the feedback is welcome.
Dan Neumann: [06:35] So let me give you an example. In our show, there are some significant musical numbers. So it’s a musical again, not just acting but way outside my comfort zone in a musical. And so going to one of my fellow actors before they’re getting ready for their time on stage with the audience with that musical number is not the time to be sharing feedback. They are trying to get into their own head space. They’re trying to make sure that they’re ready for what they are accountable for and the timing’s just not right. And I feel like a lot of times in software teams, especially, you know, agile teams, there is a misconception that it’s feedback is always welcomed and you should give it at any time and you really want to be conscious of the timing of it. And that there’s an invitation for it. So yes, ask permission to share feedback, make sure that you’re invited in, don’t misunderstand that’s not an open invitation to provide feedback in perpetuity, into the future whenever you kind of have more feedback. Typically a person is saying, yes, you can give me feedback now on this situation, but don’t mistake that for an open invitation to always give feedback. There are a lot of challenges with estimation in software development in general, this is a decades old problem, probably since software development began.
Dan Neumann: [08:08] And, I got thinking about theater. We have an opening night and as I’m recording this, that opening night is tomorrow officially, but tonight we will have the first audience, the theater does a pay what you can preview as a service to the community. So we will have an audience tonight, that date’s not moving that date hasn’t moved since the production was announced, and it’s not going to move. There were some conditions under which it might have moved. Of course the COVID pandemic is still going to various degrees and different parts of the world. So possibly there could have been some kind of condition with the pandemic where yes, the date would’ve moved or the show would’ve been canceled entirely. Barring that however, it’s happening and we’ve known it’s happening since before auditions even were called. So how do you go about estimating something like a show. Software is a concept of expert estimators. I am not one of those in a theater context, but I believe our stage manager, the production company, the director, they have all done shows before, they’ve all done shows of a similar complexity to this before they have experience putting on a show and knowing how much time it takes for that show to happen. If you were to have asked me to estimate a show, having never done one, you’re going to get almost certainly get a horribly wrong answer. It could be too small. It could be too long, but it’s going to be wrong for sure. So really embracing the fact that there are people who know how to estimate some of these things maybe have experience with them and looking for opportunities to engage those people as you’re encountering something you’re being asked to estimate that maybe is completely new to you.
Dan Neumann: [10:03] The other facet related to estimating is your estimate is always going to be wrong. We, in this case, lost days, there were snowstorms, the pandemic was more pronounced in our area when it started. So we lost rehearsal days, but that date doesn’t move. So now what do we do? How do we inspect and adapt and adjust to what’s coming up? There is accountability for individual performance related to that. People need to go and rehearse their lines. They need to come in prepared with things that they can work on independently, which is another theme I want to touch on as it relates back to software. What can you do as an individual outside of the bigger forums to make sure that you are prepared to bring your whole self into the work? So that’s just a little bit of a mental framework or thought pattern as you are reflecting on your own individual performance and how it maybe affects the ability for the whole team to achieve its milestones or not. How much can you contribute outside of moving as a large group,
Commercial: [11:16] Have a topic you want us to tackle? Send an email to podcast@agilethought.com or tweet it with a #agilethought podcast.
Dan Neumann: [11:28] I want to start now and maybe explore a little bit about personal accountability. And I one of the things I absolutely love about agility is the team concept and the team-ness that gets advocated for, and is certainly important in delivery. But there are also times where you need to do your part and other people need to do theirs. And it needs to be very clear who is responsible for what activities. So let me give you an example, the props for the show. There are some specific props that I need. I need to know where my plate of cookies are. I need to know where the bottle of champagne is. I am accountable for having my props ready and being on cue and ready to go at a particular time. Just like every other actor in the ensemble is, now there might be times where I notice that maybe there’s a chance somebody else’s prop is in the wrong place where I know that they’re going to need it for the show, or I believe that they’ve typically used it that way for the show, but it’s not mine to move for them. I don’t know if they have changed something about how they operate and they’ve put it there. So kind of making sure to know what your accountabilities are and the supplies to agile teams too, and then not ignoring potential downsides, if somebody else maybe looks like one of their accountabilities is out of place, if you will, but really then making sure before you move something metaphorically, within your project team, clarifying with the person who is accountable for it, was it intentional? Did they want to have that particular approach taken? Do they need any help? maybe in a show, maybe somebody simply forgotten, did have the prop out of place and they want some help, but maybe they put it there very intentionally. So just being really clear about the roles, the accountability, the setup, when you intend to move something, asking if somebody would like help with moving something and then advocating for your own needs.
Dan Neumann: [13:45] And this is a thing that actually applies very well to scrum teams. A lot of times the daily scrum is mistaken for a status report to somebody. Well, guess what? That’s not what the daily scrum is for. The daily scrums, a chance for the developers to collaborate with each other about how they’re going to go forward. And I like thinking of this now, as a chance to advocate for yourself, here are the things I need for us as a team to be successful, you know, in the show that might mean I need to work with the props person to get, I pour drinks, I need a bottle with some kind of liquid in it so that the drinks can be poured. if that’s not there, there’s a problem I need, from the costume person, I need a tire that fits if something isn’t fitting right, I need to work that out with that person. And if a transition isn’t happening well on the stage, I need to advocate with the director often in private to make some kind of shift to how we move forward. So as a software development professional, you need to advocate for yourself as well. What do you need to be successful? How can it be gotten? Maybe there’s a suboptimal way to get it versus the ideal, but you still need to advocate for having your concerns or your needs addressed so that you can fully contribute to the team.
Dan Neumann: [15:13] Let’s talk about transitions for a second because this in software it might look like a deployment, a big deployment, especially there are transitions that happen within sprints at the end of sprints and on the theater stage, lots of people need to take a lot of coordinated action in a fairly small amount of time. Think of, you know, moving a bed in onto the stage, setting up a dresser, making sure bottles and glasses are in the right place. Blankets pillows, curtains are set, lighting is set, et cetera. Those types of highly coordinated needs that have to happen quickly and effectively do require, first of all, rehearsal and everybody needs to know what their part is. When we talk about scrum teams, sometimes we talk about team members swarming on particular activities, which can be fine, but there are also times when it’s appropriate for people just to know what their part is and to make sure it’s executed on time and with excellence and depend on your teammates doing things, in a transition If I am accountable for moving a topiary onto stage, I can’t sit down my topiary, go try to help somebody else with the bed and, and not care for what I need to do when I’m trying to help another person.
Dan Neumann: [16:40] So kind of just thinking through how to create those accountabilities for every person to know their part and debriefing is a really important part of making sure those transitions happen. Well, Hey, we launched a software product, this sprint let’s debrief on what worked and didn’t work through that transition. Did everybody know what their part in a deployment was? Did the deployment steps happen smoothly? Where did we maybe run into a problem with releasing software? Did we tell our customers it was actually coming or what the impact to them might be? So just thinking through the transitions, accountabilities, reflecting back on those transitions to improve them. And then also thinking about what are the triggers for change, make it easy for people to know when a change is coming and thinking of, you know, this acting example, standing backstage, you can’t see what’s happening out on the stage. You can hear it, but you can’t see it. And one of the kind of ways to idiot proof the transitions we have is a light that goes on the light going on means get ready, a transition’s happening. And as soon as that light goes off, that means we’re transitioning now. And it makes it really obvious. You don’t have to remember where exactly is this cue. There’s a big red light when the big red light comes on, get ready when the big red light goes off, do your thing. You are accountable for knowing what your thing is, but the light helps you know when to do it. So think of your software teams, what are those transitions that you have and what might your equivalent of a big red light be for them? How can you make that transition super obvious as far as when it happens and then how can you make it easy for people to do their part and then reflect on how it went as a transition and then improve the transitions for the next time through so that there’s less confusion and chaos.
Dan Neumann: [18:51] I want to talk about risk for a second. As part of doing our show, there’s an orchestra, it’s a small orchestra, handful of people who would’ve thought that we’d have a violinist break their wrist as the show was approaching. Who would’ve known that we would have a snowstorm that was going to cost us a day of rehearsal time? How could you forecast that somebody would have a family emergency that would take them away for a week of rehearsals? The answer is you can’t. We can often get lulled into a false sense of precision, where we come up with the estimates and we lay out a plan and we try to manage all the risks that we have, but ultimately things will happen. It’s not obvious what they’re going to be, but something’s going to go wrong and needing to then respond and adjust in time. And this ties back to the estimating of our project. How long is it going to take? hard to tell, expert estimators can help. If you have done this type of work before you are a type of expert, if you’ve done work similar to this, you can use what’s called reference class forecasting. If this work is similar to that work, they’re probably going to take about the same amount of time. if you ran into problems the last time you’re probably going to run into problems this time. And what I mean by that is you think of a project, maybe it took you four months and you go, oh gosh, you know, but we ran into an illness, an outage, some technical hiccups, hardware acquisition, purchasing was slow, we had to get an approval from compliance, whatever the case might be. It took six months, a lot of software projects go horribly wrong. When they look at the new effort and go, well, this one should only take four because you know, the last one was delayed with compliance and audits and acquisition and, and, and guess what you’re probably going to run into on this project? Compliance and audit and acquisitions and, and, and it might be different, but you will almost certainly run into a similar volume, similar impact of delays with the qualification that unless you’re really doing some root cause analysis, when things go wrong and improving your system to make it more resilient and less vulnerable to different types of problems, you’re going to have the same problems again. You can mitigate the impact by having resiliency, resiliency might look like, we have some slack in the schedule for something to go wrong. We have multiple people maybe who are capable of delivering on a key piece of work that needs to be done as opposed to the one violinist who if they break their wrist, we are in trouble. Fortunately for our show, there are a bunch of violinists known in the community and some of them, one stepped forward and we’re going to be just fine. But when you think of software teams, a lot of times it’s efficiency and we have the one person who can do the thing, and that makes your system incredibly fragile. So, really think about resiliency and how you can build in some resiliency sometimes through redundancy, sometimes going through and doing some kind of root cause analysis and then process improvement to make sure that that is not going to happen again or if it happens, the impact is less severe and the recovery is much faster.
Dan Neumann: [22:36] And I think the last facet I want to touch on, although I may inspect and adapt before I click stop on the recording is really taking care of people. That is so important because ultimately businesses are collections of people, software team are collections of people. They’re not resources, they’re not assets, they’re not whatever other kind of euphemism we use to pretend people, aren’t people. You’ve got a whole bunch of humans there and humans are complicated animals. We need to both make sure the physical and emotional needs of those complicated animals are taken care of. What does that look like? That looks like things as simple as letting people know what’s coming, what does the future look like as it’s able to be shared? Of course, one of the fallbacks of, or one of the downsides of waterfall was we pretended we could do the requirements, we pretended we could get all the design and then build and test and release, et cetera, et cetera. But that was a false sense of security that we were giving to people. In reality and with agile now, what we’re looking for is more progressive elaboration. So what is happening near term with a high degree of precision as we look farther out, that accuracy degrades and the level of detailed degrades, that’s fine. And the farther than farther out we look, we get less specific, but as that work gets closer, it needs to be unfolded and refined and elaborated and clarified as the work gets closer to people, because people want to know what’s happening, uncertainty is uncomfortable. And so to the degree possible unfolding and demystifying the uncertainty as the work gets closer, builds a lot of comfort with people helps take care of their psychological needs and the emotional safety there.
Dan Neumann: [24:34] Be clear about startings and endings. When are things starting? When are they ending? When do we expect people to participate? take into account a variety of needs for your humans. You’ve got different ages, different needs inside and outside of work, making sure that we’re taking care of our people as best we can. Anything from as simple as, you know, snacks available, breaks available, to the more complex things like checking in with your team, how are you doing? And these can be collective check-ins at times, and they also can be individual check-ins. Go reach out to your teammates one on one and say, Hey, how are things going? maybe you observed something that you are curious about and would like to kind of know if there’s something going on. So reach out to those people and be supportive. It’s not a manipulative thing. You’re not looking to gain some insight that can be used against them at some point, but you’re really wanting to approach that with curiosity so that people can feel and be supported. Touching on the fact that all these efforts that we’re doing involve humans and uncertainty and agile methods are ones that acknowledge that there is the uncertainty we are dealing with humans. You know, we’re talking about people and interactions over processes and tools, business and IT collaborating together, not just planning, but also replanning. So hopefully these reflections on my experience with the theater endeavor that I’m part of have been helpful for you and would of course love to hear any questions or comments you can email to podcast@agilethought.com and I will get back to you. Thank you much. And until next time, really want to appreciate you being a listener. Thanks.
Outro: [26:32] This has been the Agile Coaches’ Corner podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com/podcast.
