Kupe and I are excited to be celebrating our #AskAnAnalyst’s one year anniversary! We officially made it an entire year! And, I hope you have not only enjoyed our conversation but have also learned from our experience and stories. In celebration of our year mark, we are going to look back and reflect on what happened and look forward into 2017.

Episode 21 | December 8, 2016 Business Analysis Podcast Transcript

Jacqueline: Hello. We’re here: 1 year later. This is Jacqueline-Sanders Blackman of Technology Expresso here with Kupe on #AskAnAnalyst, the one year edition today, Kupe.

Kupe: I know. Happy Anniversary Jacqueline!

Jacqueline: We made it! We probably need some therapy, but we made it through.

Kupe: We’ve had our ups and downs. Mostly ups, though.

Jacqueline: Yeah. And most of the downs were technology. We have our bloopers. I’m sure we could do a blooper reel here. It’s really exciting and engaging, and I feel like I’ve grown from our conversation.

Kupe: Absolutely.

Jacqueline: It has just been a thrill. Being interactive and having people call in. It has been a great 1 year. Hello to all of our listeners and followers. We’re going to have some people who are going to join us, some that have been previously on the show and some first-timers.

Kupe: I know. I’m excited.

Jacqueline: We’re going to do a recap look at what we were talking about a year ago as well as what our predictions are for 2017. We have another call who has joined us. We want to say hello. We’re going to be speaking with them shortly. The exciting part is, we’re going to give you our predictions, but someone can agree, disagree. That’s perfectly fine.

Kupe: Yeah. Actually, we want to know — at least I do; I don’t know if Jacqueline feels the same way. We love a good debate, and I think the way we learn from each other is by challenging each other and pushing each other. I think that’s what we’ve done over the last year. The two of us have had conversations with people who joined in, and I’ve gotten good feedback from some of our consistent listeners out there saying how much they enjoyed the show and this format. I’m just glad that we can continue it and do another great year.

Jacqueline: Absolutely. I’ve grown from it, too. It’s great to have the conversation. One thing bout the field we’re in: it’s forever changing. What’s true last year may not be true this year. It’s not about right or wrong, but it’s: learn, adapt.

Kupe: Right. What’s next. How do you push yourself and keep growing?

Jacqueline and Kupe: Absolutely.

Jacqueline: This is our world. Kupe, we have people who are here at the top of the hour to hopefully talk to us and to share with us. I’m going to go to the line. Hello.

Pam: Hope I’m prepared for this.

Jacqueline: You are live.

Pam: I was just going to share with you this type of work we’re doing here in 412.

Kupe: Is 412 not just an area code, it’s an attitude.

Pam: The attitude is right. That’s exactly it. It’s a Pittsburgh attitude.

Jacqueline: A state of mind.

Pam: It is a state of mind, definitely. I have a couple of us here: Lisa, Rick. We are all working in a quality insurance area looking at people’s deliverables and learning a lot about what’s going on inside of the banking industry. In our findings, we’re finding that — and Kupe and I had a conversation about this earlier — a lot of packages are being purchased in the banking world. We’re trying to understand how the requirements are written from a package perspective. Talking more about a big discovery here was the fact that there was this new requirement called transition requirements. We’re doing a lot of educating people in terms of what is a business requirement vs. a transition requirement. These are the conversations occurring here.

Kupe: I was talking to somebody the other day, and I apologize for getting who it was. He was saying that a lot of people think nonfunctional requirements are the ones that get missed the most, but in his opinion, mine too, and obviously you guys are saying this stuff, that transition requirements are the ones that often get missed. Once we have the package and we’re ready to turn it on, how do we make sure people are trained? Everybody’s ready for this change and can accept this change? I’m glad you guys are focusing on that.

Pam: Yeah. Nonfunctionals, too, are another area that people have a lot of difficulty with, in our experience.

Jacqueline: Absolutely. What I want to add to that is, like you said, and it’s very interesting getting this different perspective from different industries. That’s one of the things we talk about: there is not one way. Different industries vary, and then I’ve seen it within different organizations. They go through the trend, whether it’s buying package or doing in-house. Sometimes they flip-flop back and forth. One of the things is that there are still some of those key components, those core components, that are true to either of those methods. That’s where the business analysis and the transferable skills come in. You just apply them in different ways.

That’s where, something we’ve always talked about, the critical thinking. People sometimes just want to have this step-by-step: do ABCD. We kind of talked about this a little bit. What I’m seeing is that the classroom has to go beyond just training and prescriptive to these workshop-type atmospheres where you show them and then you let them get in the lab and feel it out. They’re going to be on the ground having to make those decisions, make some critical analysis, and come to their own decision about which one to use at which time.

Kupe: Right. That was something we talked a lot about on our show a year ago. I’m sure we talked about it throughout the year, but a year we talked a lot about critical thinking as being that key skill, that overarching skill, that analysts need to be successful. Every project is a little different. Even if you’re working on a package software A and package software B, that the people you’re dealing with, the project’s risks and timelines, all of that is different, so you can’t do a prescribed process.

Pam, to that point, with you Lisa and Rick in Pittsburgh — I have to say I’m a little upset about Pittsburgh right now because I’m a New York Giants fan. You guys kind of put a whooping on us, but let’s not bring that up. The critical thinking aspect of stuff around the package softwaring, you guys are in this QA role kind of reviewing deliverables, processes and stuff. Are you seeing that teams are adapting their product?

Rick: The situation I think we find ourselves in, because as you probably are aware, in the banking industry, and this is the case with many industries, it’s very highly regulated. What we’re trying to figure out is a balance between what the regulators are asking us to do and what makes sense for the business. I quite honestly think we’re sorting that out. We’re getting there, and we’re making some stride. I think that the end users of our process, the people we’re assessing, in a way, we’re trying to be collaborative with them; we’re trying to understand the perspective that they’re coming from, and working within all of the requirements that have been put upon them to come to a happy medium.

I don’t know if they actually have the ability to execute critical thinking, yet, because they think we’re kind of evolving our quality insurance process a little bit. But I’m confident, given what we have experienced with the project managers, that they will be able to do that. We’ve had very good feedback from the project managers, and we’ve had really good success with the program in general. It’s pretty new, what we’re trying to do. It’s about 6 months old.

