Kupe and I have both been out and about in the community a lot lately and found in our off-air discussions that we are hearing a lot of the same things about agile. One event Kupe attended recently was Agile2016, and a presentation that stood out to him above the others was one on modern agile. During this episode, our conversation is structured around some bullet items from that presentation, including how people are getting paralysis in their implementation of agile, the importance of the agile mindset, and the modern agile.
Episode 16 | August 2, 2016 Business Analysis Podcast Transcript
Jaqueline: Hello Technology Expresso listeners. This is Jacqueline Sanders-Blackman. Welcome to our afternoon edition and our continuing series of #AskAnAnalyst. I’m here with Kupe. Hey Kupe! How are you?
Kupe: I’m doing great. Thanks again. It has been a few weeks since we’ve been together, so this is nice.
Jacqueline: It’s like a reunion. Perfect setup. We’ve been out and about, you’ve been to a conference or a two and I have a few more lined up this year. I’ve been out and about working with clients and customers in the training realm, coaching, and doing intense workshops. That’s all great material and experience that we’re bringing back to our audience to share with them, about what we’re hearing, seeing, experiencing, and what the hot trends are. I’m really excited.
Yes, from time to time we have to juggle our show schedule around, but just know that we’re going out there getting the real-world, real deal experience out there and making that part of the show. We’re very excited. We thank everybody for joining us today. Whatever timezone you’re in, for some it may be early morning and for others it may be lunch or later in the evening, but regardless, thank you for joining us and know that our show is meant to be interactive. We want to hear from you. With that being said, Kupe, why don’t you tell us about the mini adventures you’ve been on? What are some of the things that you’re hearing in your explorations?
Kupe: I assume you’re asking about business analysis, agile-related stuff and not the other stuff going on in my life.
Jacqueline: Yeah, you probably could go in all sorts of directions.
Kupe: Last week I had the great opportunity to attend and speak at the Agile 2016, which is the Agile Alliance Annual Conference here in the US. It was in Atlanta in my and our hometown, so it was kind of cool, although I did stay at the hotel where it was. It was kind of like a staycation. One thing I realized is the I really have no clue about there restaurants in downtown Atlanta. Everybody just assumes that I know all the great restaurants because I live in Atlanta, but I’m about 5 miles East, so I don’t go out to eat down there that often. As it relates to the stuff we like to talk about — entrepreneurship, agile, business analysis, software development — there were kind of a number of themes that I highlighted that I thought was really interesting at this year’s conference.
We’re a learning organization at B2T Training. Jacqueline and I do training, coaching, and that kind of stuff, but there’s something about conferences that’s really cool. One, it opens your eyes and ears to some new ways of thinking. There are a lot of great presentations. Also, the conversations that happen in and around the presentations is where a lot of the nuggets happen. It’s a good time to step away from your daily job to really dive into areas of how you can improve. If you get chances to go to conferences, do it.
One of the highlights is there was a lot of talk about how product ownership does not equal the user community. This is something, Jacqueline, that you and I have talked about a lot. Sometimes when people go to agile, the view is, “We’ve talked to the product owner and their the ones making the decision.” If the product owner says it’s done, it’s done, but really, that’s not the case. A lot of people were talking about that, and there were good conversations around that. The user community is an important part of the puzzle, and they need to be brought into the mix, too.
My topic that I spoke about was design thinking. It was really about how to define the real problem that teams are going after. Teams are doing a great job organizing and are more productive in building software, but is the stuff they’re building the right thing to build? Are they building things that a customer wants to use? Design thinking is creative problem-solving or a problem-identification and solution-identification approach to use the customer lens and really make sure that there’s a high probably that the consumer wants whatever we put out there. Do you want me to continue down that rope, or do you want to react?
Jacqueline: There are definitely some areas that I would love to dive in, but why don’t we give them the broadest and do the deep-dive afterwards?
Kupe: Ok. What I could tell in talking to people that are working in organizations trying to implement agile or improve the way they’re doing things is they fall into two buckets. They’re looking for an approach to take and the tools that will help them get there, and other people are completely paralyzed. They feel there are so many options and so many ways to implement and attack agile, and there are so many different areas that could be the challenge spot that they get paralyzed. They don’t know what to do, so they maybe don’t do anything.
The third thing was there was big discussions about how agile is a mindset. It goes to the previous point around people looking for an approach. This is something I’ve always felt form the beginning, is that agile is not doing scrum or other approaches that are out there. There are critical things related to the mindset of agile, and I think in the end that’s what the writers of the manifesto were kind of getting at. That has been bastardized a little to come up with a single approach that is agile or multiple approaches that could be viewed as agile.
There was a keynote on Wednesday by Joshua Kerievsky. He started up this movement called modern agile, and you can go to modernagile.org for more information. His whole point was this is about the mindset. He kicked off his presentation — which I thought was funny — saying we’re not going to talk about scaling, scalification, safe, scrum, or scrumification. When he was talking about those approaches, half of the audience was cracking up, applauding, thrilled that we’re not talking about specific approaches. The other half was looking around like, “We just spend 200,000 dollar getting everybody trained to be safe-certified and now you’re telling me that’s not what agile’s about anymore?” They were a little confused. He boiled it down to 4 key areas, and we can talk about that in more detail. He was trying to push the maturity of agile about the mindset and how to approach things vs. taking one single or a combination of approaches.
Jacqueline: Awesome. I love going to the conferences as well. It really sounds very intriguing. In the agile space, it’s very interesting, and even as you were speaking I was imagining, there’s a broad audience, a broad spectrum. There are still people that are sticking their toes in. There are people that are just being told, “We’re going agile.” I have an opinion about agile, and this may or may not have come up. Maybe I’m the only one that still thinks this way, but what I have seen, too, is everyone tries to use agile for every type of project. It became “It’s one (waterfall) or the other (agile).” I feel like you have your extremists or your purists, and it’s one or the other. It’s throwing the baby out with the bathwater.
There are circumstances. We do a lot of projects that might be rewrites, freshening up a legacy system, or cleaning up code in the background. There are compliance-type projects, where it’s very specific what we’re doing. It’s not a big, long, “what should we do with this?” It’s very specific because you’re doing something according to some type of compliance. I just throw that out there.
In my travels, I’m working with real-world project teams, and they find themselves set. They’re told that they’re going to go agile. I see where the organization or the IT department is going agile, and with that, everything in some form or fashion fits into some type of mode that is agile. The other challenge I also see in the real world is the IT department maybe declaring themselves agile but are not taking into perspective that the rest of the world isn’t there at that same moment. There are high dependencies. That’s where I would like to see some conversations around. Is it appropriate for this type of project? What are the mitigating factors? Do we have an overwhelming number of blockers? If all the other external agents are waterfall, then how successful could we be? Are we setting ourselves up with this blanket determination that everything is going to be agile therefore — that in and of itself is being inflexible. Before we even declare that agile is the best approach for a particular project, let’s evaluate: what are the parameters?
You have some great points, and I want to take each one. Let’s start with the product owner. You and I have had some conversations about product owner and actually collaborated on a blog post on the B2T website. When you say the product owner is not the end-all, why don’t you start us out with what that conversation was about?
Kupe: Right. Prior to the viewpoint of a product owner, I think the teams would have the analyst or someone that would do stakeholder analysis, figure out stakeholder engagement, and understand who all the players are. Some teams have gone into an extreme where they’re working on a chunk of work and a product owner is the ultimate decision maker. We can go into 101 angles on this, about how when the product owner isn’t available all the time, what are teams doing and how are they working around it, but for the sake of this argument, let’s say they have a product owner they can use and that can help make decisions along the way. What happens is the mindset that, “Oh, as a software development team, all we have to do is work with the product owner.” However, that’s one person. It might not be bad, but to your point, you have to think about this stuff.
This is the mindset piece. You have to trust and validate. Trust that the product owner has the user community or the real-end customer in mind when they’re making decisions and prioritizing. You have to validate that they have a process in place to gather that information. I always say, especially talking to BAs, you might not be the one that is going out. You might be facilitating conversations between your team and the product owner, but you’re not going out to the larger community, but you still have to validate that someone is doing that.
It comes down to the point I made earlier, about we’re cranking out products and teams are doing a better job at continuously delivering, but if they’re not thinking about the end customers/users of these systems, then they’re going to have challenges. People need to think about, yes, there is a day-to-day person that’s doing a lot of the validation for the system, but that doesn’t mean once they validate, they’re done. You have to make sure you’ve also validated with the user community and figure out ways to get them in the mix so they’re constantly part of the conversation.
Jacqueline: Exactly. I think there are two pieces to that, even in defense of the person who gets tagged with that role of product owner. In most cases, they have their day job. They’re probably a pretty significant person who knows that part of the business, so they’re probably pulled in other directions, too, where they need to make decisions, stay informed, or stay in the capacity that they are. That’s a lot to ask of one person. Love the idea of product owner being that single point of decision making, but I used to even say in my class, “When you’re doing stakeholder analysis, everybody can have input, but we just need one person that can make the decision.”
Now, when you look at that nice picture of an agile team, there is that single product owner sitting with the developer and the tester. They just sat together, and they were going to build a solution. The reality is, that person has to go outside of that circle to reach out to subject matter experts, end users, and the upstream and downstream stakeholders. They need to know who to reach out to. The formal stakeholder analysis we are known to do as business analysts, does that all of a sudden get put on the shoulder of the product owner? The title ‘product owner’ is given to this person who is very knowledgeable in the vision of the business and in the representation of the sponsors’ needs, but at the same time, they actually are now the facilitator to reach out and communicate both ways.
Not only reach to get everyone’s perspectives, but that role has also taken on the responsibility of making sure that those who are going to use the system in the end have buy-in. There has to be communication. I remember on another project, not specifically agile, but when the engineers got it, they asked, “Who made this decision?” It wasn’t necessarily a wrong decision, but it wasn’t talked through so they could come to the same conclusion by the time they saw this system that they were going to use on a daily basis. When you put all that together, that’s time-consuming. That’s why there are full-time BAs that have to juggle all that. When you put it on someone who has a day job and just has been labeled ‘product owner,’ and I’ve seen where product owners shared a project. That product owner was responsible for multiple agile teams that were going on at the same time.
Kupe: Yeah. It’s not an easy job. People are like, “We have a product owner,” but there are so many variables that come to play that people need help in understanding what the goal of product ownership is. Then, you can determine, what’s the best way in our organization or in our culture based on how we’re organized, how we’re rewarded, and who has the time? It’s more about the skills needed for product ownership and what that’s really about. To your point earlier, being agile is not saying “this is the way agile is done.” This is why people get paralyzed, because it’s not a one-size fits all.
You used to be able to build teams based on title. You would think, for the most part, that every team needs a product manager, a BA, x amount of developers, an architect, a DVA, a QA, and so on. I apologize if I missed anybody, but you get the gist. Now, it’s thinking about it in terms of capabilities. That could take one or more flavors. Some teams might be able to have a product owner, and they have so much time that they really understand the consumer market and know what to do. You might only need a person, and they have the time to dedicate. They have all the parts of product ownership. However, what typically happens for teams that haven’t gotten to that point is you have to come up with creative ways to fill these roles. That’s ok; that’s being agile. If you don’t do that, then your teams are still going to struggle and have challenges.
Jacqueline: Exactly. In one instance, the product owner said, “Because I’m spread across all these different teams…” One of the things the team was striving to do, which is at the core of agile, was break out their user stories so that they could have increments, do their sprints, do demos, and share with the product owner. The product owner’s reaction was, “I don’t have time for that. I’m spread too thin.” Like you said, we have to step back and look at our culture and our environment. I almost question, “Are you equipped to do agile if your product owner is saying ‘don’t call me until the end of a couple of sprints. I want to see a whole feature before you call me.’” I’m kind of stunned and speechless, which is rare, to say, “Are we doing agile?” Maybe I’m extreme. I’m not sure how you would react in that situation.
Kupe: To me, it’s been about what people are willing to a accept. The beauty of doing things in smaller chunks and seeing things earlier rather than later is that you can catch, adjust, and adapt. When it comes down to it, that’s what it’s about. If this product owner is saying “Don’t come to me until we’re 4 sprints in,” that’s two months from now because that’s when you anticipate the feature to be finished. “We’ll talk now but don’t talk to me for another two months because I don’t have time,” then that person has to know the impact of that, and they have to know what can happen by you not getting involved in the daily, weekly, or bi-weekly demos. There’s a higher chance that we’re going to be off-target, and if you’re ok with that, then that’s acceptable. That’s not a bad thing. It might not be the best thing, but it’s the best thing that this group can understand.
Hopefully that product owner will realize, “Oh, wow. This is definitely not what I intended. Maybe I should get back involved or have someone involved for me.” We might have a slight disagreement in what agile is, because in my sense, that is being agile. And you talked about the parameters. People or teams in organizations are always going to have constraints. There are no ideal scenarios. It’s figuring out the best way to move forward in those constraints.
Jacqueline: This actually is proving your second point, which was paralysis, because of the total contradiction. People were going to agile because they were getting to the end of the product or delivering something and being way off. That was the attraction of agile. Now I’ve gotten to agile, we label ourselves as agile, we create these teams, and we have the product owner saying, “I don’t want to participate in the increments. I’ll show up at the end.” The reality is, and you can have this conversation with them, about, “Well, know at the that if you didn’t come to the demos incrementally, then you’ve lost some of that opportunity to say if we’re going in the right direction or not.”
This reinforces why we need to keep reiterating that product owners get trained along with the team. At the end of the day, if this product owner isn’t allocated to be a part of the team, then they could have all the training in the world, but they just don’t have the time. By not having the time and just showing up at the end, then agile isn’t going to be any different than if they had stayed in waterfall. That’s what my concern is. You can say to them, “You know what’s going to happen if we don’t have these incremental touchpoints,” but the reality is when they get to the end with the product owner, this is the history that people part of the technical team that I’m talking to in the classes have with that product owner.
I can see why you said there were some people walking around the conference in paralysis that on the one hand, agile was supposed to be so different from waterfall, but if you have certain symptoms that are still going on…that’s why we have to bring to the forefront that it’s not that you’re doing agile right or wrong, but there are key things there. I’ll give you an example. I sometimes hear people say, “I’m being pulled on and off the team,” or “New members are coming on and off the agile team.” Again, trying to form a well-formed team with everybody focused on the same project at the same time with the same goals of the sprint is how you keep people, keep the velocity, make your commitments, and meet your commitments. If you’re still having the same symptoms of people being pulled off in different directions, its going to undermine the schedule for the sprint just like it would undermine the waterfall schedule. That’s why people have to be honest and understand.
Sometimes people aren’t the best to do their self-analysis of what the actual problem is, because they’ll say, “Well, we need to get better at this,” and the reality is, your problem may stem from something backing all the way up to how the group is structured or managed. That’s something I wanted to put out there.
Kupe: Yeah. I’m right there with you. I think that’s what causes a lot more pain than anything. There’s something you can sink your teeth into when it’s a specific technique, a specific thing like estimating. It’s easy to say, “Well, that’s where our challenge is,” rather than looking back and saying, “How are we organized as a team? Is there an issue/challenge/opportunity that we have to tweak to get better?” To your point, the team says they’re agile but the business is not, so they don’t have that understanding of, “How do we organize on the business side to make sure we have people available to make good decisions?” There’s only so much you can gain and only so much you can get to in that situation.
Jacqueline: Exactly. As we’re having the conversation talking about the product owner, for any of our listeners that joined late, we’re going through bullet items that Kupe brought back from the recent agile conference he attended.
One of the big topics was the product owner. Part of it, I’m on the side of the product owners that want to do a good job but they also are being stretched and pulled in a lot of different directions. I’m not seeing dedicated product owners. I’m seeing someone that has a day job and on the side is a product owner. The product owner may in some way, because of their bandwidth, be still in that waterfall where they come in up front, tell you what they want. What I hear a lot is “I want it all so just show it to me when you have it all.” Even the incremental demos, backlog grooming and sprint planning, they’re not interested in that at all. They’ll show up at the end. In their mind, everything they ask for, they want, whereas agile is a place where you should be negotiating your backlog and looking for your minimum buyable product.
That’s all tricky, but I don’t want to just be a person that’s a naysayer, because on the other hand, what I’ve seen be successful is you do have a business analyst that helps augment that busy product owner. That’s one of the key things. We often see in various presentations that you never see the business analyst role associated with the agile team. I don’t know if that came up at this particular conference. Is it coming back in style to have a BA? We have plenty of people that come through our agile analysis training that are in the BA role, but is that on the upswing? I know you probably don’t have anything scientific, but I don’t know if you got a feel for that while you were at the conference. Do you have an opinion on if the BA role is on the upswing with agile teams to help support the product owners?
Kupe: There are a few things. At the conference, I was talking to one of our clients, and he said, “I’m surprised there’s nothing here talking about the role of a business analyst in an agile world.” At the conference, and this was a huge conference. There was about 2,500 people in 18 concurrent sessions going on at a time, so it’s hard to totally stay abreast at everything that was happening, though there was a lot of us that were tweeting and keeping each other informed about what was happening in the other sessions. There really was not anything specific around that. Talking to other clients, that is a question they keep asking, like, “What does the BA do?” Even some management, whether they don’t feel this away, the people promoting agile don’t talk about the BA role explicitly, or people say, “Because of the makeup of the team and having the business people a part of the team, we don’t need a BA because they were the translator. They were writing documentation, and agile doesn’t believe in documentation.” Those are the theories and thoughts they have.
There’s a lot of talk right now, and people are concerned about the BA role. Part of it is we’re in this space, and maybe I’m listening for it more in the stuff I read, the people I talk to, and the ones I’m engaged with, but it is a challenge. One of the things I started saying is that it’s partly shortsighted and partly the wrong question. The question of “What do I do with a business analyst on an agile team,” is the wrong question. People need to realize that analysis is needed on the team. Think in terms of capabilities. You said this in our talk yesterday, that no one would ever say we don’t need a developer on the team, right? I don’t know what’s happening in some organizations and what they view business analysis is really about. If their BAs are pure notetakers — and we’ve talked about this before — and they’re having a conversation with the business and copying that into a document then passing it on to a developer, then you don’t need that person.
A good business analyst is the one teasing out what the real problem is and making sure that we’re focusing on the right problem, that we’re heading down the right path, that we’re making good decisions along the way, that we’re prioritizing, and that we’re thinking about the impact our initiative has on other initiatives. There are so many things about analysis that is critical. You don’t need a business analyst, but you need someone doing that work. It just so happens that people that do that work have that title. You might not need someone with that title based on the team and the capabilities.
To answer your question quickly, yes, it’s a hot topic right now, and there are different views on what to do. Teams are trying to figure out that answer. To me, when someone says “We don’t need a business analyst on the team,” I always agree with them 100% as long as they have the capabilities and they’re being implanted in the right way. You said it yesterday when we were prepping for the show that yeah, a developer may be able to do it, but do they have the time? How is the time being broken out? It all comes back to how the team is being organized and being honest and truthful about how much work each person can handle to be effective.
Jacqueline: Exactly. You’re absolutely right. I think some of the history of why people say “There’s no need for business analysis on an agile team” was in the beginning, we said you didn’t need any requirements. There weren’t any requirements in agile. You just wrote a story. But, you know I do a recurring webinar about how there’s more to the story than user stories. There are placeholders. At some point you still have to come to a common understanding. I talk about the business analyst a lot as a facilitator. My thing is, you have to facilitate on the fly. You’re not scheduling meetings, getting everybody in the room and doing workshops.
One of the things I try to tell people is that you’re just eavesdropping every chance you get. When you hear something and you think someone else needs to be in the loop, then you start thinking, “What’s the best way I can facilitate this?” That’s how I see the business analyst role. Having a business analyst that has experience can react quickly. They can read a situation, they can read stakeholders, and as the product owner is thinking about something they want or need, the analyst is putting it through a filter to say, “How is that going to translate into the software and the solution? Does that get added to the story? Is that another story? Is there a technical component involved in that?” They’re already analyzing it to determine, “Ok, how do we represent this in the backlog as a placeholder?” That’s not something that the product owner, like I said before, might have the bandwidth to do or the background to do. They know what they want, but they don’t know it in terms of how you slice and dice these things when it comes to when you’re trying to build a software solution.
To me, it’s very clear. You do have advanced product owners. You have product owners who have come from the technical, but you’re definitely going to have those that can play that hybrid role. Team by team, you have to read the capabilities of everybody, like you said, and see where they are. The more advanced they are or the more advanced the problem/solution is, then you need specialists and not just a generalist. Some product owners could get away with it no problem, but there are others where you have to have that flexibility, even if your business analysts are shared services and you’re bringing them in.
The other thing I’m a big proponent of but that I don’t hear a lot of is the business analyst also wears the hat of the scrum master, because that’s facilitation. With the added training and understanding of how to document the components for the information radiators and velocity, a BA is perfectly capable of facilitating. As a scrum master, part of what you’re doing is making sure the team stays healthy. They’re keeping their agile mindset throughout everything. If you need a hybrid role and you don’t see you need a full-time BA, have a specialist there and use them to capacity. Then, a BA can always assist with testing and QA. You can do different combinations, but understanding and respecting that there are some things, especially if you’re trying to move on the fly, there’s someone that has been doing analysis for their career. They’re going to be able to read something very quickly and make sure that the team takes certain things into consideration. Do you want to respond to that?
Kupe: Yeah. The perfect example where analysis is not there is when I was having a house built — I’m sorry everyone, but I just love using house analogies. There are so many ties to a house, how analysis plays into it, and how it parallels to software development. In our kitchen we had an island and we had granite countertop. It was designed in a way that we had these 4 posts at the end that you could put chairs around in certain stops of this island. There was the island and then there was the granite countertop extending past that, and you could have chairs all around it. The island was put down, and then they were measuring out specifics for the granite countertop. The guy that came to do the measurements, I was thinking he was like a developer. He comes, he’s meeting with my wife, and he says, “I think we can do this in just one slab and not have a seem in the middle.” My wife was like, “That’s great. I love it. Much better than having two pieces cut there.”
They go off and do that, he delivers the slab, and one side is too short. We’re like, “What happened to the extension over here?” He’s like, “Well, you guys wanted one slab.” It’s like, yeah, we wanted one slab thinking that we were still going to have the same measurements. To me, that’s a lack of analysis that happened there to show, “Yes, we can do this different. We can have one slab, but here’s the impact. Do you want to move forward with it or not?” I don’t know if you agree if that’s a good point of analysis. To your point, an analyst that is eavesdropping, and I love that you give that advice, they would hear that and be like, “Is the one slab the same size, or do we have to cut it a little shorter? How does that impact the 4 posts that we want?” Now, it’s funny, because they got 3 posts in and in our attic we have this post that just sits there; it was supposed to be installed but couldn’t.
That’s what happens when you don’t have analysts. It’s hard for people to see that. They don’t think in terms that that’s analysis. Analysis is not writing a user story, writing a use case, or knowing all the symbols in workflow diagrams. Those are tools to help understand stuff and help us keep things organized, but the analysis is that example I gave. We have to keep pushing that. If you have other people on the team that have the time, that know how to do it, and that do it well, then I agree with you that you don’t have to have a business analysis. If you don’t have a BA, then you need other people on the team that are qualified people that have been doing this in a traditional environment that can adjust into this new world of breaking things down into smaller chunks rather than thinking about requirements as a process in the system.
Jacqueline: Exactly. Speaking of analogies, I used this one. It was with some students that were asking about the product owner’s role vs. the business analyst’s role. The conversation was about why do we need business analyst. The analogy I used, which is similar to the house analogy, was about when I built my first house. I had a real estate agent who helped me with some of the negotiation. I bought a house, I’ve lived in houses, so I know houses, right? In that situation, I’m the product owner. I’m representing the buyer, but at the same time, this is a professional. She has been involved with numerous and countless negotiations. She was my advisor throughout it all.
People buy houses without real estate agents, and that’s perfectly fine, but with this first one, she was the perfect example of a business analyst saying to the product owner, “Have we considered this? Do we need to talk about that? Have you thought about this?” We’re advising them to think about, “What about…have you thought about?” Similar to the real estate agent, in one case I was building a house. Upfront we were talking about one thing, but we got to a certain point where something got missed. My real estate advised me, “Let’s negotiate on this to get something cut back because they missed that.” That was a miss, and they admitted it. Clearly we had talked about it, and it had been documented.
She was like, “If we try to fix it at this point, it’s going to be too big; it’s going to compromise the dateline,” so on and so forth. She was like, “How important is it to you? Would you rather just have them take something off the backend to give you a little extra freebie here, or do you really want me to go and make them redo this?” She was playing my business analyst or advisor in that because that was her specialty; she knew that area, and she knew my side as well as she knew how construction worked. That’s what I think is a business analyst.
When the students asked me the question, I used that example. They were like, “Well, can the business analyst just be the product owner?” I was like, “At the end of the day, I have to live in the house.” I could’ve signed a bunch of papers and said, “Oh, you’re real estate agent? You know about houses? You take care of it and I’ll be back in 6 months (I don’t remember how long it took, but hopefully not that long) when its built and move in, and I expect it to be what I think it should be.” You know what I mean? Who would do that? Me as the buyer, I still have to be engaged. We do incremental development when building a house all the time. Every chance I got I was doing drive-by’s to check what progress they made and were we on the right track. That was my analogy. How do you like that one? I don’t think I ran it by you before.
Kupe: I haven’t heard that one before, but I love it. We could debate offline the value of real estate agents —
Jacqueline: We’ll talk about the conditions. I did go alone and do a couple of deals without a real estate agent, but for those first couple of ones, I was taking notes on the value that they provided at that time. As you said, some projects you need them before and some you don’t. I’ve had some very straightforward projects where I hadn’t used a real estate agent. The same thing applies to business analysts.
Kupe: Yeah. There are so many different roles in buying a house. You have people that are inspecting the house. That’s another great analogy where you need someone to walk through the house, inspect it, and advise you, “Here are the critical things to focus on. Make sure you go back and get these things corrected. Here are some things that are not critical that you can negotiate on.” That’s the role of analysis. I’ve said this over the last 3 years a million times, that it’s about helping you make good decisions.
Your example of the real estate agent was, “Ok, here’s the situation you’re in. Here are ways this could play out. I know this because I’ve been here, I’ve done it, and I understand it. I see all the sides that are involved, so here’s how this can go.” They give you options. “You can go option 1 and make them redo it. Here are the impacts. Option 2, ask for money off. Here’s what that means. Option 3, they throw in a higher end appliance for you.” It’s looking at the situation, seeing what’s going on, and giving options to help you make good decisions. That, to me, is what analysis is. You need that on your team. That is non-negotiable. If you look at analysis like that, I don’t know how anyone could argue that it is negotiable.
Jaqueline: Absolutely right. To our listeners, thank you for joining Kupe and I. We’re talking about some of the things we’re hearing in agile as we’ve been out and about. I want to talk about how people are getting paralysis in their implementation of agile, the importance of the agile mindset, and the modern agile. Kupe, you said you saw people walking around that were in a bit of a paralysis when it comes to agile, and I love with agile that you have your retrospect, you have your continuous drive to improve it. Just like anything else, you go through levels of maturity with agile. It is a hot topic right now, so people probably find themselves overwhelmed with different options. There’s Scrum, there’s SAFe, there are different levels of safe, the 3.0 and 4.0, and everybody has their own hybrid.
Sometimes people say, “We have our version of agile,” and they say it in a derogatory way, but to me, that’s the flexibility of agile. You should do it your way, and I am even a proponent that each team has different ways of finding out what works for those teams. That’s the flexibility, but at the same time, people that grew up with the waterfall methodology, they’re used to, “Just tell me what I need to do.” Sometimes I even see that in the classrooms, “Just tell me, what’s the right way to do this?” When you say, “Well, you could do it this way. It depends…talk to your team,” that throws people off a little bit. Get comfortable that you’re not going to get one answer. If someone is coming in and telling you one way, because I get that sometimes, too, where someone will come in and say, “Well, I went to another agile class, and they said that we…” That throws up a red-flag. What are your thoughts, Kupe?
Kupe: Yeah. I was going to bring up that last point you just brought up, where that’s part of the problem with agile. There are hundreds and hundreds of coaches, there are training organizations, there are certifications, there’s Scrum, there’s SAFe, there’s DAD.
There’s actually an approach that says there’s no approach. One of the guys that was a part of writing the agile manifesto has come out with a method, but that method is that there is no approach. He even talked to the guys at SAFe, the guys at DAD, and they are trying to leave the doors open for a lot of flexibility. Even though there are approaches, there is a lot of flexibility within them. Part of the problem is you as a coach may talk to a team and say, “Here are ways you can go things,” and then the next day a different coach might have a slightly different twist. They might even be saying the same thing, but they’re using a different way of saying it, which causes confusion. This is nobody’s fault.
This is why the guy, Joshua, that talked about modern agile was trying to bring it up a level. He was trying to explain what modern agile is and how you do it by talking about 4 things. You can go to modernagile.org. His first thing was make people awesome. That concept is thinking about the customer. How do you make that person more awesome? How do you make their light more awesome? Whatever you’re focusing on, that should be the anchor to say, “Ok, our goal in whatever we’re building is to make the people we’re building it for more awesome.” The second was deliver value continuously. Try as fast as you can to give those people that you’re trying to make awesome, make them awesome faster. Some of this is my paraphrasing, so I hope I’m not totally changing the stuff.
The next was make safety a prerequisite. When he was talking about safety, he was saying it was more from the psychological sense that they can feel comfortable making mistakes when trying things without being judged. When throwing out a crazy idea, they don’t get judged. Make your environment safe. The last piece was experiment and learn rapidly. If you have a safe environment and people feel comfortable, then they’ll be able to experiment, try things out, and do some things differently which they can learn from and get better. The reason for this is to make people awesome.
I had really good conversations with people after this session, because I came away inspired. I really liked it, and in my opinion, you know I talk a lot about improv. That’s a key skill that everybody needs and that this modern agile is perfectly aligned with, the viewpoint of improv. I was really excited about it, and I was talking to people. Someone said, “Why do we have to come up with new stuff? There are new names to call things that we’re already doing.” So, some people were frustrated with it, but I thought it was kind of cool. I think that’s the key. If you are paralyzed, go back to these 4 things. Focus on, “What is the best way for us to do that?”
There was a group that I spoke at last year in Dallas. They walked me around their office, showed me what they were doing and how they were implementing it, and their whole thing was taking pieces from things like Scrum and Lean to incorporate how they were going to be agile. To me, that was the right answer. In some sense, now looking back, it falls into this modern agile concept as well. I want to say one more thing before you chime in. There was a group I was working with that called their hybrid ‘Chunky Waterfall.’ I actually thought that that was a little disgusting, but they were kind of trying to highlight that they just do things in small waterfall and not really agile.
One other thing, Jacqueline, is I listen a lot of sports talk radio. They’re always getting sponsors that bring in food and stuff, so how do we get a sponsor to drop off lunch for us while we’re doing the show? Have some good pizza for ourselves or something.
Jacqueline: Yeah. We should put that challenge out there. The trick is that they have to drop it off in two locations, but hey.
Kupe: I’ll drive to the studio, go to your place.
Jacqueline: We will work on that. Put it on our to-do list. I like what you said and how you tied it into the mindset. One of the things I jotted down is that hone of the team building exercises for agile teams should be some type of improv exercise. Like you said, that’s exactly what agile is. You feel a little bit uncomfortable, but you just go for it. You try and be a part of the solution. I really like that.
When I do live classes, I enjoy observing people, watching people coming out of their shells. When I see certain things, maybe someone that’s kind of standing back, I find ways to make sure I switch people with the pen. There are so many things you can observe in the class that are so fascinating to me. I just love studying the whole dynamic of the team. That in and of itself, sometimes I can tell right away. When you do that first exercise, you see that person who grabs the pen. In my mind I’m going, “I need to get that pen to the next person,” because that person that’s standing back or shying away is going with the flow.
A lot of times, people are used to doing that, whether it’s the titles of the other person or the other person has been there longer. You have to watch for when people do their introductions and talk about how long they’ve been there. Some people just relinquish like, “That person knows more, so if they say it’s this way, that’s the way it is.” I want to highlight that everybody can be a part and say something. When someone says something that’s out of the norm, I’m the first person that puts a spin on it, like, “That was really unique. We didn’t even think that way,” and I’ve seen it open eyes around the table.
Like you said and I’ve said this before, with agile, when you’re changing a mindset that’s affecting the whole culture of an organization and all of the surrounding parts, it takes time. It’s like breaking bad habits, which takes 21 days; it takes time. That’s where the coaching comes in. Even agile and the combination of things you do along with the training — the coaching and even some of the assessments and interventions. Sometimes people can’t see what someone from the outside is able to observe. An outside person helps them with what the root cause is. The symptoms might manifest. Maybe we can’t pick up our velocity, we’re not able to be consistent, or we’re not meeting our commitments. Those may be the symptoms, but let’s look back at some other things from the team dynamics and even the atmosphere.
The mindset: when people say they’re going agile, they really have to take into consideration how they get that team converted or transitioned from a waterfall to agile. It maybe different things that’s augmented, whether it’s improv training or just coaching. Agile, then, really has to become contagious. If you have the technical team that’s agile, then you also have to look at all of the different support teams, partners, and neighbors that they have to interact with and depend on. You have to look at what the product owner’s mindset is and what the business mindset is. You have to make sure that it spreads beyond just the IT team. What are your thoughts on that?
Kupe: Yeah. I wrote down one of the things you talked about, interventions or assessments in the outside view. It’s a lot of things. When you’re deep in trying to self-diagnose, sometimes it’s hard. That’s why coaching has taken off. There’s a consultant training module that is out there in the agile space, and I think it’s good. It’s about how you use that. I’ll give you a shout-out because I’ve seen some of the retrospective summaries that you highlighted to our clients after going in to do maybe a 2-day workshop. “Ok, we addressed what we came here to accomplish, but here are some of the other things we’re seeing that are going on.” Maybe they know it, but it just wasn’t part of why they were brought in initially. It’s the holistic piece that is needed for teams to really get this. This is a massive, massive change, no matter what anybody thinks.
That goes back to why people get paralyzed, because it is so big. You have to recognize it’s a big change, but then you also have to look for the bright spots and start to implement. There’s a design thinking session that I give. At the end, I’m like, “Even if I think design thinking is the next big thing and the thing people should start implementing on software developments, you don’t have to do all of the components of design thinking.” It’s like, just take out something. Try something that can change and improve the way you’re doing business, and start doing and learning. That, to me, is part of the mindset.
You can talk about this stuff all day long. This came up with some of our internal systems that we were doing. A team was working on updating and implementing a new CRM and learning management system. We were talking over and over about how we can do something and how a certain feature is going to work. Finally, we were like, “What are we doing? Let’s try one.” What do we think the best one is, and then we can adjust and adapt. That’s the mindset. Whoever you trust and whoever you feel can help you get there, you should trust in them and try something, because you can talk about it for years and years and years and still not have an answer.
Jacqueline: Exactly. That’s interesting because even with some of the coaching that I’ve done with students, I’m getting them to that point where they can get comfortable with saying, “I don’t know.” This comes up in some of the classes, too, where you have a product owner saying, “How should we do it?” It’s almost pressing the IT team to do a complete design and to be fully committed to one way of doing it, and that’s exactly what agile isn’t. It’s like, “We’re going to get in, try a piece, touch base, see if we’re going in the right direction, and peel back a little bit more.” What I keep trying to help them understand is the advantage: you’re going to take what you learned, and that means your solution is going to be that much more better vs. you trying to predict up front.
Software development has proven to us: it’s unpredictable. Whatever you see, you try to peel back all the bases, but when you get in there, you’re going to have surprises. You want to look at the big picture, take your experience with your architect and teammates, try to identify, but you’re not going to have all of your answers, and that’s ok. Those are some of the things that play into that mindset and you continuously having to say, “It’s ok to feel uncomfortable.”
Kupe: Yeah. And that’s why it goes back to Joshua’s modern agile thing around making safety a prerequisite. That’s part of it. You know if something happens, you’re not going to get fired, be kicked off the team, or be looked at differently.
I forgot if it was his presentation or another keynote, but they were talking about a high-end restaurant in Italy, and one of the desserts was a lemon tart. They were getting ready to bring it out to people that ordered it, and the sous chef dropped it, causing it to crack in the plate and giving it an odd shape. It was no longer this beautiful thing. The sous chef went to the head chef and said, “Hey, this happened. We don’t have anymore. What are we going to do?” Then he said, “Wait a minute. If you look at it from this angle, it looks really cool.” They were able to get it on the plate, and they redid all of them. They smashed them up and made them all look broken. They changed the name of it from ‘lemon tart’ something to ‘Oops, we dropped the lemon tart.’
That, to me, is that safe environment and not looking at everything as though “this is a mistake,” but instead saying, “What can we do with it from here?” That’s why this is hard. This is difficult, and people are scared. We talk to so many people in organizations, and they’re like, “My company’s risk-averse. They don’t want mistakes. They want everything right all the time.” It’s hard to all of a sudden one day say, “Go agile, guys.” It’s not that easy. To your point, there are years and years of culture, and a lot of it might be perception, too. They’re out there, and you just can’t flip the switch overnight. You have to start trying things, and if you go back to that modern agile component and stick to those concepts, then that’s a good way to get the team headed in the right direction.
Jacqueline: Completely agree. Everything that was covered that you said came up in the conference, it’s an interesting parallel that as I was working with clients, the main thing that I see in the real-world is the struggle about the product owner and even that paralysis. One form of paralysis that I see is where people start that waterfall to agile transition, but what I find is that they get comfortable with the transition and don’t keep pushing forward to continue to hone in and really get the benefits of agile. They stay in limbo too long. That’s a form of paralysis, too. Again, going in and doing an assessment or even an intervention and saying, “Keep moving forward.”
It’s like you’re missing the ‘Promised Land’ because you have gotten out of harm’s way, but you’re still in the middle land and not all the way there to where you really see the real promise and the advantage of agile. You don’t know that because you’ve never seen a full agile implementation, but someone else can see, “Ok, you guys are going in the right direction, but now we have to keep moving. Push through. Lean into some discomfort one more time and then you’ll really see that breakthrough.” I want to throw that out there, too. Paralysis comes in many forms, I think.
Kupe: Yeah, that’s great. I know you’re a big proponent around constantly looking at bigger issues on a monthly or quarterly basis and see how you’re improving. You’re right. Part of it is human nature, especially if you’re going through this transition. There’s a lot of change and uncertainty. You’re potentially on edge or excited, and at a certain point, you’re like, “Can’t we just level out a little while?” But then, teams just get back in that rut. We always talk about how you can’t accept “this is just the way we’ve always done things.” It’s comfortable, and teams have to realize, “Is this a good time or should we chill out for a little while?” I actually got push backed today from some people on my team because we’re going through this systems transition, and one of the other systems we used — I think you were on the email I sent.
We use Sococo to communicate and collaborate together. They upgraded awhile ago, and we never did it. I was like, “Guys, I just talked to them. Let’s update Sococo.” I got pushback saying, “Can we just chill for a second? We’re just relaxing from the other systems stuff. Can we not have one more new system to learn?” For me, I was like, “This is easy,” because I had already upgraded. You can’t get into that paralysis, but back to what you were saying earlier, you have to read the team and understand, “Is this a good time to rock the boat again?” or, “How many things can we switch up at a given time?”
Jacqueline: Exactly. I see that and hear that from clients. Sometimes even as they’re doing the agile transformation, there are other things going on in the organization as well. One was they were changing people’s titles, roles, and resetting that. They were doing some HR initiative, something else was going on, and they were doing their Windows 10 upgrade. Everything was in motion, and they were like, “Look, we can’t…” One of the things I said is, “Every retrospect doesn’t have to be a major change. It can just be a leveling off or checking the pulse.” Like you said, make it work for you. I often tell people that yes, there are exceptions in agile and to rules, but don’t get comfortable and the next thing you know, you’re like, “We haven’t done a retrospect in 10 sprints. We just stopped doing them. We don’t remember why.” That’s where my caution to them goes out.
Kupe: I want to ask you one more thing, because you made me think of something. I had a conversation with a friend in Agile 2016. I know you’ve bumped up against this in the last minutes or so we have here. I wanted to get your take on it. He’s a coach for a large organization that has like 200 teams doing their thing. They do their assessments and retrospective monthly/quarterly to see where they are, but there are upper men. The teams are cranking along, and they’ve even identified the next big thing they should focus on as an organization. However, 6 or 9 months of major change at the upper management level, above the teams, comes in. Then it’s like, “Well, who’s the champion, now, to drive this change?” They have to convince new people. What’s your take on that and how that plays into all this stuff we’re talking about?
Jacqueline: That’s what’s so interesting, because that agile model is taking agile all the way up to the enterprise level. The nice thing is you have those different levels stacked on top of each other in a nice handoff, but at the same time, you’re expecting. You should be expecting that there’s going to be a shift in initiative. You have some organizations that are more volatile than others. One of the things I just talked to a group about is when there’s a handoff or someone is handing things down to you, there has to be rules of engagement. That’s part of what safe is, when you have multiple project teams, dependencies, and interactions.
When new initiatives are coming up, what are the rules of engagement? What do I need as a minimum? At a minimum, I need an identified what we call ‘epic owner.’ Users can’t hand something off to me if I don’t have an epic owner that is going to stand by this, stand up for it, and point me to the right resources. If it’s so important that it’s at the top of our queue, then this is what we need to engage in and take the team off of what they’re currently working on. The other thing I tell teams, too, while work is in progress is to treat every sprint like this is the last time you’re going to work on this project. What’s the most important thing I could put in here that if I had to walk away from this, it still provided value to the business?
That’s the big difference in other projects like waterfall. You had project influx. If you stopped it on any given day, you just had a bunch of half-done features and functions. Agile is supposed to be where you’re delivering things in a way that there’s value associated as you go along. When I worked with teams and said that, I said it because I had been in environments where one day this was the number 1 priority with all attention on this and the next thing you know, something else comes along and they’re like, “Drop everything. Now, this is the most important thing, and we’re going to pull your most important people off the team to go look into it.” You expect that, and you govern yourself accordingly.
Maybe we need to deep-dive into that on a whole ‘nother episode, but that’s just the reality. I have seen those environments. Thoughts? Do we need to get into that a little bit more and make it our next topic?
Kupe: Maybe that’s part of our next topic. Actually, you took that in a different angle than I expected in how you were talking about new management might come in with different views of the projects or the work that the team is doing and they need to adapt. That’s a part of it. My friend’s situation was more from learning from the retrospectives and the assessments to say, “Here’s the next piece of stuff that we need to develop as an organization to get better,” and those executives having different opinions on what we should develop or having to convince those executives to buy into, pay, and support those changes.
Jacqueline: Yeah, that’s a whole other thing.
Kupe: The different angle was actually cooler than the angle I was looking at it from. That’s improv.
Jacqueline: Yeah, and maybe something you said made me have a flashback to one of my workshops, so that’s how I ended up down that road. I can totally see that as well. The management buys into the continuous development of these teams. That goes into management understanding what they’re role is. You’re right, I did a real in-depth assessment of one of the teams I had a workshop with, and the top 10 things were things that management needed to understand about what agile required of them. Them making sure there was an environment that, “You’ve invested, but you at the top have to step back and empower.” I can see an executive improv class to kind of loosen them up, because the most common thing is that their reigns are way too tight for self-governing teams. If I come to you and say, “Hey, this is what we need. It will make us better,” then you have to give some leeway. I think there’s a lot more to this for sure.
Kupe: Yeah. I know we’re up against the clock.
Jacqueline: Yeah, we are. We’re going to cut it off here. Thank you everyone that joined and stayed with us. Again, this is Kupe of B2TTraining and myself, Jacqueline Sanders-Blackman of @RequirementsPro if you’re on Twitter. Hit us up. We’d like to hear from you. We’d like to hear what you think of the show. At any point in time if you have a topic you would like us to talk about, please let us know. We’ll see everyone 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 17 | September 13, 2016: 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: 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