Throughout my career, I’ve been in and out of the IT industry in different facets, and through these years I’ve seen technology grow into what it is today. Technology has evolved to be a strategic part of almost every industry. But how has it changed? They way we interact with technology projects has definitely seen its highs and lows, but what about the basics? On today’s show, we’re going to give a definition of ‘what is back to basic?’ Have we gotten too far away from them? Do they still hold up today?
Episode 17 | September 13, 2016 Business Analysis Podcast Transcript
Jaqueline: Hello. This is Jacqueline Sanders-Blackman broadcasting this evening on Technology Expresso Radio. Happy to be with you guys on an evening edition and actually broadcasting remote. Happy to continue our bi-weekly series with Kupe. Hello Kupe! How are you?
Kupe: I’m doing great, and I’m guess I’m remote, too. But I’m in the place I’m usually at: at my house. I guess that’s not in the Technology Expresso studio.
Jacqueline: There you have it. Taking advantage of technology to bring our message to our folks and continue the discussion and conversation. Making it happen wherever we are.
Kupe: That’s right. Jacqueline, in the radio world you would be on-location because you’re out teaching some classes right now. You’re actually on-location, doing the work and seeing the people this week.
Jacqueline: So true. Absolutely, and enjoying it very much. Love being out and about, and a lot of our content does come from being out here with the people who are doing it every day, us finding new ways and creating ways, and hearing what the latest and greatest challenges are. Staying on top of that, things we’re learning in the classroom and problems we’re solving allows us to be able to share it with a broader audience. The names and faces change, but sometimes those pain points are more similar than you can imagine. That is actually a great segway, because one of the things that we wanted to talk about was back to basics. As a matter-of-fact, we wanted to even have this show to say: what is basic? What’s back to basic?
You’ve got the IT industry that has been around for about 30 years. I feel like it’s still somewhat in its infancy when it was coming about, especially from businesses really adapting it and starting to utilize it. Now we’ve seen it evolve, and now it’s a strategic part of every industry, I venture to say. Every industry is using technology in some form or fashion, and I’ve been able to touch upon a lot of those different industries. It has been a great experience. I feel like the IT industry has gone through that kind of crawl, walk, and maybe crawl a little bit more. You’re the same way, Kupe. You’ve been in and out of the IT industry in different facets. Today’s show we’re going to give a definition of ‘what is back to basic?’ Have we gotten too far away from them? Do they still hold up today? That’s what today’s show is about. When we talked about it, Kupe, when we said we were going to do ‘back to basics,’ what came to mind for you?
Kupe: I think the first piece was regardless where you are or where you’re at, and maybe this is something that got bumped along the way, is, for the lack of a better word, scoping. Defining the problem and understanding, “What are we really going after?” Looking at the objectives. For a while, maybe our industry, in this space and in this field, people tended to go through the motions. They were kind of like, “Hey, we want to get to the solution,” and that’s the fun part. They went through the motions a little on the objectives, the goals, identifying the real opportunity, getting to the heart of the matter of what problem we were really trying to solve. That’s one of the keys, definitely, to basics. No matter where you are or what you’re doing, that is the key piece, and if you don’t do that, there’s a big risk of not delivering something and having it not exactly right.
Jacqueline: That’s a good point. Interestingly enough, it’s like you can’t, or at least I can’t, talk for very long about the IT industry without mentioning agile and mentioning how agile is being thrown around and talked about so much. It’s all about faster, and we even throw the word ‘lean’ out a lot. Everybody wants to go lean, they want to be quick, and they want to do agile. You’re absolutely right. We want to skip steps and skip some of the fundamentals. Scoping: it feels like we’ve been preaching about scoping for such a long time. Do you think our industry is just hard-headed? Is that what the problem is? Or is there just a new wave of people coming in that still don’t see the lessons learned over all these years? What do you think?
Kupe: Well, I think part of it is it’s a difficult thing to get your hands on. Maybe some of it could even be equated to people not wanting to make decisions about this stuff. If you lay out the goal for a project, an initiative, or an amount of work and say, “We’re trying to achieve XYZ,” and you don’t achieve it, then maybe there’s a culture in your organization that you’re going to be fired, moved, or demoted. I think it’s a combination of it’s a difficult thing to do and it’s a lot easier to talk about the system and its features and functions than really sitting back and saying, “What are trying to accomplish with that?” The other thing is, I think some people think, “I thought this through. I sat back, I talked to a couple of people, and now I’m ready. Let’s get to the solution. I know what the problem is. Let’s get to it.”
To some extent they do, but the challenge with that is the tools that we talk about and other people talk about, the techniques that are out there to help organizations get down to the heart of the matter, people don’t utilize enough of those. They don’t cross-reference and double-check things. I do want to mention lean, because you and I, at least as recent as this week, started talking about lean business analysis, and I did a workshop called ‘Lean Decision Making’ when I was in New Zealand a couple of weeks ago. It was all about helping people do lean business analysis. I think with agile, too, people try to be lean. The way I defined ‘lean business analysis’ was to add customer value with human resources. If you look for the definition of lean in terms of the way we’re speaking about it, not the ‘no body fat’ kind of lean, because I definitely don’t fall into that kind of lean business analysis.
The definition of ‘lean’ is to remove weight, so it’s basically continuing to add customer value but reducing resources. I think people look at lean business analysis or lean in any way and only really think about half of the equation or half of the definition. Try to remove resources, right, and it’s like, “Well, how can we get lean? How do we reduce resources?” We have to look at both pieces of that puzzle. Are we adding customer value and doing a better job? Are we adding customer value with less resources? It’s not just removing somebody, people, or a group of people. You still have to add customer value. I think people don’t think about it in those terms. They think more on the, at least some of the stories I’ve heard from people, they were talking about removing people but not thinking about still adding the right level of customer value by just reducing resources. I know I said a lot there, so I’m going to let you chime in.
Jacqueline: Absolutely. I don’t know which one to comment on first, but of course when you talk about lean, that part is near and dear to my heart. One of the things is when we think about six sigma, different efficiencies, and continuous process improvement, that does not come without a lot of thorough analysis and doing that background to determine if you take this, the cause and effect. That goes back to what I think is a rush to judgement. Sometimes we’ll cut first and then we’ll figure out if that’s the right thing.
Kupe: If I could just jump in with a story about that. I used to do that with reports and reporting systems, because over the years, the report gets so bloated and I’d have all these reports in there. We couldn’t determine who used what report, so it was like, “You know what? Let’s cut 90% of the reports out, and if someone calls us screaming ‘Where’s the report,’ then we’ll know it was being used. There is time when you should do that, but I don’t recommend it for everything.
Jacqueline: You’re right. It’s so funny you jumped in with that example because you’re right. Like you said, there’s a time and a place to see what is at risk. That’s one of the things I wanted to circle back to and pose the question to you. Sometimes I look at the IT industry and we try to borrow different methodologies because we’ve seen it work in other industries. Everything is from lean, six sigma, on and on. They come from that manufacturing type industry.
One thing, and this is my own personal point of view, is that I’m just seeing IT is not in any way cookie-cutter or repetitious. You can do one thing on one project and it works perfectly fine. That next one is new territory. When you go in there, it’s high-risk. Yes, you can take chances, but there are other projects you have to look at. Again, it goes back to that up-front analysis and saying, “Ok, what’s at risk here?” Back to our topic, this one we need to slow down and go through the A’s, B’s, and C’s.
I’m a big advocate for agile. I’ve been on some great teams and great projects related to agile, but I am one person that will say there’s a time and a place for agile, too. I sometimes say this because I see where companies say, “Our department/company is going agile,” and it’s just blanketed across the board without really saying, “Ok, let’s look at the nature of what we’re trying to accomplish.” To go faster sometimes, you have to slow down and make sure you get the up-front things right, and that’s what allows you to go faster, even in agile. I think sometimes people miss that point. All they hear is the fast part, and they’re off and running.
Kupe: Yeah. Tell me this: would you say agile, and this is your term, that agile a little way makes sense for most things. I think what you’re saying, and we’ve had conversations about this so correct me if I’m not interpreting your terms or your definitions of it. Agile is just the way you should approach stuff. It’s more of a mindset, and it’s not a prescribed process. Going through the motions of agile, of scrum, or writing user stories, that’s doing an agile kind of thing, but being agile is what you’re talking about. It’s critically thinking, “Ok, where are we today? What’s going on? What is the best thing that we can do to move us forward?” It’s thinking about risks and constraints and making decisions based off that rather than any prescribed process.
If you go through a prescribed process, whether it’s scrum or a waterfall kind of thing, to your point, this stuff, whether people want to admit it or believe it, it’s not ABCD. There’s no prescribed process. To your point about manufacturing where a lot of the tools and techniques come from, especially with lean manufacturing: it’s a repeatable process. You can easily check, “Are we getting better?” If we remove this piece of the puzzle, what happens to that door that we were supposed to put on a car? It’s almost like you can see that, you can feel it. With software is one thing, but we’re dealing with human beings all the time, people. I wrote a blog about how your next BA is going to be a robot, so until that point, we’re dealing with human beings.
Human beings are different every day. They have different interests. Depending on the project, they may have a little more power or a little more influence over a project. Someone might be more interested in a project or less interested in a project. Every day, attitudes change, so you can’t just keep doing the same thing over and over and expect the same results. Just going back to the whole agile thing, another piece of the basics I was going to talk about is process stuff and seeing the impact to processes. You have to know what your processes are, and then as you’re building stuff and changing things, you have to be able to evaluate the impact of that process to see if it’s a good decision or not, or is it something we’re ready to accept and the user community is ready to accept. Understanding processes and how things work in an organization is clearly a basic business analysis capability that regardless, you need to have that toolbox and be thinking about it and doing it.
Jacqueline: Absolutely. One of the things that you said which is interesting, and let me respond to the big A and the little a. I definitely think little a is the mindset, and in that mind is also being open that not only is there not just one way to do agile, even from team to team there could be variation within an organization, but also not saying that everything not perceived to be agile is bad. Being agile is being open. Quite honestly, agile is just a whole mixture of other methodologies. It’s some of the good pieces out of various different methodologies over the years. Agile was never meant to be anti-anything, so that’s one of the aspects I see that people who want to be so-called purists around agile are saying, “This way or that way.” Hybrid is not a bad word when it comes to agile.
I will say that on the big A side of agile, the whole manifesto came out. Then of course you had things like scrum come about. Each technique that agile has incorporated has a purpose. There’s nothing bad about these ceremonies, and those ceremonies honestly came about with good intentions for people trying to implement agile. When you’re trying to scale this and communicate this to a whole group of people, you have to have some type of parameters, some type of framework. That’s why I think some of these ceremonies come about. If we say we need to have regular communication, ok. Why don’t we have a standard saying to have a 15-minute quick touch point every morning?
What I see on the other hand is, people want to say that they’re agile and, back to our conversation about basics, they don’t want to do their homework to understand which of those ceremonies will really help you in executing some of the manifesto. I definitely say, starting out, you have to start with the basics, even in agile, and one of the basics, to me, that I do not think is optional, is retrospect. Make the retrospect your own, and make it work for your team until you get to that spot where you’re a well-performing, self-managing team and your communication is on par. The product that you’re producing is proof of that.
With all that said, sometimes I think the problem is that things are so complicated, to some extent, that it’s not so easy to self-diagnose yourself in IT. I used to joke with one organization and say, “You all have random acts of process improvement,” because they’ll try one thing, and if things don’t immediately return an investment, they will jump into something else. In with agile, out with agile, in with a different tool, out with that. I was like, “This is just random acts of so-called process improvement, but you’re never allowing things to settle in to give it a try and then to find ways to make it work in your environment.” Process improvement schizophrenia or something. It takes someone from an outside perspective to help you do some of that assessment.
That’s one of the things I’ve also put out there, too, is that sometimes you need someone from the outside to look. I know in the world of agile we have a lot of coaches on the inside, but even from a step above that, to kind of do an assessment and diagnosis. We talk about those groups, and you sometimes find people complaining about one thing, but they’re pointing to all of the wrong things. I’ve talked about it further with people saying, “We need to work on…” and it might be something like our stories. Our stories are the problem, so everybody’s pointing to the stories, but it’s exactly what you said. The stories are never going to be right if you never lock down your scope.
Kupe: Right. If you never have an anchor or something to make decisions off of to know if that story aligns with where we’re going and it’ll help us get there better, then you’re always going to have problems with your stories. There were a couple of things you said. I really liked that random acts of process improvement, because one of the things I had in basics was continuous learning. A basic is knowing what’s working, what’s not, and trying to adapt and make those changes.
What I like about the ‘random acts of process improvement,’ is that people, we tend to try something, and as soon as we have this inkling, we start to get nervous like, “It’s not working. Abort!” With all of the things that are out there, all of the techniques that are out there, and ways to do different stuff, we have to understand their purpose, believe in that purpose, and give them a chance. When you have these retrospectives or whatever you’re using to continuously learn, you have to determine, “Ok, how long are we going to give this before we abort?” It can’t just be one time.
For me, I love using lean coffee. Talking about lean again. I don’t know if you’re as familiar with that process, but it’s like an agenda-less meeting. The group decides on the agenda. At the beginning of the meeting, you have an overall topic, and then you brainstorm different things within that topic that you want to move forward with. And then the group votes on what they feel is most important. The highest voting topic wins, and you start talking about that. You time box the discussion. At the end of that time box, whether it’s 3-5 minutes, you do thumbs up and thumbs down. If it’s thumbs up, then we keep going with that topic. Thumbs down, then the group has had enough of that topic and they can move on.
One of the first times I did that, someone introduced it to me. I didn’t feel like we were getting to the point of what I thought the results of the meeting was supposed to be. I’m on a back channel working with the other guy leading the meeting, and I’m like, “I think we need to change the process.” Luckily, he talked me out of it, I went for it, we went with it, and it was a great meeting. The process worked. I think that’s just an example of what happens on projects. People start to get nervous. They’re not seeing the light at the end of the tunnel, per se, and they don’t understand how the process works, so they get nervous and jump to something else. They keep doing that.
Jacqueline: Exactly. That’s one of the things around, especially process improvement and when you’re introducing new things, is that people have to understand that whole concept of forming, storming, norming, and performing. You need someone on the team to remind everyone that it’s going to get uncomfortable before it gets comfortable. Just hold on, give it a couple of cycles, a little bit more time, and either we learn something or we learn not to do that anymore. It’s one or the other, but that’s part of the process. During one of those uncomfortable periods, you need to have the right people championing and coaching.
That goes back to how throughout agile, the scrum master is there to help the team stay healthy, especially in their mindset. Where people think you just switch people’s titles from project management to scrum master and that it’s all the same thing — very recently I heard someone saying they’re scrum team is being run by a project manager. I started throwing out a few key questions about, “How do you go about ensuring that the team is healthy, that everybody has the right mindset, that people aren’t falling back to old habits?” Agile is a culture change. It’s not just going from one methodology to another. That, I think, is so important for organizations to understand. I want to tie that back to something else you and I have talked about, too.
When you’re trying to bring your organization along, when you’re maturing either your IT department or individual groups and roles within the IT department, I think there’s a misunderstanding about training. Like you said, I’m on-site doing training this week, and the whole thing is about iterative learning. Some people think, “I took one class. I got it.” That was the mindset, especially when we talk about methodologies like waterfall. You took a class, and if you did A, B, C, and D this particular way, you were doing that methodology. Agile being a mindset, that has to be iterative, let alone some of the other basics. When you talk about scoping, you can take a class, and you’re going to take away pieces of that.
The next step beyond the classroom is to learn by doing. Continue on that path and take follow-up classes. I see when the light bulbs go on, because now they’ve gotten one level of understanding and they’re ready for the deeper dive. Some people might listen to a one-hour webinar and say, “Oh, I got it! I’m done!” They’re off and running when they’ve only got half of the story. That goes along with learning. I know we kind of talked about that before.
Kupe: Yeah. I think in today’s environment, this is not just in IT. Just today I found a, and I started a discussion about it on LinkedIn, it was an infographic about new managers, the lack of training they’re getting, and how it correlates to this research that was done about being successful or unsuccessful managers in their first or second year. Training is not just related to this field. To me, something has to change, because we go through primary school, pre-school or kindergarten all the way through your senior year of high school, or in other countries they call that college, and then you go to university. You’re learning in a pattern that’s repetitious, this iterative nature that you’re talking about.
My kids, I know this firsthand because the new math they’re teaching in school, I don’t get, but I trust it’s better for our children. They get introduced to different concepts, some basic algebra concepts early on, and then the next year, they get a little more and a little more. It’s this pattern of adding more, maybe even difficult or expanded views of concepts. And then we get into the business world and all of a sudden it’s like, “We’ve got to get better, we need improvement, we know what we need to learn, so go to this 3-day class, come back, and you should be an expert.” It’s just an interesting phenomenon that’s out there. Why do we get taught that way as kids into young adulthood and all of a sudden you’re 22-years-old and your whole learning pattern changes and people expect you to be experts really quickly?
I think teams have to think about what are some of the skills that they need to understand, and how do they get to a point where they can start using them and trying them in a fake environment all the way to doing them in a real environment and having coaches and mentors there to give them that feedback. I think it’s this pattern or this consistent iterative nature of learning that people have to go through.
I don’t think enough organizations even think in these terms, that we have to have an overall improvement plan. Think about, “If these are the skills, the capabilities we need to get better at, here is our learning plan that is going to happen in a year and a half.” And things can change within there. You can be agile and adapt as you go, but don’t think about it as one-time events. Think about it as more of a program, and then you can really see some changes, some really good, positive behavior changes that leaders in organizations want to see.
Jacqueline: Absolutely. As we’re sticking around this topic and looking at it from different angles, I’m still reflecting upon this industry. What I’m finding is that people aren’t realizing that this industry has changed. It’s not what it used to be even 10 or 20 years ago. Now, we have more systems, more interfaces, some legacy, and then we try and stay on top of the latest and greatest. I look back and I even joke with people when they’re doing something that would’ve been called business analysis by some of today’s terms. It was sitting and talking with the end users. And that end user hadn’t even used computer software to do their role.
I remember working with some people in accounting, and they would always do spreadsheets. For the first time we were introduced to this interface we were going to do. They were thrilled with what whatever we designed. We were importing those excel spreadsheets, we’d talk to them, and then we’d go back to IT and come up with something. Whatever we showed thrilled them because they didn’t have anything to compare it to. Now you have mounds and mounds and mounds of data, you have all of this big data floating around, and then you have all these different commercial offers.
As things get more complex, maybe we need to go back to the fundamentals. We need to slow down to speed up, because just going fast right now, you make mistakes faster. Some thought needs to be into it. Even as I talk about agile, because I don’t want anybody to interpret what I’m saying as anti-agile, but I do talk about how there has to be some thought that goes into it. I’m a big proponent of what they call the user story now. As we’re picking stories from the backlog and not just based on how many points we can put in iterations but in some order that when we get this group completed, we can say we met this goal and addressed this feature. There has to be that kind of thought that goes into it.
Moving back, you have to make sure you have that right foundation. I love the image of agile: trying to build a plane while you’re building the runway at the same time. If you think of the runway as the technical, underlining pieces and you’ve got to always keep that runway just a couple of feet ahead otherwise you’re going to run into the dirt. There’s this dance that has to be done, and that really has to be balanced. That’s some of the architects and analysts. You have to make sure that you’re doing the dance. Some of that is reconciliation that happens in that upfront work, doing your traceability and reconciling back to that. When we say ‘back to basics,’ several things popped into my head, but when you said ‘scope,’ I was like, “Oh yeah! That’s right.”
Kupe: Yeah. It’s nailing that stuff down. You made me think of something, and I’m going to lump it all into a big category around collaboration, and trust might get thrown into there. I think the basics, what it comes down to, is collaboration. I think that might even be a newer basic than some of the other basics we’re talking about, because in environments in the past, there seemed to be the idea that you had to do less collaboration. I’m not even just talking about agile teams and how agile teams are formed.
To your point, there are so many systems that are tied to so many other systems, and the ecosystem is just this unbelievably well-orchestrated system. I say it’s well-orchestrated because, for example, me with my Google account. I can use my Google account for so many different sites and different things that are connected. With big data, like I go to Facebook and it gives me ads that show the things they think I’m supposed to be interested in based on my past searches and things like that. There’s so much data and systems that are tied together and working in what I think — though behind the scenes it might look crazy — is well-orchestrated.
When it comes down to it, individuals, teams, groups, and companies have to collaborate together to make all this stuff happen. People aren’t thinking about how to do a better job in collaboration. If you nail the collaboration and you have good, open communication with trusting relationships, other things fall into place, and they get easy. When you don’t have a collaborative environment, when you have people going against each other for a number of reasons, then I don’t care if you want to go agile or think agile is great. If you want to use this technique over another technique, it’s just going to be harder. A basic in today’s environment is clearly: you have to facilitate and set up a collaborative environment.
Jacqueline: That’s such a good point. When I did mention agile, one of things I talked about was the culture, that it’s a culture change. You’re absolutely right. I love some of the things I get to say in agile class that completely shocks people, but I can tell by the reactions whether they are actually doing more of ceremony or are they actually embracing the whole concept. They say, “As we break it apart, it might cause more work.” Yes, it might. “It might cause some rework.” Yes, it might. “We might have to double up on our task team.” Yes, that will happen. Remember what we said about embracing change? That was part of it. I remember I talked to someone about them doing an iterative demo. I’m like, “Just because there’s a demo at the end of the sprint doesn’t mean you can’t show them progress every day or every other day, whenever you want to show it to them.” I remember someone saying, “Well, what if they don’t like it?” That’s a good thing.
Kupe: That’s good, right. Awesome! Perfect. That’s when you want to know and not 2 weeks from now.
Jacqueline: Exactly. I’m like, you need to hear this because you’re going to a ceremony. All they were thinking about was “we’re going to build, build, build and at the end of 2 weeks, we do a demo.” You missed the mindset, and you’re just doing a ceremony. One of the things, and it goes back to my comment about how important the scrum master role really is. They’re kind of the shepherd and the steward of the mindset, the environment, and the culture. They’re supposed to protect those things from outside sources that are trying to push back into the old culture or more of the waterfall type habits. You have someone that is trying to promote and bring everyone back to the original spirit of what the manifesto was all about.
That’s why often, some people part of your retrospect are like, let’s just recite the manifesto; let’s just recall what the manifesto said. It’s interesting. I’ve had people who had been doing agile for 5-7 years and when they see the manifesto, it’s like they’re seeing it for their first time. If they have seen it, they’ve just long-forgotten it as they fell into a ceremony. You’re right, and all of this goes back to your point. At the heart, if it’s agile or even if you apply the same approach about collaboration to waterfall, there are certain projects where waterfall could be perfectly successful if you add that layer of collaboration to it.
What I often tell people is that some of the biggest downfalls of waterfall projects happen because it is set up for people to do a lot of finger-pointing. “You didn’t complete this,” “You didn’t do this,” “I’m not going to sign off,” or “That happened during the requirements phase.” There just was a lot of finger-pointing. It’s not that waterfall can’t work. I’ve seen some very structured projects where they were very necessary to do it in that way because of regulated environments and signatures you had to maintain. You can still do a collaborative environment. I’m glad that you brought that point out. It’s two-fold, and I can’t say I pick one over the other. Both the concept of scoping as well as collaboration: it’s a tie for me. I’m not sure I can say that it’s either/or.
Kupe: Yeah. That’s what I love about it. I think it’s the wrong thing, and I do it all the time. I get into great conversations with people that’s like, it’s collaboration over this or scoping over that. I think it’s the combination of all these things. You could be really good collaborators, but nobody focuses on scope. Everybody could get along and have positive conversations, but if no one is talking about scope, then it doesn’t work, either. Maybe everybody is happy and everybody feels good, but somebody’s going to be upset because nothing is getting done and we’re still not hitting the right things. I’ve been on teams where we had great collaboration and high-fives when we released something, but then it doesn’t meet the customer’s needs, so that doesn’t work either.
It’s like this combination of stuff that is so important to think about. To your point, and this might be a stretch, but going back to manufacturing: there are so many different parts and pieces to make it work. It’s not cookie-cutter. There are no silver bullets. It’s the combination of these things it’s doing things with a purpose, and it’s critically thinking about why you’re doing things over not doing it. In the end, you have to know, and this is why we started talking about going back to the basics. You have to know that you have to do these things and you have to talk about these things.
Regardless, you have to talk about scope. Regardless, you have to create a collaborative environment. Regardless, you have to talk about the data that you need. Regardless, you have to talk about the processes. Then you have to talk about all the people that are involved and make sure you have the right people. Then the business rules that govern or constrain the systems. I just rattled a whole bunch of stuff off, but that’s my line of thinking about the basics. It’s like, I don’t care what you call your methodology or process, if you don’t think about or talk about these things, then you’re at risk for missing the mark. Not that everything is always going to be perfect, but you at least have to know that you have to talk about it.
I’m trying to use a house example of some sort. If you don’t know the basics about electricity and how many outlets can be on one wire, you’re going to run a house, and you might say, “The most efficient way is to have one breaker, and we’re going to run one line and make all these outlets throughout the house.” Well yeah, you did it a lot faster. It was a lot cheaper because you used less line and you only had one breaker. However, as soon as you turn the power on, you blow the breaker. If you don’t know the basics of electricity, then you’re going to fail, or you’re at a point where there’s a high risk of failure. It’s the same thing with the stuff that we do.
There are basic knowledge things that you need to know, and if someone on your team or the team’s capability doesn’t have that, then there’s a problem. That’s what you and I are trying to get to: what are those basic things where if you’re not even asking or thinking about it, you’re going to be in trouble. You need to have that basic knowledge and understanding. Then there’s a slew of techniques, and everybody could argue which one is better and why it’s better in different circumstances, but in the end, I don’t care how you scope; you have to have that conversation.
Jacqueline: Absolutely. I think both of us have our own techniques. When we’re doing the show, as you’re talking and I’m listening, I’m jotting down words. When we first started this show, we said we would raise the foundation. As you’re talking, I’m constantly filling my piece of paper with points I want to circle back to. Like you mentioned, this isn’t all going to fit in one episode. It’s a nice 60-minute segment. Who knew we could have filled up two 60-minute segments? We definitely want to continue this conversation.
For those who are listening to this episode or want to listen to the next episode, you can answer: what does it mean to go back to basics when it comes to IT? Is that what we need to do, or are we going wrong with some of our IT projects? If we got any project managers, QA’s, product managers, program managers, we’d love to hear if you think it’s about going back to basics, and what does that mean?
As I’m looking through some of the things that you said, Kupe, one of the things that comes to mind that I don’t think often gets put out there in the IT world is that what we are doing in IT is more art than it is science and that we’re doing very expensive experiments. What we’re trying to do with these tools and techniques, and you kind of hit this on your last statement, is that we’re trying to make sure we identify the big stuff, the high risk stuff. That’s where we can begin, but we also have to start being very forthright and come to an agreement that this is a discovery process. We’re going to discover, because every project has its twists and turns, whether it’s a combination of the project team, or interfaces, data, and legacy. We’re trying to build, go someplace, and make something bigger/better/faster. That’s why we’re doing what we do in IT. It’s always new territory.
This is what we love about it, and what I think sometimes happens is we get cornered. I understand. Businesses need to know what they’re getting for their money; they need to know when something is going to end. We need project managers. We have to have a beginning, middle, and end. I understand that, but there also has to be some conversations where we say, “I’ll get back to you on that.” We have to dig a little deeper, we have to get a little further, and we’ll see what we uncover as we go along. People want IT to be so specific and so scientific like manufacturing, and it’s not. That’s the one thing I think, out of all of our history, we’ve proven that. Quit trying to make this one square box and the next project be the same shape and size as the last project because they never match up that way.
Kupe: Yeah. There’s a theory or concept I read somewhere about how complicated things have gotten. Big systems that are bloated and touching everything. You think you know, “It’s going to take about 8 hours to get this done,” you do it, and you realize, “I just messed with this thing. We have to fix that, too.” The concept around app development: maybe long-term will help with this, because the concept around apps that we have on our phones are primarily smaller in nature and only have a single use. There’s one thing that you do with them. As the user, I can turn it on or off whenever I want. I can disable it from my phone and enable it on my phone.
Even though they’re integrated on the back-end, database wise, and I think that’s still an interesting dilemma that we’ll always have. However, from an interface standpoint, if you’re building things in an app-like manner, maybe that starts to reduce and remove some of the complexity and complication and will help us do a better job. Not that it’s perfect, but be a little better. I can build an app, I know what this thing does, and I know it uses data from other places, but that’s ok. Well work to talk the same language and pull in that data, but then if I have to change that app, I don’t have to do anything to anyone else. I can change an interface without it impacting anybody. I can do something to that app and nothing changes. I was reading about that app, and maybe that’s part of an answer to help reduce some of the complication that we have out here today.
Jacqueline: Absolutely. Another piece that I thought about, and I do want to do a segway to give you an opportunity to talk about something that we’re really excited about with B2T. One last thing just to cue people up. We also have to do at least one other show related to this, so take your time, marinate on the topic, and then call us on our next show. We usually cue them up for every 2 weeks.
I know Kupe and I, our schedules have been busy, but my hope is that very soon we’ll get that on the schedule so you can also mark your calendar and join us. It has been a while since we had a caller segment, but we really enjoy those. They’re a lot of fun, and we like to hear. Maybe Kupe and I are way off base. Maybe we’re making this overly complicated.
Kupe: That’s true. Yeah, challenge us. Maybe we are, and hopefully we are. Maybe it’s a lot easier than what we’re thinking. Please tell us.
Jacqueline: Absolutely. Like I said, I wanted to do a segway because B2T is doing something. We hit upon a little bit earlier about how we’re getting our people, our resources, training, getting them up to speed, and getting them to know how to approach different projects. B2T, being a training organization, we’re working on something pretty innovative. I was wondering if you would take the time to share with our audience some of the new things that are coming up at B2T.
Kupe: Yeah. The big thing, and Jacqueline, you’re a huge part of this, part of the team, is we designed an apprenticeship program, and that program has 2 objectives, 2 main goals. 1 is we see a lot of people either graduating college or people who are trying to transition into a BA-type role and are having a difficult time finding work in this industry and doing business analysis work, because they don’t have any experience. The other piece is we see some organizations are struggling to find new, emerging talent. Part of it is the younger generation, the ones that are going to be their consumers in the future, so how do they bring this new, emerging talent into their organization and have a spot for them with something to do all at an affordable price.
Now, there are a lot of organizations, and I’ve talked to a lot of people and they’ve talked about, “Well, we just bring in senior people.” I think it’s best to have a good mix of senior and not so senior people. We created this apprentice program where it’s a cost-effective way for you as organizations to bring in new, emerging talent; it’s a way for people wanting to get into the role that have the aptitude, that have the willingness to learn to drive to get better and to get some experience.
What we do is we find this talent, these people who are going to be great BA’s in the future, and we train them up and put them side by side with a mentor as they come and start to work in organizations. We’re starting here in Atlanta because Jacqueline and I are here in Atlanta and we’re able to support it. We’re going to try to grow this to more cities as things happen. The idea is bringing in this emerging talent into organizations, allow them to thrive in the organizations, they get experience by being trained by B2T experts and also having those B2T experts as mentors that they can reach out to and use. We think it’s a great fit. We talked to a lot of people that are thinking it’s a good fit as well.
As you have your organization and you have the needs for some emerging talent, please give us a call or text me: firstname.lastname@example.org. If you’re someone that wants to be an apprentice, you want to get into this industry, do this stuff, and come out of this apprenticeship program with the training, certification, and pieces to excel you to the next level. Coming out of this apprenticeship program, we see you having critical experience that can get you jobs in many places. Reach out to us. We’d love to partner with all sides to make this a reality.
Jacqueline: Awesome. Absolutely. Very excited about this. I see it being a win-win on all sides. Come on and get in on the ground level. I think it’s going to be really exciting. Well, Kupe, we have spent the last hour together. I’ll be ready to pick this up in 2 weeks. In the meantime, I want to make sure we get some other points of view. It doesn’t have to be business analysts. I look forward to hearing from developers. We haven’t had that type of episode. I know from time to time David as a project manager gives us his perspective, but I would definitely love to get a developer and testers to join in our conversation. We’ll mix it up and bring in some other perspectives as well. In the meantime, good evening. Enjoyed the conversation, and I look forward to the next one.
Kupe: Awesome! Thank you, Jacqueline. Looking forward to it.
Jacqueline: Absolutely. Alright everyone. Have a good evening until 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 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: 1 Year Anniversary & 2016 Year in Review
- Episode 22 | January 10, 2017: Business Analysis in 2017
- Episode 23 | Janary 24, 2017: Is agile a methodology?
- Episode 24 | Janary 27, 2017: An Agile Mindset
- Episode 25 | February 7, 2017: State of Agile
- Episode 26 | February 28, 2017: Are BAs Becoming Obsolete?
- Episode 27 | March 23, 2017: Remote Agile Team Success