Kupe: No, that’s great. And the fact that you guys are critically thinking by saying, “What are the regulators’ wants/needs? What makes sense for the business and how do we fit,” rather than saying, “Oh, we’re only going to deal with the business’ wants,” or, “We’re only going to do what the regulators say we need to do.” It’s finding that right balance. Thank you guys for calling in! We have some other callers and some other topics to get to. Big thanks to Rick, Pam, and Lisa all the way from Pittsburgh. Go Giants!

Jacqueline: Absolutely. Kupe, I know even from your perspective, this is our first anniversary, and you looked back on some topics from our first call. This one, we’re talking about critical thinking and where things are going. What we’re we talking about a year ago?

Kupe: There were 3 things: critical thinking, collaboration, and networking was the social side of being a BA. We also talked about how the spark of it was STEM. We were talking about how learning about math, technology, and science in school helps you become a better BA. We talked about how it helped me. I went to college as an accounting major, and that had helped me be a better analytical thinker. It’s interesting that Rick talked about their collaboration, because that’s what we were talking about last year. The way BA’s need to operate, it should be a collaborative effort.

The shirt I’m wearing is the B2T shirt we wore at the #BBCConference, and on the back it says ‘analysis is a team sport.’ You always said requirements is a team sport, and that’s what it is. People in this space need to know that they’re not out there on an island, and they shouldn’t act like they’re on an island and doing their work alone. They should be collaborating with other people, understanding what they need, and then going out and finding the right people to give that information.

Jacqueline: That reminds me: one of the students today in a follow-up call to one of my classes said that our class helped lower her blood pressure. She was thinking it was all on her shoulders, and then we gave her permission, saying to use your whole team and get them all engaged. I think this is one of the big revelations, one of the big takeaways from 2016 going into 2017, is that it’s not just about sending a business analyst to a business analyst class.

Even people sitting in the room, she had spoken of how one of the other, it was a tester, like Rick was saying in his area, that she realized, “I see I can be helping you more. I see ways I can help you.” Sitting through an analysis class, and now she said the whole team is working together. Her blood pressure has come down, and they’re being more cohesive. It’s just a much healthier environment. People were asking about those shirts at the conference.

Kupe: Yeah, they wanted to buy them. I think we still need to do a mass production and get them out there.

Jacqueline: Yeah. Stay tuned! 2017 get your B2T “analysis as a team sport” shirt. Stay tuned for that!

Kupe: Yes. And there was another one of your classes, I was looking at a survey from a class you taught recently. There was a developer in the class, and his comment was, “I’m not going to use this stuff day in and day out because I’m the developer on my team, but it has helped me so much to understand why the BA is doing what the BA is doing.” It helped them be a better team member by helping the BA, and it even helped identify, “Hey, there are gaps in certain things.”

Jacqueline: Absolutely. Speaking of, Pam I’m going to open up your mic real quick because you also teach around analysis and that type of thing. As an analyst, how do you feel when you have a class with other people in other roles? Like you said, you guys are in the QA role. How does understanding the analysis piece help people in the various roles in IT from your perspective and experience?

Pam: Just understanding their involvement in this. Understanding that they’re going to be the recipient of the requirements as the QA person, and they’re going to be responsible for ensuring that they are correct. We are working with the entire team. We’re working with the business areas, and in particular, the project managers and understanding their involvement with ensuring the timing of all of this and ensuring we’re meeting the needs of the business. We are dealing with an awful lot with our quality insurance work. Just appreciating how important those requirements are and how they are passed.

Some of the stuff I worked with in particular last year was just understanding what I’m responsible for as a business analyst: what I’m responsible of giving to the people that will be coding from this. What do they need in order to do their job. I struggle with that constantly, and it’s like, I can produce anything you want, but what do you need in order to do your job better. I guess that’s a lot of what we’re seeing regarding the teams. Is each area developing something useful for the next area to work from whenever we have a team that we’re working with.

Jacqueline: Absolutely. I want to elaborate on what Pam said. When you’re communicating to understand what it is you need, that’s how you get to lean requirements. It’s not arbitrarily, “We don’t need this,” or, “We don’t need that.” What I think sometimes happens is you have to oversee documentation because you have to get what you might need or might use and that type of thing. If we’re having a conversation, “Did that work well for you? Did that not work well for you? Do we need as much here?” Then, I’m all about the lean documentation, but just make sure the recipient, as Pam mentioned, is in tuned with what you’re slicing and dicing and understanding how they’re using it. It’s about understanding the recipient.

Kupe: Yeah. We’ve talked about lean business analysis, and that’s kind of been my mantra over the last few years: business analysis is about facilitating decision-making. This is how the concept folds into lean analysis and exactly what you’re saying. If your role and your goal is to help people make better decisions and one of those decisions on the project is what’s the problem or opportunity we’re trying to go after. You have to do analysis to help people get to that decision. The only analysis you do is the analysis that helps them get to the decision. How do you know that?

You have to ask them and talk to them: “What information do you need? What do you want? How can I help you make that decision?” And then that’s the analysis you do. If they can make a decision, you’re done; don’t keep analyzing it, and don’t do things just because you think it should be done unless the recipient, the consumer of this stuff you’re delivering can use it to help make a decision. Lean business analysis, decision-making: I think that’s the next generation 2017 looking forward. If people have that attitude, that mindset, and what you and Pam are talking about, then you can start really adding value to your teams.

Jacqueline: Absolutely. We’re back to our old selves. It reminds me of how our conversations used to go; you’ll say something and then it triggers something in my mind. One of the things that it triggers in my mind, too, is that now that IT has been around for 30 years or so and business analysis has been around, it’s very interesting to me that every year I’m always learning. I’m a lifelong learner; I’m always learning something new, whether it’s from students or from the consulting I do. I don’t like to just talk about it; I do it.

Kupe: You need to live it.

Jacqueline: Absolutely. But one of the things that I’ll say is that, as someone who has been doing business analysis for 30 years and they’re doing it the same way as they was doing it 30 years ago, let alone 2 years ago. I say this to people who have been doing agile for maybe 10 years or so: agile is known in its adolescence, now. If you’re doing it the same way you did it 10 years ago, then that’s a problem in and of itself.

