It’s Jacqueline here – I took over the reigns and recorded a quick ‘extension’ episode on a question I often get asked in my Agile Analysis Boot Camp class as well as on this podcast: Is agile a methodology?
Episode 23 | January 24, 2017 Business Analysis Podcast Transcript
Jacqueline: Hello! This is Jacqueline Sanders-Blackman. This is one of our extended series of #AskTheAnalyst, and typically it’s Kupe Kupersmith of B2T Training and myself. We do a 90-minute segment, but today you have myself, doing a 15-minute segment. I’m going to dive right into the topic, which is agile and the whole implementation of what we know as agile. It’s very interesting because I teach an Agile Analysis Boot Camp through B2T Training, and I like to use the questions I get on this podcast because typically, someone else out there might have the same question in the back of their mind. Let’s start with the basics. People first ask me, “Is agile a methodology?”
For me, it’s very clear that it’s not a methodology. A methodology is processes, steps, and procedures that are repeatable whereas with agile, not only are you developing a software in a flexible way, but even the process and the approach can be flexible. That’s what I call big “A” agile, because big “A” agile really is, at the heart of it, aligning your approach with the agile manifesto. You can clearly go to the agile manifesto, and they refer to those as principles and values. When it comes to methodologies, which are how you actually implement those values, that’s when we talk about Scrum, Kanban, or SAFe. Those are flavors of how you can implement agile.
This is why I am perfectly open and even encouraging hybrids, because those don’t have to be the only way. They don’t own the approach to agile, but they’re just recommending some practices that have worked in some environments. That’s why people might pick and choose between a Kanban and an agile or Scrum or even borrow pieces from Waterfall. You have hybrid names like ‘wagile’ and ‘scrumban.’ One of my favorites, just for a chuckle, one of my students said they call theirs ‘fragile’ because they’re in the early stages of agile.
With that said, I just want to respond, again, to a question I get from students from time to time: is agile a methodology? Spending more time talking about whether it’s a methodology or not really doesn’t get to the heart of how to be successful in agile. I’ll tell you the reason behind me saying agile isn’t a methodology. It’s important only because people, when you think of it as a methodology, they think it’s as simple as taking a training class, having everybody read from the same book, or in some extreme cases, watch a couple of YouTube videos and then go back to their desk and be agile. If it was a methodology, that’s possible because you have a set of procedures that you’re supposed to follow all the time, and if you follow those and follow the checklist, then you’re implementing the methodology.
Agile, when you talk about the principles and the mindset, then it’s not so simple to read or watch something, mimic it, and say that you’re agile. When you have to deal with values and principles that are typically different from what that environment currently does, then you have to change people’s mindsets and attitudes. It takes a lot more than just sitting in a training class. I’m a trainer; I train people in corporate America, so I’m speaking from experience. I don’t present agile as I present other topics like six sigma. I teach six sigma very different than I do agile. With agile, it’s about a team-building experience. People have to get used to each other’s working styles and communication styles. A lot of times, you run into disconnects or conflicting styles.
I as an instructor have to observe those and give feedback when it’s happening; I bring those to people’s attention. I build exercises in my agile bootcamp so that I can see these behaviors come out. I do it in a way that it makes people chuckle when I do point them out. If you ask them on the surface if they’re good communicators, if they’re collaborative, if they work well on a team, they’ll say yes across the board. However, there are some latent behaviors, especially when you put a little pressure on people. In some of my bootcamp exercises, I’m timing things and rushing them along. That’s when the real personalities come out. That said, when people leave class, it’s very common in agile for people to go out and get agile coaches. Well, this is great.
A coach is someone that can observe, give you feedback, and help you get back on track; a coach is someone who is there, real-time, interacting with the team. That’s somewhat different from your scrum master. Your scrum master is also shepherding the team and protecting the team, but sometimes a coach is a neutral party that can observe to even make sure the scrum master is on track. All of this is great. You have the team, which by and large should be self-organized and empowered. You don’t want neither your scrum master or your coach telling them how to solve problems; they should observe and give feedback and input, but let the team actually solve the problem. That’s very important and very different from a project manager.
As a matter of fact, most of the time, the scrum master and the coach should be protecting the team from that old-school project management approach where someone comes in and solves the problems. I’m looking for the project managers and scrum masters to actually protect the team, let them do their work, and then if there are outside forces that are a threat to the team, deal with those. That’s dealing with things like coordinating schedules with neighbors or coordinating dependencies with other agile teams. Very little on a day-to-day should a coach or a project manager ever be interacting with the team in a way that they are either asking them for statuses or telling them what should be accomplished.
With that said, I’ve watched teams, I’ve watched coach interactions, and I’ve tracked them over time to see how they’re doing as far as adjusting to the agile culture. Every now and then you really run into someone that is just very resistant. It’s not a matter of them not understanding agile or not having taken the courses. Maybe they’re even participating in the ceremonies. But, at the heart of it all, they haven’t completely bought into agile; they’re not completely vested in the success of agile. They may be passive aggressive, but indirectly they’re undermining. We’ve heard the concept of teams having that one bad apple, that toxic attitude. Well, they find their way into agile as well.
One of the things that concerns me is with agile is when you’re working in short sprints and making 2-week term commitments, you really have to address and nip those bad attitudes early on. If you don’t, it’s going to throw the team off, and it’s going to throw team morale off. What’s so important about agile is the belief that if you have a motivated, excited, and empowered team, you’re going to get quality software. So, what’s the opposite? If you have a team where that bad attitude, the bad vibes are permeating the team, then you’re going to get just the opposite. Furthermore, it’s not going to be sustainable. Once there are cracks in the team, eventually people are going to be looking for ways to leave, get out, and just get away from it as quickly as possible.
I know this to be true because this is when I start hearing people talk about how “agile doesn’t work,” and “agile won’t work in our environment.” Then when I get them to talk about the symptoms they’re having, it becomes clear to me that they’re trying to treat it like a methodology, something that they just implement through different ceremonies and procedures, and they’re not looking at the healthy mindset of the team. I’ll quickly tell you: what creates a healthy mindset of a team is honesty, open communication, and addressing the bad behaviors quickly. When a team sees that they are empowered to address those bad behaviors, then they really start to see a difference in the agile culture.
One of the things I sometimes hear is when people do see certain bad behaviors, those bad behaviors existed in waterfall. When I say bad behaviors, I’m talking about people who are finger-pointers, naysayers, doubting the system, undermining someone’s authority, or even bullying team members. These are the types of bad behaviors that have to be addressed. The team themselves should be the first point of intervention. Just like when you have someone with a personal problem and it goes so bad that you see it affecting them and your relationship, you have an intervention with them. The same thing goes with the agile team.
Like I said, you have to do it early on if you see someone that is bullying, using behavior that is stifling other members, making other members not feel equal on the team or taking a position of authority. Someone that has a big ego. Some of the people who have a big ego are those people who, in their mind, have had previous agile experience or training. Therefore, their opinion counts more than the other team members. That in and of itself can also be a behavior where there needs to be an intervention.
One of the things I say to my teams is no one owns the definition of agile. It’s about what works well and best for the team. If one team member is uncomfortable, then the whole team should find a way until there’s 100% consensus on the team. These are small teams, so it shouldn’t be that hard. If it’s hard because you have a big team, maybe your team is too big. We’re talking about teams of 8-10 people. Something else that slips by is when people talk about their agile teams being dysfunctional. Recently I was talking with someone, and I asked, “Tell me how many people are on your team?” They said 30. It’s much harder to implement that intimate, caring, healthy team when you’re that big.
The big takeaway from this is sometimes you need to pause, what I label the agile timeout, and really evaluate the relationships: the relationships of the team, the relationships of the team with the scrum master, the relationship of the coach to both of those parties, and also the relationship of any project manager that also might be lingering. That, then, also talks about the relationship with your special services and neighbors. Sometimes as you start looking at this ecosystem that has an impact on the success of an agile project, sometimes you need an intervention from within and sometimes you need an intervention from without. An intervention without is what I call bringing in a referee.
I’m going to let you marinate on that. Thank you for checking in with us here at Technology Expresso.
If you have a question or comment, call 855-484-6837, leave a message and we’ll read it on our next episode. Also, please visit our Tech Expresso Cafe page on iTunes for this and other series!
Please enjoy our other episodes:
- Episode 1 | December 8, 2015: Podcast launch and general overview of business analysis today
- Episode 2 | December 22, 2015: 2015 in Review and Set Your Expectations for 2016
- Episode 3 | January 5, 2016: Your Business Analyst Career Path
- Episode 4 | January 19, 2016: Business Analysis Role Fits in Many Careers
- Episode 5 | February 9, 2016: Overcoming Business Analysis Project Failures
- Episode 6 | February 23, 2016: Good Business Analyst vs. Bad Business Analyst
- Episode 7 | March 8, 2016: Business Analyst FAQs
- Episode 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: Back to Business Analysis Basics
- Episode 18 | October 4, 2016: More Business Analysis Basics
- Episode 19 | November 3, 2016: Live from #BBCCon
- Episode 20 | November 15, 2016: Effectively Give and Receive Feedback
- Episode 21 | December 8, 2016: Business Analysis in 2016
- Episode 22 | January 10, 2017: Business Analysis in 2017
- Episode 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