An agile approach can be applied in many different places, like this podcast for example! This week, Kupe and I demonstrated how applicable agile techniques are by discussing how we use the agile mindset in our radio show and beyond.
Episode 24 | #AskAnAnalyst Top 4 Takeaways
- Agile isn’t just an approach; it’s a mindset.
- Don’t assume that the option that worked best for one problem will work for the next. The key to challenging yourself is don’t start with the first idea, but keep looking forward to all your options before making the best decision. Do it in a quick manner, but still challenge yourself to not just go with the most comfortable option.
- In an improv, there’s no script and you’re adapting constantly. You’re seeing what’s happening around you and making the necessary changes to keep the story going forward. On stage, it’s kind of fun and creative, but the same thing applies to real life. New information is coming at you all the time, and you can’t get frustrated with it. You have to accept it and see where it takes you. That whole new information concept goes along with agile, improv, life, and everything that we deal with.
- When you introduce someone new or you take someone out of the equation, the team has to regroup and refine itself. That can be very disruptive, and a lot of people haven’t yet realized. Team efficiency is a big bonus of agile, but you have to adhere to some of those key principles, like keeping the team together.
January 27, 2017 Business Analysis Podcast Transcript
Jacqueline: Hello, good afternoon! This is Jacqueline Sanders-Blackman of Technology Expresso. This is another edition of #AskAnAnalyst with my co-host, Kupe Kupersmith.
Kupe: Hey Jacqueline! How are you doing?
Jacqueline: Doing excellent. This is episode #2 for 2017.
Kupe: That’s right! Hitting our mark. It’s good when you stick with a goal, at least in the first month.
Jacqueline: We’re right on track with the people that set that goal to lose weight. You get through January, then after that, we’ll see what happens.
Kupe: Right. You usually start the show off with asking me questions, but I’m going to flip things around and ask you a question. In our conversation leading up to the show, you mentioned how our show ends up being like agile. I wanted you to give the audience your thoughts on how we act in an agile manner.
Jacqueline: Absolutely. I’d be happy to. I talk about how agile is a mindset, and once you get into that mindset, you start recognizing it in every day opportunities and in business. Sometimes I like to challenge my students that when they leave the classroom, it doesn’t have to be a project, but you can apply the approach, the principles, and the values in everything that you do. Our podcast, just like any other project where you’re trying to achieve a goal, when you understand what the overall goal is, you need that flexibility. We definitely need that on the podcast, because as you know, sometimes at the end of one show we’ll say, “In two weeks, this is what we’re going to talk about.”
Well, how many times has the hot topic within those 14 days changed drastically to the point where we would be remiss if we were to just stick to the plan when really, our overall goal is to bring the latest and greatest information to our listeners. That was what came to mind. We always have to retouch base and rethink up after that two-week sprint to come back and say, “For tomorrow’s show, what is the most important thing to talk about?” We’re kind of doing our backlog grooming, because we always have a topic, but it may not be the most important thing. What do you think?
Kupe: That’s exactly what it is. I actually wrote down our value statement: to bring the latest and greatest to our listeners. That, to us, is more important than laying out a plan to say, “OK, the first show in January is going to be about this topic. The second show is going to be about this one.” We might lay those out, talk about that, and start to prepare in some form or fashion, but in the end, we’re not stuck in any of those topics. The value we want to bring to our listeners is the latest and greatest topics that we think will have an impact on their work. It’s about focusing on value. Even though there are great topics that I want to talk about and that we could talk about, the topics don’t hit the value statement that we have for our show.
Jacqueline: Exactly. It also reflects something that people experience from a business perspective in that as you are coming up with your solution, or in our case, the next episode, the world is going on and things are impacting what people are doing and what their pain points are. There is ebb and flow. We see that in the training arena, in the business analysis area, and in the IT industry as a whole. For example, as people were winding down the year in November and December, there were certain topics that were hot and heavy. Then, when January and February comes around, everybody’s ramping back up and new projects are getting kicking off.
What is important to people right now is picking the right project and focusing on the right project. I’m hearing a lot about that, and I’m also seeing and hearing a lot more about value. At the end of the year, fatigue came up. That’s just an example of how at the end of the year, everybody’s like, “Let’s push this out the door and assess the health of the team.” If you didn’t address that at the end of the year, you’re just going to carry that over in the new year, and it’s going to rear its ugly head again. Once you address that, then what’s next is are we working on the right things. Are we working at the right pace?
Having technology such as Twitter and the #BAOT (Business Analysts On Twitter) hashtag, I follow that and as we’re talking, I can see a wall of the different postings coming out. That’s one way I check the pulse and know what the topics are and what people are liking and replying to. That gives me indication of what is important for our community in this particular time frame. You see different trends.
Sometimes when I say in class that agile is about embracing change, people immediately think, “That’s like working with a moving target.” I would explain that when you learn new information and you ignore it, how smart is that? If something significant has happened or some big announcement came out, do you just ignore it and stick with the topic? When I say it like that, it really makes you step back and realize that it wouldn’t be prudent to ignore new information. Agile lets you react to new information. You running a company see that aspect of talking to clients. I think that’s everywhere and should be very relatable. How would you respond to that?
Kupe: Yeah. Years ago when I was at Turner Broadcasting, some colleagues and I talked about writing a book about business analysis for life. I think you can apply every situation that you’re in to business analysis, even if it’s a process that you and your family have, whether it’s getting your children up for school or planning a vacation. That’s why the mindset is so important. What you brought up made me think of another piece that I think sometimes in agile people have the wrong interpretation, and it’s around documentation.
What made me think of it is you said at the end of the year, fatigue was a hot topic, and we talked about that. At the end of the year, teams are getting tired, they’re trying to get to winter break, and they’re trying to get some vacation time in. Fatigue was a good topic and a good concept. It was something fresh on the people’s minds, but now everybody has reset. You’re fresh, but come mid-February, maybe you’re feeling that fatigue again. That’s why we record all these shows, and we make sure that if something comes up, you can come back to it. It’s on Technology Expresso and B2TTraining. We post all the recordings on B2TTraining.com. That’s the same thing in agile.
For us, it’s like the hot topic today is value, but tomorrow it might be something else. That doesn’t mean value is not a good topic, but you can still get that information. It’s the same thing on agile projects and software development. People take this leap saying, “We don’t need any documentation.” That’s not true. You should think through why you’re documenting something and is it going to be reused later? If nobody’s using the information and you’ve been storing it, then you should stop, adapt, and change. You need to be thinking about what good information is that will help the team be productive and efficient and that can also be consumed quickly. If there’s information like that, then you should document it.
Jacqueline: Absolutely. Your comment made me think, again, about how agile can indirectly be applied to the podcast. Agile also encourages continuous process improvement and continuous evaluations. With that, there are points in time where you may need a little bit more documentation, and other times you may need a little bit less. You might get in a grey area that’s really hard conceptually or has a really complex family of business rules, so you really need to lay that out and visualize it so everybody’s on the same page. There are other areas where you may be a lot more familiar, so you can adjust as you go.
Maybe one area, you did need a lot of documentation, but you don’t turn around and say, “Going forward, all stories have to have a detailed ERD (Entity Relationship Diagram).” That’s when you find yourself falling back trying to make it to prescriptive and methodical, whereas leaving it is just in time and as needed. If it doesn’t serve a purpose at that point in time, then you’re not necessarily using it.
Going back to the analogy of the podcast, there are a lot of times when I’m scribbling on a piece of paper with different ideas. I’m sure you have your napkin or piece of paper where you’re scribbling ideas, and sometimes it’s like, “You know what? Let’s put this in a centralized location so we both can see it and come back to it. Let’s put it in a formal place so we don’t forget.” Formal is just some place we can both get to and can come back around to it. There are times when we’re talking every 2 weeks and in touch.
There might be another phase before we break for summer or vacations. We might need to jot some things down for when we circle back around. That’s something we will talk about as a team and talk about what we need at this point in time. That’s the flexibility I want people to have. Never say never. Never say you never had documentation, and never say that you have to have documentation. That’s my thought.
Kupe: Yeah. The other thing you talked about was about getting new information. I really liked that. We’re not doing our jobs if we don’t accept new information and don’t do something with that. That’s what teams have to get better at: being more comfortable with accepting new information, seeing what that means for them, and understanding the impacts and how things tie together. When you said that, I wanted to bring up the improv piece because in improv, we actually view new information as a gift. We thank people for new information.
In an improv, there’s no script and you’re adapting constantly. You’re seeing what’s happening around you and making the necessary changes to keep the story going forward. On stage, it’s kind of fun and creative, but the same thing applies to real life. New information is coming at you all the time, and you can’t get frustrated with it. You have to accept it and see where it takes you. Now, there’s an art to it, because you can’t get completely off track. In real life you have to make a decision like, “Does this fit with the realm of what we’re talking about?” You have to be open to at least hear the new information and accept it.
Teams really have to set themselves up to hear the new information, because you can easily shut everything down. Your team can get so focused on your project and not hear or see anything else that’s happening around you. You can’t do that, then you’ll never hear the new information. Then your project has the potential of going off course and not being aligned with the goal. That whole new information concept goes along with agile, improv, life, and everything that we deal with.
Jacqueline: Absolutely. Like you said, you thank people for that new information. Just imagine if you really pushed that out throughout your corporate culture. I do an exercise in the Agile Boot Camp, and it’s almost like I give the next instruction and then I count down, “3…2…1” to see whose head is going to explode. I always get a reaction, and I love it. It’s just natural instinct: “We have a plan, and now you’re telling us something new.” I have this scenario like, “We just found out our competitor is going to do X, Y, and Z, and if we don’t do it, a focus group of people is telling us they’re going to move to our competition.” That’s what they have to think about because this is the way the world of business is. It’s good that we have these great lines of communication and instant feedback.
I also talk to teams about how that’s one of the key selling points to product owners. When I hear people talk about how their product owner hasn’t really bought into agile and they just want to give the requirements up front without being involved in the project, my answer surprises them sometimes: “You need to sell it better.” I tell them, “If they have new information that could really provide some type of strategic advantage to their project and if we’re doing 2-week sprints, they’re only 2 weeks away from being able to get that at the top of the list. On the other hand, if we are all plan-driven executing phase 1, 2, 3…”
Kupe, do you know how many old school product owners used to hate when you said, “We’ll put it in phase 2.” I’ve had a company where we weren’t even allowed to use that word. That’s how frustrating it is. I just had to recently remind someone. It’s so funny how people are quick to say “the good old days,” like, “Well, back in the good old days, we had a plan. It doesn’t feel like we have a plan.” When I said, “Do you remember what that plan did to us?” and I give them examples, they’re like, “Oh, yeah.” That’s the reason I’m retiring 3 products that we just wrote 3 years ago and I’m replacing another: because we built the wrong thing. We stuck to the plan, but now I have something to replace. It’s obsolete within 2 years.”
Kupe: Yeah. I think agile is still in the stage where it hasn’t completely gotten to the next level. By getting away from the plan, what you really need to get away from is talking about certain features. To your point, everybody would say, “Oh, that’s going to be in phase 2,” and they would be like, “That means it’s never going to happen.” They try to jam all their features that they think they need into this phase 1, and eventually something in the process breaks. People start working all-nighters and rushing to the end to get projects complete and out the door.
But, that kept the focus on features and functions on the softwares that people were building. What agile does is allows us to change priorities to what the hottest new information is every 2 weeks. What it allows us to do is focus on value. I talk to people about this, and it throws them off. “We have to tell our management that we’re going to do these 10 features, it’s going to cost this much, and it’s going to take this long.” This is why I think teams need to change what they care about from features to value.
It could even come to our show. If we had a topic, and this never happens to us, by the way, we can talk forever. If we had a topic and we were like, “OK, we have an hour scheduled for that topic,” in the old world it would be like, “You’re going to go that entire hour and you guys can keep going to fill up that house.” In the world where we’re thinking about value, it’s really that you keep checking, and even though you planned for an hour, if you’re done in 20 minutes then the show is over. Or we could have a conversation to ask if there’s anything else we want to talk about that will add value.
It’s the same thing for our projects. That’s the whole backlog concept. You have a backlog, and as you finish different features and functions, you need to check if we’re there yet and if we got the value we were looking for. If so, stop and work on something else rather than saying, “We only did 5 of these 10 things. We have to finish the other 5.” No, you don’t, in my opinion.
Jacqueline: Exactly. A prime example of the analogy with the podcast is when we do live shows. To our audience, these are live shows, so you can actually call in. As you said, some of the shows last year we had a general topic, and people called in. You and I kind of gave our opening perspective on the topic, but once you took that first caller, there has been times when the caller was more concerned with a certain aspect of the topic and we would pivot.
It’s like, “OK. I have a client. This is what their question is, and this is the area they want us to dive into. That’s going to be our topic.” That was of much more value than telling them what they were talking about is not the topic and to get off the phone; “We weren’t planning on talking about that. We have a plan. Thank you for calling in.” It was about servicing that need. We were getting real-time feedback from our customers, and we responded to it. Absolutely.
Kupe: Yeah. It takes a different attitude. It goes back to saying thank you. What most people do, and it’s just inherent, like what do little kids learn how to say first: yes or no? They say no first. Even as adults, that’s what we do. We hear new stuff, and we’re like, “Nope. Can’t deal with that.” We’re too busy trying to stick with a plan that we don’t hear that information. At times, you can go with the flow, and especially with our radio show; it’s set up that way. We’re here. We know who our customer is. You and I talk like this all the time when we’re not being recorded, so we don’t have to be on a radio show to have these conversations. We’re know we’re doing this for the listeners.
Jacqueline: Exactly. To your point, there could be a caller that calls in and the topic may be very specific. I can remember someone had a specific project, and it had a very specific element to it. We kind of responded to the general question but said, “We can also touch base offline.” It was like, maybe the topic would take us too far off of the scope, because we do have the general audience at the same time. That happens, too. Sometimes it’s open mic where any topic goes, but sometimes we have a scope of the conversation. Maybe it’s the job search aspect of it or what makes a bad BA. We did that segment and we had call-ins.
That was establishing our scope and our topic, so we had to be true to that for the other listeners to make sure everybody’s needs were being met. That’s what’s also key to agile. Every now and then when I’m teaching a new class, I get deer in the headlights when I say that just because I can write it on a card and stick it on a board does not mean that it’s in scope. There is a process of evaluation, like you said, back to the overall objective and then looking at the value that particular story brings in comparison to everything else that’s there, especially in the realm of the minimal buyable product. It’s the same thing.
It doesn’t necessarily mean someone else can call in and take over the show. We still have to be true to our scope. A lot of times what I say to people is you have to have a scope, just like we have to have a topic. We always have some touchpoint to say, “What, in general, are we going to talk about today?” so that we can have the background information we want to have to allow us to pivot in a lot of different areas. The same thing applies.
Kupe: Yeah. The scope – I think that’s another misnomer. You still need an overall boundary of what we’re trying to hit here. As new information comes in, you can bounce up against that and say, “Do we need to react to this? Does it matter? Can it wait? Do we have something in our plans to address it? Or do we need to expand or change the scope?” That could happen, too.
In terms of a radio show, I don’t think it happens for a show like ours, but for CNN or Fox News, there could be breaking news all of the time. They had a plan to talk about certain segments in the news show, but something happened with the president, a plane crashed, or a catastrophe hit. Then, it’s like, “We have a break here, then we’re going to go to this news and change the total scope of what we were doing.”
Jacqueline: Exactly. One of the things that come to mind for me has to do with the concept of computer science. When I majored in college and undergrad, I majored in computer science. But I sometimes see people in this industry with the mindset that this is a sign that there’s something repeatable that works every time. But, there are soft skills. That’s why improv does have a place in what we do. The whole agile mindset is because every time we’re creating something in IT, it’s a new flavor. It may have some similar elements of the last project, but one of the things that attracted me to it is that I love the change, always pushing the boundaries, and going to new areas. You get to question everything.
What we just thought were the laws and rules, we get to question them, especially if we need to push through, be innovative, and come up with those new ideas to stay on top of things. People wonder why we talk about improv in IT, but it actually does make sense. If you’ve worked on enough projects, you know it works for each and every one. Something that’s important about our industry is people’s mindset on agile projects. We have to accept that we have to think on our feet, and I think that’s what changed about some of the teaching and training styles. They’re no longer about giving you a book, a checklist, and you walk out as a robot following this.
It’s really, which we’ve talked a lot about, the different types of thinking – critical thinking, design thinking, system thinking, creative thinking – putting all those together. You really have to think on your feet, similar to what we have to do everyday on the show. When we take a call, we don’t know what we’re going to get. We have a Rolodex in our head going through, “What do they want to go with this?” We pick it up from there. Your comments on that?
Kupe: Yeah. You were just mentioning your Rolodex. Why improvisers are so good at what they do is because they’re prepared. My troop used to rehearse 2-3 times a week to have 1 or 2 shows on the weekend. That pattern of us practicing, and people were like, “Were you rehearsing skits and stuff?” No, we’re still improvising, but we were putting ourselves in all kinds of situations. We got comfortable with feeling unsure of where things were going to go.
When we’re on stage, we can just relax and be ready for anything that comes our way, no matter what the audience throws at us, what another actor on stage throws at you, or how the audience is interacting with you. There are different types of audiences; some were the classic comedic audiences while others were more cerebral and thinkers. You have to feel them out and adjust on the fly based on what was getting the good laughs and what wasn’t getting the good laughs. It’s the same thing here, but for us, it’s because we have broad experience and have been in a lot of situations that we’re able to just be comfortable, listen, adapt to the questions, and be comfortable answering. That’s on project teams. That’s why it’s going to be interesting.
It’s a similar thing, I think, to kids today who are growing up with cell phones. They’re given a pacifier in one hand and a cell phone in the other, so they’re communicating with people. It drives my wife crazy, because she’ll say, “Find out from your friend when they’re coming over because we’re going to dinner and we want to make sure they’re here.” So, they start texting and Jenny is like, “Pick up the phone!” They’re full on text. I’m really curious, and I’m sure there are researchers out there doing this work, tracking kids now and what the social skills are going to be like in 20 years from them. I’m really interested in that, and I’m also interested in how we’re operating in teams as younger people are joining the workforce.
When they jump on an agile team, I’m wondering where and how they’re going to add the most value. To your point, to be able to adapt quickly, you have to have experiences, so you kind of notice, “This smells like that other project I was on. We tried this and it worked or we did that and it didn’t.” We have these experiences that allows us to be adaptable. Back in the day it was more the development process that you started in one role as a junior, do certain kinds of work, go to the next thing, do certain kinds of work, go to the next thing, and start to build your experiences.
Now, if you get thrown onto an agile team, it’s like, “OK, go for it team. You guys are a team. Figure out what you have to do.” Are the younger, newer folks going to be able to adapt like someone more experienced? Some interesting things to consider. Now, how do we develop those people and not feel like we need senior people all the time?
Jacqueline: That’s an excellent point. I want to continue to talk about the team and bringing young people on the team. That’s a pretty important topic. You asked about the younger members, and even when I have someone brand new to agile in the class, I’m like, “Great!” I don’t have to undo any bad habits. I really feel like just like in the classes, it also works well in the team: having a balance between the old and the new. I see over and over the behavior with those people who had those years of experience that, instead of using it to say, “Here are our possible options,” they’re stuck in, “This is the way we’ve always done it.” Some of it, in my assessment, is a fear factor: the fear of making a mistake.
At any point in time, if you’ve worked in IT long enough and have been on a project, there has been some type of hiccup, especially if you have gotten your hand slapped in some form or fashion. They’re always remembering, “I don’t want that to happen again.” That’s why, from a cultural perspective and from a management perspective, you have to show them, not just tell them, that you are going to be empowered to make decisions. Part of those decisions and learning process is going to be what some people might have in the past labeled as a mistake. I just talked to a group, and someone who is on an agile project right now said, “I don’t like agile because I get blamed for the bugs.” My response was, “I want that to be taken out of the vocabulary.”
Bugs, defects: those are not in our vocabulary. We learn something about the project, so how do we improve it. We learn something – that’s the language I want. Someone said to me, “We can’t take defects out of our language because we always use the word defects. We have defects reports.” I was like, “Get rid of those, too.” You’re just naming off all the other stuff that we have to unravel, because I got consensus from the group on the question; when you hear defect, is that a negative connotation? I said, “Defect is a language of finger-pointing. We have to let it go.” When you keep using old language, people are still in that world of fear, that I don’t want to get blamed for a defect. And where there’s a defect, there is typically blame.
I’m trying to show them the connection between the two. Agile changes a mindset, changes a culture, and changing a culture means sometimes taking some words out of your vocabulary because of the impact they have. Don’t hold onto something because you have a report on it, but report on something more meaningful. Let’s report on something that reports on the agile value. That’s changeable, but you’re holding on to it for nostalgia’s sake. I think all of that has to go into the reprogramming of new members.
To your point, you have old and new operating together, and you have to understand both sides. What I love about the new: they’ll do stuff that is unheard of, but they won’t blink because they didn’t even know that some invisible boundary existed whereas the old team members are still within these invisible boundaries. In some ways, they can balance each other out. That’s something I’ve observed.
Kupe: Yeah, absolutely. Sometimes I tend to think, because I like to flip-flop, that other people are like that. Some people with experience get stubborn with that experience and are like, “No, this is the way to do it. There is no other way.” They get very stiff about that stuff. That’s why I said I like to be a flip-flopper. That’s a confidence that people need. They need there to be flip-floppers. It’s not about you being right, but it’s looking at the situation and saying, “Last project we did it that way, but it’s not going to work on this project so we’re going to do it this way even if on the last project I said that was a bad idea.”
It’s not about one winning over the other; there is not one right way and one wrong way. Paul Mulvey used to always say, “It could be wrong-ish, but there’s not a wrong way to do it.” I think that’s really important to get in everybody’s head. This is why I don’t like best practices. When anybody says to me, “I have the answer,” or, “Here’s the best way to do it,” or This is going to be perfect,” then I’m thinking, “It can’t be. It’s not that perfect.” I’ve never been on a project that has been 100% perfect.
Best practices are best in a certain context, and unless your context is exactly like that and you have all the same people, then it’s not going to be the same. It could be a good practice. You talked about all the different thinking approaches. You have to critically think about what makes the most sense for your project, and to me, that’s an agile mindset.
Jacqueline: Exactly. There’s another thinking style: breakthrough thinking. I love one of the exercises where they have you come up with a solution as a team. They really get into it and the people are invested in it, and then they throw it out and say, “OK, we’re not going to use that one. Give me another one.” The people are stunned and say, “Well, I used my best idea on that one.” They’re not allowed to use any aspect of it, and they have to push harder to come up with something else. One of our 2-day workshops is breaking down user stories. I call it, “21 ways to break a story.” I watch them when they get a story and break it.
Then I say, “Give me 2 other ways you can break it.” The one you came up with may be good, but there might be a better and a best, so look at all your options before settling. What I see people do is find that one favorite way of breaking a story and that’s what they get hung up on and use over and over. They never even question that it may work for one story, but 2 stories later it may be the worst way to break the story. The key to challenging yourself is don’t start with the first idea, but keep looking forward to all your options before making the best decision. Do it in a quick manner, but still challenge yourself to not just go with the most comfortable option.
Kupe: That’s awesome. I love that. That’s a cool exercise to push the team to come up with something really creative then say, “Not good enough.”
Jacqueline: Exactly. And that in and of itself is the teaching moment. Just check your initial reaction. It goes back to what you said even from the improv perspective. For whatever reason, there may be other things in place that you might not know about and that might not be fully disclosed, but at this point in time, that’s not the direction the company can go, so you have to look for a b, c, or whatever the case may be to keep that mindset. Another point when talking about agile and not getting hung up on the way we’ve always done it is even this episode; we usually do our 90-minute segments. We assess the situation, and you pinged me and asked, “What about 60 minutes today?” Let’s go with it and make it work. Again, not getting stuck at, “Well, we’ve always…”
I always wanted to point out that you and I are an agile team, so after a couple of episodes we got the hang of things. Maybe in some of the earlier ones, we did write down points we were going to follow, and then I think we loosened up, learned each other’s style, and now we know. We can fill up time whether you give us 90 minutes or 180 minutes. We can definitely fill it up. We’re comfortable with each other. This is a teaching point I make with a lot of teams: when you introduce someone new or you take someone out of the equation, the team has to regroup and refine itself. That can be very disruptive, and a lot of people haven’t yet realized.
I know agile and how you implement it is flexible, but I’ve just seen it to be true that when you do not have a stable team and you have members coming in and out, being borrowed, and being given additional assignments, you really mess with the heart of the team becoming high-performing. One of the examples is what I call the waterfall behaviors, because we did it so many times in waterfall. People weren’t committed to the projects and were taken in and out, and that same behavior is taken and is brought to agile. Then, you’re going to end up seeing the same symptoms. It’s not a matter of agile. The stable teams, I think, is so important.
Where you and I are a year later doing the podcast, we can relax a lot of us being so formal about documenting a topic, what we’re going to talk about, how we’re going to start the show, and that type of thing. Earlier, we had to get comfortable with that. It’s the same with people wanting to go with lean documentation. That is a by-product of a lot of other pieces that have gelled and are in place with the team, so now you don’t have to over-document and be so specific because you all have now gotten used to each other’s style.
Kupe: Yeah. It goes back to efficiency, too. A lot of people like agile because they feel it’s going to help with accelerating product delivery and with team efficiency. I think that is a big bonus of agile, but if you adhere to some of those key principles like keeping the team together — for us, we had our points, but we would actually meet for about an hour before an hour-and-a-half show to talk about, “Who’s going to kick it off? What are you going to say? What should I bring up next? When do we want to do the breaks?” We had to work through all those things, but now, Tuesday you said you wanted to do a show Friday, and I said, “Sure.” We prepared for the show via text.
For an hour and a half show where we used to prep for an hour, we’re now down to about 5 minutes for the most part. I know we talk at different points in the week, too, so it’s not like we only talk during the show. But, it went from an hour to about 5 minutes of planning, and that’s huge. To your point, we’ve had other co-hosts, and we’ve said, “Hey, why doesn’t someone call in.” We have to take the time to get them up to speed on how the team works, how this works, and how this happens. If you just assume, “Oh, we’re adding another team member but we’re going to keep at the same pace we were before,” then you’re kidding yourself.
Jacqueline: Exactly. I know we’ve had people that came on the show, special guests, who may not have been familiar. We kind of have a cadence, we know how to listen to certain pauses, and that type of thing. I remember one time a guest gave a long pause, and I thought, “Do they know we’re on the air?” But they weren’t familiar with it. We just bringing a third person in and understanding who rotates in next, who picks up after a comment, and that type of thing changes the dynamic. I want management and teams to realize that’s something that has to be addressed.
Agile will actually highlight some of your bad habits that we let slide in waterfall, and you really have to address them and confront them so that you get the full value of agile. That’s where I think a lot of groups are at, now. They’ve dabbled in and have been introduced to it, and in some respects, they don’t realize how to optimize it. It takes continuous process improvement, but sometimes it also takes someone else to interject new focus on how to optimize agile teams. That’s what I’m looking forward to in our upcoming Boot Camp, whether people are new to agile or they’ve been operating for awhile. The Boot Camp is really an opportunity for someone to observe and help fine-tune and point out some of those bad habits. They can also talk about some of those tough things that has been holding them back from getting the most out of agile.
That’s my final comment in regards to this. I’m glad we were able to talk about the improv as well as how it fits into this. Is there anything you want to wrap up with everyone? Also let us know where you’re going to be next, because I know you’re here, there, and everywhere. I’m keeping up with you on Twitter. “Speaking where? Doing what?” But, any final words you have for us?
Kupe: Yeah. Surprisingly, I had a couple of trips early in January, but a lot of my trips don’t kick in until April. I’ll be in Cincinnati and then in Orlando. In May, I’ll be in Des Moines. Springtime is when I’ll be on the road again. I have a couple of webinars coming up with some clients. I’m a big believer in virtual-type stuff. I view this radio show as a virtual medium for us to talk, so I love to do webinars, virtual classes, and things that allow people to be in the comfort of their own home. It’s still a joy to have the camaraderie and learn from other people from around the world. We do need some of that face-to-face time, too.
I just want to end with this flip-flopper, flexible, open kind of attitude. You’re doing yourself and your team a disservice if you don’t keep that open mind. Always be listening for stuff. If you’re on your project team and your team is trying to do X, Y, Z, when you’re reading articles or listening to other people talk, figure out if that might be a way you could adapt your team, change your team, or do something different. When you’re reading a news article about something you didn’t know was going on, figure out if it’s impacting your company at all. Ask if you need to change anything in your team’s project instead of being numb to everything around you.
Last year I wrote a blog called Business Analysis is Not a 9-to-5 Job. The reason for that is, when you’re not working you should still be letting your mind noodle on stuff, and you should always be looking out for stuff. I’m not saying you should be working 24/7, but at the same time, you shouldn’t leave work at 5:00 and say, “I’m shutting down. I’m not thinking about that stuff at all.” That’s all I’ll leave you guys with today.
Jacqueline: Thank you, Kupe. Enjoyed another segment of #AskAnAnalyst. Looking forward to doing it again. Please visit b2ttraining.com, look at our public schedule, and/or reach out if we can help you in any aspect of business analysis, agile, improv team building. Thank you for listening. Bye for now.
If you have a question or comment, call 855-484-6837, leave a message and we’ll read it on our next episode. Also, please visit our Tech Expresso Cafe page on iTunes for this and other series!
Please enjoy our other episodes:
- Episode 1 | December 8, 2015: Podcast launch and general overview of business analysis today
- Episode 2 | December 22, 2015: 2015 in Review and Set Your Expectations for 2016
- Episode 3 | January 5, 2016: Your Business Analyst Career Path
- Episode 4 | January 19, 2016: Business Analysis Role Fits in Many Careers
- Episode 5 | February 9, 2016: Overcoming Business Analysis Project Failures
- Episode 6 | February 23, 2016: Good Business Analyst vs. Bad Business Analyst
- Episode 7 | March 8, 2016: Business Analyst FAQs
- Episode 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: Back to Business Analysis Basics
- Episode 18 | October 4, 2016: More Business Analysis Basics
- Episode 19 | November 3, 2016: Live from #BBCCon
- Episode 20 | November 15, 2016: Effectively Give and Receive Feedback
- Episode 21 | December 8, 2016: Business Analysis in 2016
- Episode 22 | January 10, 2017: Business Analysis in 2017
- Episode 23 | January 24, 2017: Is Agile a Methodology?
- Episode 25 | February 7, 2017: State of Agile
- Episode 26 | February 28, 2017: Are BAs Becoming Obsolete?
- Episode 27 | March 23, 2017: Remote Agile Team Success