Kupe: That’s not being agile.

Jacqueline: Exactly.

Kupe: They’re not learning and adapting.

Jacqueline: It’s continuous process improvement, so you need to have your eyes and ears open. Maybe I’m preaching to the choir, because the people who listen to our podcasts, these are the people who are looking for what’s next. We can look back at 2016 and some of our comments in 2016 can be taken into 2017. But, the word has to get out to a broader audience, that if you’re doing business analysis the same way or you took that one course and you’re good. We have to keep up with that curriculum because it’s changing, the energy is changing.

Kupe: Yeah. The environment has changed. How people are performing the role. All that is constantly moving. I think the lifelong learner piece is critical. Years ago I wrote a blog and a presentation around what it really means to be a senior BA. Actually, Heather Mylan-Mains, another one of our colleagues, wrote a similar one recently. In mine I was saying that a senior person isn’t somebody that has been doing the same thing for 10 years. You have to have a breadth of experience, and if you haven’t adapted your ways, then you’re senior in the sense of years of experience but not in your experience.

You can’t keep going through the motions; you have to always be looking around and figuring out. I think that’s the critical thinking piece. It’s the same thing on your projects. Just because you did a project like this and it smells just like the last one you had, that doesn’t mean you do it the same way. Maybe there are some things you do the same; we’re not saying always change, but you have to at least go through that thought process.

Jacqueline: Exactly. Whether people call it critical thinking or not, there shouldn’t be a day that doesn’t go by that — this is the thing: we do analysis on projects, the problems, and the solution, but you should be doing analysis on the work that you’re doing. Your contribution, how you’re approaching it, how you’re approaching your stakeholders and that type of thing. I can remember, and I’ve been saying this for a while. We don’t use the ‘A’ in BA enough.

Kupe: Yes, exactly. And it’s funny because we sometimes don’t use the ‘B’ enough. We just use, I don’t know, the ’S’ around solutions, or systems. That’s what we focus on, so a lot of people are BSA’s vs. BA and they just use the letter in the middle and not the ‘B’ and ‘A’ enough. And hopefully they don’t just use BS too often.

Jacqueline: Right. The thing is, I do see it maturing. I definitely see that there are more people who has now been doing it for a while. Sometimes you have to do it your way, and then once you start feeling the pain, then you circle back around and say, “There has to be a better way.” There has been. I tell people when they’re embarking upon business analysis, “You have 30 years worth, now, of experience and lessons learned.” The dark ages when there were true business analysts, we kind of did systems analysis. When I do my introduction I talk about how when you talk with a user for about 30 minutes, you start decoding. But, this is, once again, when they were using green screens and spreadsheets.

Now, we have a much more mature audience, so why shouldn’t what we do be more mature: our conversations as well as our technique. Then the other thing is, technology has made the world speed up, and at the same time, what I like to emphasize is being busy doesn’t necessarily mean being productive. We have people who are trying to move really, really fast and get things done, but if you find yourself backtracking, then you’re not really making progress; you’re just spinning in circles. That’s where maturing your approach to doing the analysis up front, because we’ve been saying for who knows how long that doing the planning up front —

Kupe: Is going to save you. Right. It might be confirmation bias on my side, but that was one of the notes I had written down about 2017 and where some of the focus is. Just more and more people I’m talking to are agreeing that the focus is less on — even on agile teams, and you write a lot about this so I’m not going to go to it in detail, but on agile teams, they’re doing a better job, now, at getting stuff done. To your comment, they’re busy and they’re getting stuff done, but are they getting the right thing done.

I think that’s the big focus and where the switch is happening, where it’s not just about working more efficient as a team, but it’s working more efficient as a team and getting stuff that customers really want to use. Up until this point, some of the surveys that are out there still point to how customer satisfaction is still not the highest priority, or when it comes to IT and technology, there is still too much technology driving some stuff and not the business wants and what the business can really use to excel.

Jacqueline: Absolutely. To your point, sometimes I even say in my agile class, “Agile can help you build the wrong things really fast.” It’s not necessarily getting to that minimum buyable product. When we first talked about agile, MBP wasn’t in the conversation. Now, I don’t have a conversation where it’s not MBP. Let me jump back to Pam for a second. Pam, talking about lifelong learner and evolution over time, you recently actually took a class. Talk to us about some of the new things that you’re introducing to your repertoire and what came out of your class.

Pam: I believe it was an agile class. Yes, it was an agile class.

Kupe: It wasn’t the dance class, Pam, that you took?

Pam: No, I didn’t do well. But I will talk about my scrum master class, actually. It was very, very good. I attended it in Columbus, Ohio. Very eye-opening to me. I now understand the terms. I definitely learned all the agile terms. I can’t wait to try this, frankly. In this past year I reviewed a lot of agile projects. I don’t know how good or bad they were, but I’ve been exposed to agile in that way, in doing the quality insurance check. I had a fabulous teacher.

The young woman was excellent, and I’m really looking forward to getting on an agile project and using the skills. I have an understanding of the development team, I now have a better understanding of where the BA’s fit in this world, where the development team fits, and how the QA is part of that development team. As I said, I have a better understanding of what a scrum master’s role would be on an agile project. I’m very, very intrigued by it and really anxious to get on an agile project and get involved in the work.

Jacqueline: Absolutely. I’ll piggyback my continuous process improvement. This year I got my certification in SAFe approach and the scale of agile framework. I, myself, like Pam, am getting exposed. The thing is, it’s very different when you still have that foundation of the business analysis, and now it’s mapping and finding its appropriate application with these different approaches. I tell people in my class that you can take agile, you can take scrum, you can take safe and all these various different approaches, which are wonderful planning tools.

Even when you have a backlog, for example, if you don’t know how to do your analysis and if you haven’t done your scope so that you have those boundaries, you can just have a random backlog. You can work on a lot of things really fast that come together and mean nothing; they don’t have value. I’m adding to my list as we go along.

