This week on the show, Jacqueline had a surprise topic for me; one of her questionnaires on Twitter. We discussed her question, regarding the impact of agile on business analysts, as well as the 4 multiple-choice answers she provided. I exercised my improv skills by giving an answer that wasn’t listed: all of the above.
Episode 26 | #AskAnAnalyst Takeaways
- Jacqueline asked Kupe to answer the same #AskTheAudience question she tweeted: Since agile, do you think Business Analysts are becoming obsolete? Kupe said that all of the following answers are correct:
- The BA role is on the rise: Teams are still struggling, and they’re realizing that they have to do a better job with understanding what value they’re trying to get out and then working on the things that are most important. That is business analysis. Teams are seeing that as the next step in the evolution. So, business analysis, the role, and the discipline are on the rise.
- The future is BA hybrids: For the most part, you realize that on teams today, it’s not as valuable if you’re a specialist all the time. There are other skills you need to pick up and other things you need to do on your team. You need to be a T-shaped employee.
- POs are the BAs: Product owners should be doing a lot of analysis work. That’s what their job is. Their role as a product owner is eliciting information from the people that they’re representing as the PO. Part of their role is being a hybrid BA: doing analysis. The question is – does the PO have the necessary training?
- Agile doesn’t need BAs: Titles don’t matter. Agile teams don’t need an analyst. They need a person or multiple people to play that role and to do that discipline, but that doesn’t mean you need to have someone who has that specific BA title.
- The PM role is also changing – a lot of times, it gets translated into scrum master. The PM can also help the team transition from waterfall to agile.
- People get this wrong impression about agile, but some of it stems from how they’re being thrown into it. Going from waterfall to agile is a project. I don’t want agile to get blamed for some things that there are cures for. A lot of times, it’s just adjusting your thinking and your mindset. Start thinking in terms of business analysis being a team sport.
February 28, 2017 Business Analysis Podcast Transcript
Jacqueline: Hello. Welcome to another episode of Technology Expresso. This is Jacqueline-Sanders Blackman here with another episode of #AskAnAnalyst with none other than Kupe. Hello Kupe!
Kupe: Hey! How’s it going?
Jacqueline: It’s going good. We’re just closing out February, so the year is speeding on.
Kupe: Yeah. It feels like we just did a show rolling into 2017 and now we’re well on our way.
Jacqueline: Absolutely. I like to be spontaneous. We’re spontaneous on this show, and sometimes we have to adjust our times a little bit because Kupe and I are actively engaged out there with clients and customers. I’m still doing business analysis and teaching. Kupe is out there talking with clients. That’s how we get our content and our information fresh and on the spot. Sometimes we have to adjust the podcast accordingly. We appreciate our listeners and how you understand our flexibility. I mentioned to Kupe: I’m going to test your improv skills.
Kupe: I’m looking forward to it. Just so all the listeners know, when I asked Jacqueline, “What are we talking about today?” she said, “I have a surprise topic for you, and you’re going to have to wait for the show.” I’m ready. I love the challenge, and I like the riskiness. It’s going to be good.
Jacqueline: Absolutely. One of the things some of you who follow me on Twitter, whether you follow @tech_eXpresso or me @RequirementsPro, I put out a question via Twitter. I love their questionnaires, and it has been running for the last 7 days or so. My question was around the BA role. I actually switched it up and instead of #AskTheAnalyst it’s #AskTheAudience. We’ve talked about certain topics around the BA, especially as it relates to agile, how it has changed the BA world, and in what ways people thought it had changed. I wanted to first start off with that’s not the surprise, Kupe.
You’re not off the hook, yet, but I just want to start with talking about that survey and thanking those who did respond to it. I really like making this interactive. I know not everyone can dial in on time for our shows, so I’m going to continue putting out those surveys. Let me share with you what some of the responses were compared to some of the things we, Kupe, have talked about on previous shows to see if there are any surprises or anything you want to elaborate on.
The question, again, was: How has the BA role been impacted now that agile is at the forefront and a lot of people are looking into it? I gave them 4 choices; I only get 4 choices on our survey, so I have to be very careful with picking and choosing what I can put in there. I think I covered the range. The first response was whether they thought the business analyst role was on the rise as a result of agile, and now that it has settled in and has been around for 13-14 years, do people think the BA role is back on the rise? To be honest with you, 21% of those who responded said they feel like the BA role is on the rise. Sometimes I talk to people and they feel like it’s on the comeback, because they feel like there was some uneasiness when agile first came out but now it’s on the rise.
I’ll go through these then, Kupe, give you an opportunity to voice your opinion on the results and your thoughts on if they’re reflective. It wasn’t a huge response, but I think there is something in the trends here. 50% of the people responded that they think the BA role is going to be a hybrid role. We can talk about interpretation of hybrid role, but it resonated with 50% of those who responded. 29% said the product owner plays the role of the business analyst on an agile team. Those 3 categories are where all the votes went. My fourth option, which was in agile, you don’t need a business analyst, got no responses. People feel in some form or fashion that there is the need of a BA role. What are your thoughts, Kupe?
Kupe: I know you were limited by the number of answers you could put, but if you could, I would have selected all of the above. The way you put the answers down — BA role is on the rise, the future is BA hybrid, PO’s are the BAs — by using BA, sometimes I call it the business analyst and sometimes I call it business analysis. If you look at BA role is on the rise, I think business analysis and that role, recognition, and discipline is definitely on the rise.
You and I have had a multitude of conversations about what you’re seeing in the classroom and conversations we’re having with people in the community: clients and non-clients. They’re all focusing on realizing that, “OK, we’ve organized well as teams, we’re doing things better, and we’re able to get more group input and deliver things at earlier stages than larger leases we did in the past.” But, they’re still not delivering the things that everybody wants or what is best. They’re still struggling, and they’re realizing, “We have to do a better job with understanding what value we’re trying to get out and then work on the things that are most important.” That, to me, is business analysis. Teams are realizing that and seeing that as the next step in the evolution. So BA, the role, and the discipline is on the rise.
But then the future as a BA hybrid, I do think people that have played in the business analyst role are realizing that, “I’m not just going to be a specialist in business analysis.” There are times in your day, week, or month when you have to specialize, but for the most part, you realize that on teams today, it’s not as valuable if you’re a specialist all the time. There are other skills you need to pick up and other things you need to do on your team. Other people who were primarily QA analysts, developers, or whatever other role, they realize, too, that maybe they’re picking up some different things. So the hybrid-ness is coming out.
I do think the PO’s are the BAs. The second answer and the third answer kind of relate to each other, because product owners should be doing a lot of analysis work. That’s what their job is. They have their stakeholders outside of the team. Their role as a product owner should be eliciting information from their base or their people that they’re representing as the product owner. They need to be doing analysis. Part of their role is a hybrid BA: doing analysis.
Finally, agile doesn’t need BAs: I also agree with that. This is where I switch from analysis to analytics. I don’t think a team – and I’ve always felt this way – to me, titles don’t matter. They don’t need an analyst. They need a person or multiple people to play that role and to do that discipline, but that doesn’t mean you need to have someone who has that title. That could be semantics that a lot of us agree on, but I don’t think there’s a need. Long-term, I definitely don’t see that we’re going to have siloed roles. There needs to be teams built around capabilities and disciplines, not titles. That’s my long-winded answer. So, all of the above, Jacqueline.
Jacqueline: That’s great. That’s exactly what I wanted you to do based on what people were saying. Let me go back, because I think there are some great discussion points here. One of them is why I picked those categories. When you go to a particular site or when someone is voicing their perspective, they’re really reflecting where their company is in their agile outlook, maturity, or how it has been presented to them. For me, even in my experience when I go in the classroom, I find that they fall into one of these 4 big buckets and that they strongly feel one way or another. I know one-on-one when I go to client sites, but what were some of the trends? People either strongly feel like, “We need to get BAs,” and they’re lobbying and asking the question, “What would the BA role be?”
Then, there’s the other group saying, “Well, we’ve been to sites where they took away everyone’s titles, and everybody was an analyst on the team.” They felt like the generic name for everyone was an analyst. Then, within that, we talk about T-shaped employees. You might be in an environment where everybody’s an analyst, but you might also have your specialty, and that’s where the vertical line in the T comes from. You deep-dive into maybe the technical side or maybe the business aspect. I find groups in that camp. That was actually the biggest bucket, the hybrid. What’s good about those is they get the idea of sending everyone to, even though we call it a business analysis class, sending everybody to that because they’re coming away with different elicitation and analysis techniques. Everyone can use it however it applies to that vertical line.
I see that big bucket, and then the other big bucket, like I have in the survey, was the PO as a BA. I can see that to some extent, but what I don’t often see is when and how did that PO get those analysis skills. Having been a PO does not naturally mean you know the whole elicitation and understanding different stakeholders. Because they’re a senior or a leader in a particular business area does not mean they’re a subject matter expert and/or know how to get consensus across different users and other business owners. What I don’t see is yes, they’re saying the PO is now the BA or is replacing what used to be a BA role, but are they getting the appropriate amount of training and coaching? Do people really understand the full breadth of what a BA role is? I’ll pause and see if you have any thoughts on that perspective of how the buckets came about.
Kupe: Yeah. That totally makes sense. Two calls I’ve had in the last two days: one was right before I got on the call for the show. It was related to that PO as a BA, and part of the conversation I had with this one person today was I think people in the BA space, people that have grown up in the BA community, for whatever reason there’s a perception that they can’t take on some of these roles that are popping up in the space, one being a product owner and another more of a client-facing type person. BAs weren’t picked to be in that role, especially the client-facing role, but the people in that role are realizing, now, that they need analysis training.
I think it’s positive that people are recognizing this role needs analysis training or a skill list, but the sad part is they have extremely, strong, capable, smart, well-trained, well-experienced people that can do this role, but they’re not tapping them to step up into this role. There are some perceptions, still, that the BA community is a lower-level position, they just deal with the details, and they can’t meet with the customers. That’s why we do this show and why we push people to feel empowered to step up and do this stuff instead of watching this cool bus driving by that we wish we were on but we can’t figure out how to jump on it.
With the idea that the PO’s are the BAs, I think people are realizing that they’re missing a skill set, and they need to elevate that. On the other side, I’m not a big believer in having a proxy PO, meaning it’s someone on the IT side that doesn’t have a lot of the decision-ing power, but they’re making the decisions day in and day out for the real product owner. People in the BA space should grow into and go work in the business and be those product owners; that’s a potential position for strong BAs, but unfortunately I don’t think they’re getting tapped to take on these roles.
Jacqueline: Exactly. It’s funny – you mentioned proxy, and I cringed a little bit. From time to time I have students say, “Yeah, we use proxies. I’m a proxy for the PO.” Basically, you make all the decisions along the way, and then it’s not until the end when the product is built that the product owner sees it. Sometimes they’re early on with that approach, and because agile is meant to be flexible, as a coach I don’t necessarily show them how I’m feeling about it. It’s like, let’s have a touchpoint in so many months or in so many sprints, and let’s see how that’s working for you. I usually get, by and large, feedback that it’s not working so well. It’s because it’s a way of doing waterfall. “I’m going to tell you what I want, you go off and build it based on how you would answer the design questions that come incrementally along the way, and then I’m going to see it at the end and say that wasn’t what I had in mind.”
That’s my feeling on proxy; try it, then call me. You have to be careful, because sometimes you might have the perfect project that is pretty straightforward, and that’s where it does work. I say across the board that anything can work in different scenarios, but don’t think in every type of project you’re working on, it will work. There are going to be some times when you really need to interact and have discussion, because you’re in an area that has a lot of different options for the problem as well as for the solution. That’s my thought on the proxy perspective.
Something you said, also, about looking to the product owner to take on this BA hat or what was traditionally the BA role. Another suggestion I’ve also made is it’s kind of a paired role, where the BA is supporting the product owner. Sometimes the product owner still has their full-time day job, but then they’re also responsible to be there to answer questions and interact with the team. They’ve been assigned to a team that looks at them as a full-time participant, but they have a full-time job. The BA can be the liaison or the facilitator. If the BA is not needed full-time and you have a strong product owner, the BA, then, can also support the test team or help with whatever other task, even with some of the design conversations.
We’ve mentioned this in our product owner introduction classes, that the BA role becomes coaching and facilitating the team. Like you said, that leads into somewhat of a hybrid, where the BA is still being supportive of the product owner and not just thinking they know all of what the job entails. That’s something we get a lot of in our class, just the shock and awe when they realize, “I didn’t know all of this was involved in the business analyst role.” Just taking the class to raise their awareness. What are your thoughts?
Kupe: Yeah. I think that’s the reason we also promote that, even though the title in the class is analysis, it doesn’t mean people who only play the analysis role should be taking the class. It’s a team sport, and they have to figure out how their team is going to deal with it. If you look at a basketball team, and you have a guy like LeBron James on your team, he’s going to take most of the shots. That’s how that team is going to work. You also have a team that maybe doesn’t have a huge superstar, and they have to share the load. It’s the same thing with analysis.
If you have somebody strong on your team, this is what they love to do, and they’re great at it, then let them go for it. Some teams might be closer to the 100% range of doing analysis work, but then you might have other teams where you’re more 50-50 or 75-25 or some other mix of role. That’s why it’s helpful for a team to understand what it takes to do the analysis on a team and have discussions on how they’re going to act as a team and how they’re going to spread the load when it comes to that type of work.
Jacqueline: Absolutely. I want to talk about the 4th bucket, which was there isn’t a business analysis needed on the agile team. I asked it in that way specifically because when you go back 10-15 years ago when agile was being introduced, that was the word on the street. That’s what everybody was talking about. I can remember people actually leaving the BA role and saying, “I need to get my PMP. I need to become a project manager because business analysis is going away.” It was being said that the whole role was going away. You can go and read various agile books, and you can get a hold of several different authors and books; never do they mention the business analyst role.
One of our clients was comparing training companies, rightly so, for who they wanted to bring in to help them with their agile transformation. They definitely acknowledged that we brought a different flavor to it because, first of all, we’re doing team-building and we’re showing how analysis is a team sport in our Boot Camp. They didn’t see that with the other training. The other part is that they would say, “We’re business analysts. We’ve been brought to evaluate for our organization.” The question was asked, “Where do you see us filling in?” They couldn’t even answer the question. They got blank stares, nor could they adjust their presentation in any way to incorporate the BA. It had just never been taken into consideration.
Some of that was a bit of a setback for a small period of time early on in agile. Some of us still feel like there’s a comeback of the BA and kind of a vindication for some who said in the very beginning that someone on the team, whether you have the title or not, has to have their eye on analysis. What worries me sometimes that I see now, fast-forward to our current inquiries, clients, and people we talk to, they are getting frustrated with agile, but they don’t call out, “We need to get some analysis training.” They just know they’re frustrated; they’ve identified the pain points, but they’re not connecting the dots back to, “Remember when you said analysis wasn’t needed?”
That’s why, in our exercise in the Boot Camp, I lay out the examples and exercises, and I’m in the background coaching them through. They have their own “ah-ha” of, “You’re right. We’re not going to get to the right solution if we haven’t even agreed on the problem up front.” Those different types of “ah-ha’s” they have as a team. It makes it so easy. By the time we get to the debrief, they’re telling me, “Well, you have to do this. You have to have an iteration zero.” Yeah, I agree. Anything you want to add?
Kupe: I think in the end, if everybody had the same definition of what business analysis was, then nobody could argue that it’s unimportant. People have different perceptions and definitions of what business analysis is and where the focus is. They’re like, “We don’t need business analysis; we’re doing agile.” There’s this thing over time that has happened, and we probably don’t have enough time to go into ideas of how we got here. I think that’s the case, and I think your approach is a good one.
People will come to the conclusion of the things they need to do, like getting a better handle on why we’re doing this initiative and getting a better handle of making sure everybody’s on the same page or have an understanding of the goals, objectives, and value of this initiative. That has been called business analysis, and that’s what we’ve been trying to do our whole career. But, other people don’t call it that. My advice to people in the community, if you are having this challenge or this discussion within your organization, don’t fight to make them say, “You need business analysis.”
It’s kind of like these opposite forces pushing against each other and nobody’s moving anywhere. It’s talking about the outcomes that have to be accomplished for success. That’s what’s more important to talk about. So, don’t use the word business analysis if it doesn’t work. Sometimes you can’t convince them; go through a cycle, and then show, “Here’s what happens. Here’s where we can improve. Guess what? This is called analysis, and I have the skills to help.”
Jacqueline: Exactly. Again, like I said, I wanted to ping some of the people in our audience. Whenever you do surveys, being an analyst, it’s so important to also consider who you’re sampling. Maybe we are hitting some of the people that are rather sophisticated business analysts, because they’re out on Twitter; they’re following #BAOT, which is Business Analysis On Twitter. I even had someone reach me, a long-time BA, and ask, “What is #BAOT?” Some of the people that are following it, they’re already in the loop; they’re reading and following the different blog articles. There still might be people that are out there saying the BA isn’t needed and that type of thing. This was our particular sampling.
I do see those buckets, and because of that, like you said, you have to sometimes approach it from a different perspective. The pain points they come up with, especially around agile, is probably my biggest fear; sometimes I feel like agile is getting blamed, now, for a lot of things. You’re always going to have naysayers, but people are quick to say, “Agile really doesn’t work.” That was one of my polls recently: is agile a game-changer or is it not all that it’s cracked up to be? I’ll be honest, because I have a lot of naysayers. I have some in every category, but the majority said agile has a few flaws, but it by-and-large works. I love seeing people saying that.
Sometimes they come to training once they’re frustrated, and so I get people who are very frustrated with agile; it’s funny that by the time we go through their litany of pain points, it’s not agile. It’s either they’re not doing any real form of agile but they’ve picked one component, or it’s hard for a team that has never seen agile being performed any other way to pinpoint what it is that’s causing pain over and over. That’s the nature of agile: the coaching and having someone there from time to time that can do audits and help you. This is a continuous process improvement and adjustment, and the nature of projects change.
I don’t want agile to get blamed for some things that there are cures for, to be quite honest with you. We’ve seen some great turnaround and some great stories from our clients through the Boot Camp. A lot of times it’s just adjusting your thinking and your mindset. Start thinking in terms of business analysis being a team sport. Anything else you want to add on that note?
Kupe: Yeah. With your comments about the people that are saying agile is not working or they can’t do something in an agile manner – if that’s truly their attitude, it’s almost like scribes back in the day when the printing press started to come into full swing. It’s like, the ship has sailed. I mean, everybody is doing agile. There’s not one group, especially in the IT space, that I can point to and say, “They haven’t even started talking about agile.” Everybody is talking about it in some form or fashion. Either they’re full on their way or they’re planning on it soon. The ship has sailed, and agile is the path. It’s figuring out, now, what is your agile piece.
I agree with saying “agile doesn’t work” if they’re doing agile. If they’re just picking an approach and trying to do that over and over, then yeah, it doesn’t work, and that doesn’t work with anything. Having the agile mindset is adapting the team, the department, and the organization as a whole to come up with the efficiencies within that group. That’s being agile. If people take that definition, nobody, in my opinion, could argue that’s not a good thing and that’s not how we should be operating and going forward.
Jacqueline: Absolutely. I’m glad we were able to go through the survey, and I’m going to be proposing some more questions on Twitter. I’m going to call it #AskTheAudience. I enjoyed seeing what they said to see if we’re on the right track. They can always call into the show, but I know it’s hard for people to stop on their lunch hour and call in. They do enjoy listening, and I get that feedback. Again, our shows are in the archives, so they can always listen via the archives or listen on our new Technology Expresso mobile app. Lots of ways to catch up with us. Visit the website b2ttraining.com; not only do we have the links for the recordings, but we also have the transcripts. If you want to browse through and maybe quote and share it with someone, visit b2ttraining.com.
Drumroll, please. I feel like, Kupe, we’ve been a little selfish. We’ve often talked about the BA role in agile and whether it’s needed or not needed, but you know what? PMs are starting to ask the same question. I know you’re thinking that this is #AskAnAnalyst, but I do want to talk about your thoughts because the PM role is possibly changing. Where does that role go? The other thing is I see 3 different avenues for the PM role. When you think about the team level, you don’t see the role PM there, but a lot of times, that gets translated into scrum master. I wanted to get your thoughts and observations on that.
It goes back to the same concept of when people get sent to training, where do they get this training that automatically helps them switch from a traditional PM to a scrum master, and are they getting the necessary training? Maybe some of that training includes analysis and the whole collaboration and prioritizing. The other thing about the project management role, not necessarily the team level, but when we talk about SAFe, there’s the program level and a space for project managers there. The 3rd one, which is near and dear to me, is the project manager helping teams transition to agile. What I find is people are waterfall one day, take a class, and then they’re going agile. Going from waterfall to agile is a project.
Have you seen companies that actually set up projects where either the project manager or the BA role help with the transition? It just popped into my head that we really haven’t talked about the PM role, but they’re going through the same kind of identity crisis. We do have project managers come to our agile classes, and from time to time, I can see that they’re having an identity crisis. What are your thoughts?
Kupe: Yeah. On Facebook I saw Kevin Brennan. He used to be the Chief Business Analyst for the IIBA, and he led the early versions of the BABOK. I saw a post from him on Facebook saying, “I keep hearing the BA role is dead. I actually think PMs have more to worry about.” I agree to some extent. PMs have as much or maybe more of an opportunity than BAs to at least come back and say, “Hey, we do have skills and capabilities that are needed.” I think it’s similar to people in the BA space having a bad perception. I look at BAs that were phenomenal BAs in the waterfall world and are phenomenal BAs in the agile world. To me, it’s not any different in the PM space. I’m not a PMP, so I don’t know everything in the PMBOK, but I was a PM for years. I wrote a blog about this a long time ago.
I think there’s a lot of people in the PM and in the BA space that were successful and can be as successful or even more when they actually want the agile movement to happen. When I was a PM, the way I would run my team is I would get the team in a room and make sure we all had a clear vision of what we were trying to accomplish. Then, we would start asking, “What do we need to do to get things done?” Once we had those out there, it was like, “OK, if that’s what we need to get things done, who can do it? Who has the skills to do it and the time to do it?” I always had, as a PM in the waterfall environment, that agile mindset.
PMs that are good with helping their teams collaborate and with helping bringing people together that have information, they’re going to be good in an agile environment. PMs that focus on the health of their team and make sure that people are happy — I don’t think we focus enough on that. Just make sure their team is happy. If their team is happy, then they’re going to be more successful and more engaged. PMs that were doing that already, and there are a lot of PMs that were doing that, they’re going to be successful in that role.
I think this is part of the perception of PMs, that everybody thinks a PM is a command and control project manager. That’s how project management grew up, especially with the early military stuff about command and control. It definitely worked in the past, but now that has changed. If you’re thinking you’re going to be command and control and be the one to say, “Here are all the tasks that need to happen. Jacqueline, you’re doing this, and make sure it’s done in a week. Kupe, you’re doing this. Jacqueline, are you finished with that task, yet?” then you’re not going to be a good scrum master. It’s about the capabilities. You need people on the team to help collaborate. You need people on the team to help with impediments or walls that are coming up and are stopping the team from being effective. Somebody has to take control of that.
There are great PMs out there that do that day in and day out, and they did it in the waterfall world, so of course they’re going to be successful in the agile world. The same thing goes as a program manager. I think this is less of a change for organizations than when it comes to agile. You still need portfolio and program managers: people to look at the larger picture and then making sure teams are keeping in sync. Someone has to help with the coordination of releasing at the same time and testing all of the pieces together. Someone has to see the bigger picture and be able to react and help the teams react as new information is coming down. Maybe the values of the organization changed or the direction of that program changed. They need to be able to weave in and help support the teams that are delivering the pieces to adapt.
I don’t think enough organizations – and this has been the story of our lives in IT forever. I was on teams where we were given a new tool to implement, and this new tool is how we’re going to track, report, and store requirements. Somebody in our architecture team decided that’s what we were going to use. I always pushed back and said, “We can do that, but this has to be a project. We have to give people dedicated time to focus on this transition.” If we’re going from BAs using Word and Excel to this new tool, we have to view this as a project. Isn’t that what we do with our customers all the time? It’s a project, and there’s time and people dedicated to it.
But it seems like when IT goes through a transformation or a change like this, they’re like, “We’ll just do it. It’s OK. We’ll make it happen.” They don’t dedicate people to this transition. I know you’ve talked in the past about BAs being some of those great change agents. They’re helping customers look at their processes and how to adapt, but why can’t they look internally at our processes? I think PMs fall into that same bucket. They, traditionally, have been the people that look at the bigger picture, can start to put all the parts and pieces together, and do the coordination amongst departments, teams, and people to make it a reality and to get the team focused on getting things done.
People may give PMs a hard time, but in the end, we have to deliver; we have to do something. PMs are those people with that being the key focus: how do we get something to the finish line? I think the capabilities that PMs around the world possess are needed. Just because scrum doesn’t mention there’s a need for a PM, that doesn’t mean the capabilities aren’t needed. The argument I have for BAs is similar to the one I have for PMs.
Jacqueline: Exactly. That was the surprise, to talk about the PMs and get some empathy for the PMs, because they are asking some of the same questions, and there are some concerns on their part. Like you said, we actually are in need of the same aspect. We’re being redefined, and companies need to understand that both skill sets are still needed.
When you talked about IT and implementing tools, a couple of previous experiences came to mind. It’s similar to yours, where we were going to implement this new tool, and they didn’t treat it like a project. Some was at the beginning of a launch of a big transformation. You’re going to introduce a new tool and change roles at that point? All of these things were going on at the same time, and no one was looking at the impacts, the risk, or the overlap. I used to call it “random acts of process improvement.” You’re just throwing them on us, and nobody’s evaluation. There are no controls, here. It got really painful for the team.
That goes back to my biggest fear about agile. People get this wrong impression about agile, but some of it stems from how they’re being thrown into it. It’s not agile, but it’s that the appropriate prep work hasn’t been done. I really see there being agile transformation project managers and business analysts. Some of them come under the umbrella of the coaches, but sometimes organizations bring in the coaches after the fact or to address one aspect vs. there being a plan and pre-scoping that needs to be done to see what are the constraints, impact, and dependencies throughout this transformation. That’s something I think people need to talk a lot more about.
I agree around the program management and SAFe. Once again, with SAFe, there are certain things. When you’re implementing it and not just going through the motions, it should protect that agile team. If it just feels like the same-old portfolio management and PMO, then maybe we need to talk, because SAFe should also be about protecting the team.
The last thing, which was the first thing you talked about, is there have been project managers all along that have wanted to focus on the team. They really understand that keeping a motivated team is how you get quality and engaged workers. Just micro-managing or brow-beating people isn’t the way you get the best out of people. For managers with that mindset, it’s a welcome relief to transition to that scrum master role. There are others who like the metrics, measuring, and evaluating the big picture. There is a place for them, and there’s a place for the business analyst’s skill set. It has been maturing over the years.
I think companies need to not be so hasty with just releasing people because of the title. Look at the skill set. We even have a tool to help them evaluate the different skill sets needed throughout agile and who’s going to play what role. That’s how you find your hybrid players throughout.
Kupe: I think you’re right. I mentioned this earlier when we were reacting to the poll you put out there about BAs. Hopefully HR is catching up and hopefully they’re adapting and adjusting so teams can really do a better job with this, but it’s looking at the capabilities the team needs, then filling it with those capabilities. Teams being honest with themselves to say, “What capabilities do we need as a team? Do we need to find someone else to feel in a gap, or should we send Jacqueline to training? Jacqueline, attend these webinars, and let’s see what we can bring back to the team.” It’s being honest and not looking at our team as, “Well, Jacqueline’s the BA, so she’s supposed to do all these things.” That’s an old mindset.
Part of the issue and why transitions haven’t been totally made is because people are still being rewarded in the old-school way. If you’re a BA with a job title and description, then you’re rewarded on that job description. You’re automatically at conflict when you get onto your team and you start doing things that don’t fall into that job description. It puts people in difficult positions and keeps people in this finger-pointing mentality rather than the team coming together and saying, “We have to get this done. Who can do this type of stuff?”
I really do think — I wrote a blog a while ago about this concept, too — when it comes down to it, if you strip away a lot of stuff and get down to the root cause of the problem of teams not being transparent and open, it comes down to the reward systems and money. If you follow the money, you could probably answer a lot of questions. If you take away money, titles, and the need for people to advance, all of a sudden the team relaxes and is more transparent. It’s more open for help, advice, and bringing in someone new to help with gaps.
I think even in our world where we need to make money to support ourselves, if you have that attitude of openness, transparency, and building these spaces where people can be transparent and open, then those teams are going to be high-performing, these acts are going to be recognized, and you will make more money and advance to places you want to advance. For years and years it has been more of the “stomp on the people you’re trying to get ahead of,” rather than building them up to get ahead.
Jacqueline: Absolutely. I’m really excited for #AskTheAudience, and I want our audience to look out. I’m going to put out another question for you to answer and respond to, so please follow us on Twitter @tech_eXpresso, or you can follow me @RequirementsPro. I’m always retweeting what we put out on the other channels. Kupe is @Kupe and @B2T_Training, who is our sponsor for today’s show. Kupe, thanks again! Look forward to us continuing the conversation. Thank you for your support of Technology Expresso.
Kupe: Yeah, it has been awesome. See you next time.
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 24 | January 27, 2017: An Agile Mindset
- Episode 25 | February 7, 2017: State of Agile
- Episode 27 | March 23, 2017: Remote Agile Team Success