We were on top of this awhile ago, but I really see this carrying over to 2017. I tell students it’s less about requirements management and it’s more about value management. When you keep that focus on value management, you really start seeing, back to what we said, the ‘A’ in BA coming out. That’s when you’re going to get the most out of your business analysis. I think some organizations, if you’re just using your business analyst for requirements management, you’re not getting your money’s worth. Use them for helping with that map and that value management.

Kupe: Yes. Tell me if this is along the same lines that you’re thinking: requirements management vs. value management. I was having a conversation with someone, and my comment to them was we have to focus less on the number of features that you promised to a group than on the outcomes that you’re looking for. She’s like, “What are you talking about? At the beginning of a project, we have to say, ‘We’re going to do these features’ and if we don’t implement them, then that project is a failure.” I’m like, “No it’s not.”

If there were 10 features you thought you needed to get to the value or the outcome that the business needed at the beginning, once you get to the 5th one, you realize, “We’re 95% there. It doesn’t make sense to do the other 5.” That, to me, is success, so why keep going with the other 5 features and get these loaded systems that aren’t adding value to the organization? Is that the same thing?

Jacqueline: Absolutely.

Kupe: Good.

Jacqueline: And you know, I’ll tell you one thing that I still see being repeated. It’s like, there are too many examples of where this doesn’t work. I hear people say, “I have a legacy system. Right now we’re in 30 years of —“

Kupe: Right. Of stuff.

Jacqueline: “I need to replace it, and I want everything that’s in that legacy system.” I feel like we keep repeating this. If you’re doing business the same way you did 30 years ago and you need every one of those features. Prime example: 30 years ago, everything was a report. You printed it out, you had hard copies, and you had copies upon copies. Nobody’s doing reports. You don’t have to, because we got these great dashboards where we can drill down, slice and dice, and these different tools. Why are you saying that? They do that and they just skip over analysis and say, “Feature for feature. We need that.”

Kupe: It doesn’t make sense.

Jacqueline: It absolutely doesn’t. And then they get several interim breaks into a project. They come to find out, “This was obsolete. This wasn’t really necessary.” Then, they’re having a conversation. Agile in any type of project like that: time out and let’s do a reset. Now we know that our theory about having to have every feature gets thrown away. Let’s do a timeout and do a reset. Sometimes they’re just not ready to hear it early on, but again, we love the analogy about building a house. If you move from one house to the next house and say, “I need this same exact house,” no. For example, when you move from one house to another, your lifestyle. It may have been 10 or 20 years ago when you bought that other house.

Kupe: You have 4 kids right now, they’re out in college. This is my mantra, and I find ways to fit everything into this. It’s about good decision-making, and the people making that decision need to have more facts to say, “Just take the legacy system and copy and put it into a new system.” They need facts to determine if that is the best choice and a good decision. They think it is because they think, “Oh, it’s easy. We don’t have to spend time analyzing anything. Just feature for feature. Just redo it. Giving them more information around, “Well, what if there are features that aren’t used? Do you care if we spend money on implementing that?”

What if there are big pain points that people are screaming about? Why build it the same way? Now, they have a new system, but it’s the same thing. Even giving a great example of a way to do that: is there an app on your phone that you don’t like? “Oh yeah, I wish this app did this, this, and this.” Well, let’s say it’s now out-of-date. Do you want them to just create the same app with prettier colors, or do you want features to be improved and stuff like that? It’s about analysis.

This is probably another show, but as you’re saying this stuff it’s making me think that to do this work and to do it in an expedited manner, which is what people need, you have to have experience. There’s a lot of people in the profession that just don’t have a lot of experience. They’re just new to the profession, and they don’t have a lot of experience. It’s really hard, and it is frustrating. You talked about it with that student in class; her blood pressure was raising, right? I would assume there are a lot of BA’s out there with blood pressure that’s really high because they don’t have the experience that you have but they’re being asked to do these types of activities, and it’s difficult.

Jacqueline: Absolutely. And I know Pam and I have had this conversation, too. Some of this has gotten lost in translation, because, early on, I remember conversations about agile. They talked about well-performing teams. They said, “Put your top performers on these agile teams,” and that includes people with analysis-like experience. This is something I also talk about in the Agile Boot Camp: being able to move at that pace, sustain it, and stay healthy and not just burn everyone out.

I have people who are doing agile, but I know 6 months from now we’re going to be getting  a call back because people are going to be leaving your team burned out and not even wanting to hear the word ‘agile’ anymore. I just recently talked to someone who said that they were leaving an organization in order to get off an agile project and that they were looking for anything but an agile project.

Kupe: Because they had such a bad experience? Why?

Jacqueline: I was like, “You haven’t even —”

Kupe: Right. It’s not being done well.

Jacqueline: Right. Don’t take that way as the only way to approach agile. It does take those people who all come with their area of expertise. The luxury of doing those sprints is because you’ve done that baseline that traditional BAs and BAs that have been doing it long-term. It’s like, if you want to sustain a stake that has 2-week iterations, then you have to do the foundational things; the iterations 0. I can remember doing them under the cover when I first started out. I remember pairing up with another BA like, “What are you doing,” and she’s like, “I do the same thing.” I still do my context.

I still do my decomp. I just keep it at a certain level, I keep it informal so that when that just-in-time conversation comes up, I can pull it out. If you want to know how to prepare your BAs for an agile environment, you have to get them to that baseline and those basics and look for someone who has that experience and practice to coach the rest of the team. Look at your business analysts not as the only people who does the analysis, but they’re the ones with the expertise to coach the other team members: we need to ask this question, have this conversation, make sure we’re all on the same page. That type of coaching.

Just completely taking the analysis piece out of the equation. I call it ‘random acts of agile.’ You’re doing the ceremonies and that type of thing, but it can’t be blamed on agile. You have to have those high performers on that team that understand their particular disciplines.

Kupe: Yeah. And I think the reason why you create that context diagram, your functional decomps and all these great analysis tools that have been out there for years and years, so you can quickly see impacts. When you’re looking at a story, which is a small chunk of information, well, if we implement it in the way we’re talking about, what is it going to impact? That, to me, is where all the value comes in with analysis.

You understand, “If we do it this way, what can it impact? Do we still want to do it that way?” Using all those analysis pieces and techniques and having them available to you allows you to understand impacts. It’s about decision-making. I do this all the time. I’ll be like, “It’s all about decision-making,” or “It’s all about communication.” But, it’s all about impact analysis, too.

Jacqueline: Absolutely. I feel that business analysts will find agile to be more rewarding ts they start seeing agile being performed in a mature manner. In waterfall, even though we had this step, this milestone, or we had to do requirements, it still was a lot of documentation. That was the focus. Now, in an agile environment, like you said, you’re having to negotiate and help make decisions everyday on the fly. I tell people, “I walk into my agile each morning to determine who or what is the hot topic that needs to be flushed out.” I call it ‘on-the-fly facilitation.’ You will get much more.

The great thing, like for Pam who has the business analysis background and is now taking the scrum master training, I’m sure it’s just natural to try to see how scrum masters need to support the analysis on the team. I even see where scrum master needs to take sort of an overview to see how analysis fits into agile, because you’re not going to find that in what I call your vanilla agile course. It’s going to teach you how to be a scrum master, but now circle back our way, what I mean by that is B2T Training, to have a conversation about, “How do I get the right amount of lean analysis?”

Kupe: Yeah. To me it makes perfect sense. You have this evolution that has happened. What you first have to do is get people bought into this new way of operating. That takes time. Scrum seems to be the main one that has popped up as far as approach and how an agile team operates. Safe. Other scaling type things are coming in. Once they get a feel like, “I basically get that structure,” now it’s coming back to, “We have the structure. Our team is more efficient at putting out stuff nobody wants, so now what’s that next evolution of improvement?” And that’s around analysis, requirements, and making sure we’re working on the right thing. That’s why I think 2017 is a really big year for that.

We talked about this on another radio show. The Agile Alliance Conference that was held in Atlanta this year, Agile 2016. The concept of agile being a mindset was a huge, huge push. Getting away from, to your point, just being scrum and all the ceremonies that go along with that. It’s really, “What is the mindset?” One of the big mindset pieces, and you’ve been saying this, is around value. How do we ensure that we’re doing things that are valuable to the business? And that’s analysis. That’s the stuff we do. That’s why we’re trying to help teams and individuals around the world get better at this.

Jacqueline: Absolutely. I just want to welcome our audience. Again, we have several people joining us. It’s Kupe and Jacqueline here on our 1-year podcast anniversary, so we’re kind of looking back at some of the things we talked about a year ago. We talked about some of our experiences, and then also we want to talk about some of our 2017 predictions. We want you to also join in, chime in. We would love to hear from you and talk to you. Whether you agree or disagree. We want to hear your experiences, your projects, your experience with agile. Is the industry going in the right direction? Are we hitting on the right areas of improvement? Are Kupe and I hitting on the right topics? Are we talking about the pain points that you’re experiencing in your world?

Rick has joined us, along with Pam. Rick, I would like to open up your mic and just ask you. We’ve been talking about how the business analyst role has been evolving and changing. Not just during the last 30 years but in the last year. Rick, I think you come from a perspective of testing and QA, if I’m not mistaken. I’m really curious to hear what you’ve seen and if it has had an impact in your area, or what’s the big impact to the area that you work in?

Rick: The topic of agile is certainly one that we’re wrestling with right now. I’m not sure if there are any set standards that we are repeatable across organizations that you go to. When you walk into an organization that’s practicing agile or is starting up agile, I think the first thing you have to understand is how that organization started up their agile program. Then, from there, you can start to apply some meaningful or reasonable quality storing requirements.

One of the paradigm shifts maybe that quality insurance needs to go through, it goes back to what you were saying about this collaborative nature. Making sure that we’re doing what the regulators were asking us to do, but at the same time, we’re very much aware of what the business has laid down as their foundational practices.

I was talking with Pam and another colleague a couple of days ago. I was showing them an IEEE standard, because from a quality insurance perspective, that’s usually where I go to have an understanding of what the industry accepts as the best practice. There’s an IEEE standard out there that talks about documentation in an agile environment. There’s very little prescription here in terms of what absolutely has to be done. Backlog, foundational documents like user stories and use cases. For example, a couple of minutes ago you talked about context level diagrams and things that are more technical in their representation of the system.

I’m not saying that it’s not important to document; I think it’s very important. However, in this IEEE standard, it talks about high-level design proposals, ad in parentheses, it says, “May not be needed for agile development.” You read that and you’re like, “Ok. If an organization decides they don’t need to do that, then we can’t prescribe that from a QA perspective.” That’s the paradigm shift, I think, Jacqueline and Kupe. And you can’t just force a certain mindset. You first have to learn, collaborate with the group, the business, and then partner with them and move forward; try to keep the regulators at bay as well.

Jacqueline: Excellent.

Kupe: I want to jump on a couple of things that Rick hit on. I’ll get on my soapbox about best practices and that I don’t think there are best practices, but I think there are good practices in certain environments. I think, Rick, that’s what you were talking about. You have to understand the environment and the culture and then figure out what works best. I don’t follow IEEE stuff like you do, obviously that’s something you utilize to do your job. I didn’t even comments like that were written. I think that’s perfect.

The beauty and curse of agile is that, yeah, there are certain things and certain foundations like user stories, if you have a scrum approach, retrospective, stand ups. But, in the end, it comes down to what’s going to make sense for the team. That’s why I go back to decisions. If something is going to help make a decision, then do it. That, to me, is being agile. It’s being lean. It’s thinking about what’s the most efficient way to move forward and get to a good answer and a good solution that people want to do something with.

Jacqueline: Absolutely. We’re going to have Rick back because there’s a whole —

Kupe: He’s a soft talker, but a lot of deep knowledge we have to unleash and get out of Rick.

Jacqueline: Yeah. Because, he has a point, that you have organizations, and him being in QA, that’s trying to balance what the regulators are saying. IEEE and agile is new, so anything that they’re writing now, what is the foundational base that they’re writing it on. One of the things he said early on is that agile would differ by organization to organization. I would even say it’s project by project and team by team. Even from the same team, a different type of project.

Back to that critical thinking. Not doing something for the sake of doing it because it’s colorful agile. I’ve had people who have passed my classes and say, “Someone went to agile training and they said . . .” I tell them, “They don’t own the word agile. Check the manifesto and then let’s work from that place of really trying to understand the spirit of what we’re trying to do.”

Kupe: Those key principles. Right.

Jacqueline: Exactly. And not saying, “Agile is agile.” I completely agree with him. Just on the same token where IEEE says you don’t have to do the context-level diagrams, some might structure a high-level diagram and some might turn around and say, “Well, we never have to do that because I read here . . .” But, on one project, you don’t need to do it. It’s overkill.

In our class I was like, “How many different external agents do you have?” They say, “I only have 2.” Well, ok. I’m like, “Let’s decompose that; do you understand what we’re trying to accomplish here? Ok, we’re good to go.” It’s something else when you tell me you have 4 or 5 external agents. I say, “Let’s lay this out and let’s make sure we haven’t missed.” It’s a case-by-case scenario. I want to say hi to a few people while we have them on the line. We really appreciate people dialing in.

Cassie: This is Cassie. Can you hear me?

Jacqueline: I can hear you Cassie!

Cassie: Thank you. I’m a colleague of Pam Swent. She asked me to call. 724 is right next to 412.

Kupe: I think you guys did this on purpose. You guys are probably wearing black and yellow. Thanks Pam for getting all your Pittsburgh buddies on the line.

Jacqueline: She has the whole team here. Excellent. Thank you, Pam. Cassie, so you’ve been hearing Kupe and I banter a little bit. What are your thoughts about the year and this whole space? Any big lessons learned for you?

Cassie: I would certainly echo what Pam and Rick has already said. I have almost more than 30 years of experience in this area. I think that part of what happens with change, and it seems like change is happening more quickly in the last few years than it had before that it certainly depends upon the type of institution that we’re working with. If we happened to work with a technology company, it seems like there might be a different and quicker way to approach these types of things. The place where I work, in banking, banking is a financial institution, so that’s their goal.

But IT is important, so bringing along the IT function within another industry is tough and sometimes a little bit more problematic. The biggest challenge is we need to make sure that we have the lines of business within our companies on board with us and that they start to become integral to projects, even IT projects. I think agile is one of the approaches that will actually do that, because they’re saying we need everyone on board that has an interest, a message, or an input into the process that we’re trying to build.

Kupe: Yeah. I think, Cassie, whether you’re doing scrum or anything else: if the business isn’t involved. I think there was a point in the 80’s and 90’s. There were IT projects that got pushed from IT, like we have to get off pen and paper and let’s implement PeopleSoft, SAP, these big ERP applications. Some things were driven from IT to make that happen. I think now, it’s a complete, or it needs to be the complete opposite. The reason why the groups that you guys work with in your organization, it’s an IT organization but your company is a bank, so you’re there to support the bank in the lines of business.

If they’re not involved in the day-to-day and some of these decisions that have to be made about what is valued, then it just doesn’t make sense. IT shouldn’t be driving that. Even the best BA’s, unless they truly are the subject matter expert and they’re in the business, they don’t know the business as well as the people who are in the business. They have to be part of that conversation.

I was on a call yesterday with a client. He was asking if we had some services to help their BAs work their business stakeholders to improve helping them elicit and get out what the real value is that the business is looking for, and not just have the business say, “Well, what’s your opinion? What do you think we should do?” Just like you guys, they’re kind of a third-party package, shop, or on the shelf. The business line kept asking the IT team, “What do you think is the best product,” and they’re like, “Our opinion doesn’t matter as much as yours.”

So, what’s most important to you? What are the things, the capabilities, that you need out of the system? Then, we can help show you the differences between the top 3 we picked out that we thought might be a good fit. It’s really ingrained in the business. That, again, and I apologize to everybody. It’s all about decisions. It’s helping them make best decisions on what the IT group should be focused on. If you don’t have that, then organizations are just setting themselves up for challenges.

Jacqueline: Absolutely. That piggybacked from some of the things I’ve seen and observed this year. It really dawned upon me. When agile came along and they talked about introducing the product owner as a part of that agile team, nobody told the product owner. It was like, “You’re over in IT. This is a great idea. Let’s include them on the team.” What I mean by that is they really didn’t explain the time, the commitment, some of the type of questions they were going to be asked, and it was determined that they would have to do regular demos.

Now, some product owners are pushing back, but some of that, I believe you said, is proper orientation and introduction as to why this is happening, why this is a business benefit to them. I hear some people say, “I have a product owner that doesn’t want to do all these demos.” I was just recently talking to someone who their lead developer is the product owner, and he introduced some new things that he wanted to put into the system that was not asked for, wasn’t in scope. The scrum master said, “Well, did the business ask for this?” He was like, “Well, I’m the product owner.” He didn’t even consult them. He just figured —

Kupe: “They need this.” Right.

Jacqueline: And it added time to the overall delivery of the backlog and the solution. Going into 2017, we need to corral this whole proxy thing and not just accept the fact that the product owner says, “I don’t want to do this.” My answer is, “We need to have that conversation.” I talk about lunch and learns, or let’s have an orientation. Those who come out, like the lady I said whose blood pressure had come down because someone had told her, “You’re the product owner. You have to do this, this, and this.” She got overwhelmed, and then once she understood, “You get a team together,” she had a much better perspective. Bringing product owners up to speed is so important, and it ties into what Cassie said. At this day and age, IT and the business, they need to be working —

Kupe: As one.

Jacqueline: Yeah. Understanding and appreciating. When you understand both sides, they have an appreciation and respect for one another. That goes back to healthy relationships. And we’ve had a history of not having healthy relationships between business and IT. Some organizations have looked at team building and changing the culture to get us back on the same page.

Whenever I directly had a product owner that said, “I feel like I have to attend all these meetings, stand ups, talk everyday. I don’t want to do that.” I just thought to myself, “Well, upper management begs to differ with you because they have adapted this approach and they see that IT is strategic to business success. Everybody, even on the business side, needs to stand for it. Agile is not just something IT needs to be doing.

Kupe: Right. In the early days of agile, a team I worked on owes a bunch of teams, but the system we were redoing, they were retiring a system and implementing a brand new one. We were building it from scratch, and there were 6 teams; they pulled 6 people out of the business for a 6-month period to actually be the product owners. At the point, I don’t even know if we were calling them product owners, but that’s what they were. It was so important to the business that they moved those people into our teams, which was awesome. If you can do that, that’s great, but oftentimes you can’t.

You have to figure out ways: how do we engage the business as much as we can? That takes away the finger-pointing, the bad blood between the business and IT. That’s not what it should be about. IT should be there to support the business, unless your company is a software business; then, your IT company is supporting the business. I know we have Greg on the line. Let’s get him.

Jacqueline: And there you are. Greg, how are you?

Greg: Hello. How are you guys?

Jacqueline: We’re doing wonderful. Tell our audience where you’re calling from.

Greg: I’m calling from Central New York.

Jacqueline: Nice. So, you’ve heard all of this banter, and I’m sure you have an opinion. We last talked to you and saw you at the #BBCConference. Tell us about your 2016 year-in-review, what you’ve picked up at the conference, and what you see for 2017 in our space.

Greg: I think the year-in-review, this past year, to exactly what Kupe was talking about and what really everybody is trying to figure out: how are we adding value and how are we showing that the IT we’re putting into our companies is adding value to the company? Business analysts seem to be the folks, and I think they should be because they have the training, to help find out what it is that the business is trying to achieve and then marry that to what the IT system, whatever that automation is going to provide and determine whether or not there’s enough value to pay for it.

It really comes down to a business decision of, “Are we going to be making up a return or are we going to be able to do other things with the people we’re freeing up and be able to do things we didn’t have to do? Lower our risks and costs somehow by putting in automation so that we are achieving enough value to pay for the system.” That’s what businesses are trying to do. This year I think there was more and more of that realization that it’s not just about the technology, but as you guys were saying, is it directly adding value to the business.

Jacqueline: Excellent. A key word you used is ‘risk.’ What are the risks of doing this vs. not doing this? That’s sometimes how I do my value propositions. What if we don’t do this? Down to the essential level: if we don’t do this, what’s the worst thing that can happen? When they start stuttering, “We had it in the old system,” that’s not going to fly. I use this in my class a lot, that people, for some reason, don’t necessarily understand what it costs to build software systems. Sometimes we take a $10 problem and throw $1000. We need to have more conversations like that and empower.

I will say that I was encouraged in a couple of my last classes to do an exercise where we ask, “How do you view the business analyst role?” I’ll be honest. For years, I never saw the word ‘leadership’ pop up there. Now, people see us in a role as leading a team. Not just being passive, but being a leadership role. That always makes me so excited, because it does require us as facilitators, helping with decision-making, helping with prioritizing, you have to feel like you’re empowered and you are a leader on that team leading them to the right solution. I like hearing it.

Greg: Yeah. I couldn’t agree more. It was interesting listening to everybody talk about agile, the issues with it. I’m going to combine a couple of things. I want to address the agile but also what I see coming. This past year I’ve been studying systems thinking, and it’s a really powerful way of looking at how people think, how the world works, and then breaking down our thinking. I gave a talk earlier this week at a symposium at Cornell University about a better way of defining scope on IT projects by using systems thinking, and taking our standard models, our context diagram, our functional decomposition which is one of my favorites, and use cases and use cases diagrams and applying systems thinking to that.

The thing that really ended up coming through was that it allows us to combine all of these views into a single model and look at the system in a much more holistic way. The whole reason we do that is to improve, as Kupe was saying, improve our decision-making. Shorten those feedback lops so that we know what the system is doing in shorter and shorter iterations. That’s where it ties into agile. I think all of these things are starting to come together in a way that is going to improve our ability to deliver value to the business quickly and correctly, and that, to me, is really exciting.

Jacqueline: It is. It’s a very exciting space right now. Really got a lot from the #BBCConference, and 2017 is just going to be really exciting. There are a lot of areas where I see business analysis maturing, coming to its own. Kupe, it’s like what we’ve been saying for years: “maybe finally . . .”

Kupe: Right. Yeah.

Jacqueline: I know there are some exciting things for B2T as well. That’s what I want to use this next piece for. First of all, I want to thank B2T from Technology Expresso for this year and being a partner, sponsoring, and just what you have done all throughout my career. I just want to take the time to thank B2T.

Kupe: No, we thank you. To me, B2T is about getting this conglomeration of smart people to help organizations approve and be more awesome: people like you, Greg, Pam, Cassie, Allie, Heather and a bunch of others over the years that have helped so many organizations. We just want to keep doing that and bring more people into the next step and have this awesome group of people.

Jacqueline: Absolutely. Some of those people you mentioned have been guests on our show, so I look forward to next year, 2017, bringing some more people on the show. Also, we have David, my counterpart here on Technology Expresso. David, are you there?

David: Hello. I am here Jacqueline and Kupe. Thanks.

Jacqueline: Absolutely. What would you like to say to us on our 1-year anniversary? You’ve been with us every step of the way, and I know you’ve chimed in with your PM perspective. Any words that you’d like to share with our audience on what probably is our last episode of 2016? I don’t know if we’ll squeeze in another one.

Kupe: Yeah. Might be tough with the holidays and everybody taking a break, but we’ll give it a go. Try to come up with a date.

Jacqueline: Absolutely. Dave, what would you like to say?

David: Let me start off by thanking Kupe for joining us this past year and B2T as a whole. We’re really happy here at Technology Expresso to have partnered with you and provided the listening community an opportunity to hear from, who I consider, lead experts in business analysis. I know as a project manager, I guess I have 2 roles here as a partner and as part of the audience as well. What I’ve learned and heard over the past year through these podcasts has been invaluable to me as a project manager needing and wanting to be more engaged with the requirement and with the solutions that are coming out of the business analysis community.

It has been invaluable. I’ve incorporated a lot of the language in my language as a PM. I think it has gone along way and has provided a certain level of comfort with not only the developers on the clients’ side but with the clients themselves, and showing that they know I’m aware of all the iteratives and activities that go on at the BA level. That helps me provide a better deliverable from a project perspective. It has been invaluable to me, and I look forward to 2017. Hopefully we can continue supporting the BA community, and the PM community as well. I think that’s a 2-way street; our roles are closely aligned and providing solutions to the client. So, I just want to say thank you!

Kupe: Yeah. Thank you. What you highlighted is a thing Jacqueline and I brought up earlier, about this being a team sport. Maybe there was a time that you could do your job in a silo. I know a lot of people did, and there were jokes about throwing the deliverables over the fence and all that stuff. But, effective teams don’t do that. Everybody knows enough about the other parts, and Jacqueline, you just wrote a blog about going from dysfunctional to cross functional and the T-shape kind of skill set that you need to have. You need to be broad across the top of that t, and then maybe go deep in one or 2 areas.

You’re not going to be effective if you don’t know enough about the other roles and the key players that you work with. Just think about a baseball team. You might be an outfielder, but you know what the first basemen are responsible for. You need to know that to be effective. So, David, you bring up the point about how business analysis has helped you be a better PM. I started off as an accountant and then a BA, but I was a BA that thought I wanted to climb the company ladder and be a PM. Then, I went back to BA. I always say, being a PM made me a better business analyst. You have to know enough about everybody else on the team to make it a really great, high-performing team.

Jacqueline: Absolutely. To our audience: I have really enjoyed this show, this episode. Thank you for everyone who participated and even those who are listening on the line that didn’t want to have a speaking part but are helping us celebrate our 1-year anniversary. I want to turn it over to Kupe for him to wrap it up from his perspective and his reflections on our 1-year anniversary and even some of the things for 2017. Kupe, the mic is all yours.

Kupe: Awesome. I think 2017 is going to be a fun, exciting year. We just always enjoy helping other people get better at what they do, and this is kind of this analysis space, agile space, IT space. The IT transformation and helping teams get better is kind of where we sit and where we fall. I just read some surveys that came back. We do evaluations from all the clients. I read evaluations from a number of classes that we did over a couple of weeks, and there was one question we asked: “Would you recommend this to your colleagues?” That’s the first question I always look at to get the answer. It’s pretty much, I would say, 99% of the time the answer is yes.

I just love seeing that. That means we’re adding value to organizations around the world. In 2017 I think some of the big pushes that we’re going to do is in the agile space, and it’s around the practical application of agile and how do you get better. All the things we talked about today, helping other people make good decisions, how too critically think, how to focus on the right thing. We have a number of offerings and we have a whole suite of how we can help organizations transform their agile practice or their practice to be more agile.

Jacqueline, you and I were talking to a client a few weeks ago. They were trying to figure out what they were doing with their agile practice. They said, “We talked to 20 people and got 42 different answers on how to implement agile.” It is really difficult. Actually, that answer was correct. You talk to 20 people and each person will have at least 2 ways you can do it. That’s the approach we take. We try to give enough knowledge, at first, so that you know what you’re up against. There were a lot of unknowns, and now you have a lot of knowns and options of things you can do. Now, with those options, what’s going to work well.

The thing you talk about all the time, Jacqueline, is one of the key things we do first: swan analysis to see what the good things are that are going on today, and if they’re really that good, then let’s bring them over. Don’t throw it all out. So, our approach is really practical, and it’s going to make sense. I think it was Rick that talked about the culture earlier. Each agile implementation is different; that’s true, and that’s what we try to understand: what is the culture, what’s going to work, and what’s not going to work? Then, set up a framework where you can continually learn. That’s really big.

The other thing we’ve been working on is an apprentice program. I think too often in today’s world, in today’s business, there are, we call them millennials, but there are young people coming out of college with a lot of college debt, and there are people want to get back into the business for whatever reason; they haven’t been in the business for a while, and they want to get back but there aren’t any opportunities because they don’t have experience. We want to help those people out.

With this apprentice program, they get training, they get a full-time mentor that they can have access to, and then we try to place them in organizations that want to get new, fresh ideas, new talent, new people in their organizations at an affordable price but with some people behind them that have a lot of experience. Really excited about that. To me, yes it’s going to help organizations; it’s like a win-win for everybody, and it’s a real, feel-good kind of service that I think, socially and for the world, it’s going to help. People shouldn’t be sitting around with all this debt and no opportunity, so we want to give them an opportunity.

Then, there are other things, kind of next-generation BA-type stuff that we’re adding to the mix. I did a presentation with Lori Silverman at BBC on storytelling and how to implement storytelling in your office. To me, that’s a skill that I think more and more people need, so we’re going to introduce some workshops. We want to do more stuff around the design thinking space and business model canvas, so we’re talking to more people about stuff like that and how to bring it to organizations to help them improve in any way. Fun stuff. Really exciting.

When I see that feedback that people are not only joining the class but figuring out how to implement it: we have our make learning stick program where we have these follow-up calls. When we hear on those that people are like, “Yep, I heard. I got what you were saying in class, and now here’s what I’m doing with it,” that is the huge win. We’re hearing that more and more, so that’s what we’re all about: to help people change their behavior on the ground and improve.

Jacqueline: Absolutely. I’ll just piggyback one thing to wrap up 2016. One of the best pieces of feedback that I got on one of our classes was a student cursed me. He said, “I curse you, but in a good way.” After the training class, his eyes opened to a healthy way of doing agile. If you haven’t heard that concept of a healthy agile team, then we need to have a conversation. That makes me feel so good, when I’m lowering people’s blood pressure and opening their eyes to a healthy way of doing agile.

Kupe: That’s right. Awesome. Well, this has been an incredible year, Jacqueline. Thank you to everybody that continue to listen to us. This all started because we were having these great conversations. It was just Jacqueline and I, and we wanted to bring it out to the world. Hopefully you’ll continue to enjoy it, and here’s to another great year.

Jacqueline: Absolutely. And thank you from Technology Expresso. Always remember to continue to listen, learn, leverage, and launch. We will see you on #AskAnAnalyst. Stay tuned. Email us if you have a topic that you’d like to have brought up on the show: technologyexpresso@gmail.com. Please like the show on the website so you can be notified when the next episode is. As we mentioned, we might put in another one before the end of the year, so like the show and follow it so that you can get those announcements. That is all for this episode, our first anniversary. Thank you, and remember to listen, learn, leverage, and launch.

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:

Pin It on Pinterest

Share This