We decided to switch it up a little bit for this show. Instead of Jacqueline asking the questions, I took on the role of interviewer and asked Jacqueline about her thoughts on the 10th Annual State of Agile Report. We discussed the major points of the report, what we agreed or disagreed with, and why.
Episode 25 | #AskAnAnalyst Takeaways
- When agile is not only being embraced at the team level, but also at the enterprise level, it helps drive enterprise success. It’s accelerating product delivery and helping teams do a better job at managing the changing priorities.
- The top 3 barriers highlighted in the report were:
- Culture: From a culture perspective, everyone – from upper management to the team itself – must be dedicated to agile methodology in order for it to be effective.
- Resistance: Address resistance immediately. Don’t wait; it doesn’t get better. Change things up in a playful way, and give people permission to be a little radical.
- Availability of resources: When people are split on multiple, completing projects, it disrupts the functionality of the team. When you’re assigned to an agile team, you’re supposed to be dedicated to that team. If you’re taking someone in and out, you’re impacting the whole team’s ability.
- It’s interesting talking about consistency, because it feels like it’s opposite to agile to some extent. You have to have somewhat of a common framework and approach. You do leave some leeway for variations in teams, and teams have been very successful in that as long as everyone still has that overarching idea where you’re connecting the dots.
- Companies are being challenged as far as consulting and training, because you don’t want someone to just come in and start adding to your staff and increasing your overall cost and run-rate for your project. However, sometimes it takes an outside observer to steer you in the right direction, empower the people, and talk from the top-down and the bottom-up.
February 7, 2017 Business Analysis Podcast Transcript
Jacqueline: Hello. Welcome to another episode of #AskAnAnalyst featuring Kupe of B2T Training. Hello Kupe.
Kupe: How you doing Jacqueline?
Jacqueline: I’m doing excellent! 2017. We’re just chugging right along.
Kupe: I know. It’s February already. It’s like we’re going to be doing our 2-year anniversary show before we know it.
Jacqueline: Exactly. We have to start thinking about what can we do to celebrate our second year. But speaking of that, great segue. For our first anniversary, Kupe and I did a live taping behind the mic. I put it out on YouTube under our Technology Expresso channel. As I was editing the video, I watched all my hand gestures. You know how critical you are when you see yourself on video.
Kupe: Yeah. It’s tough to watch.
Jacqueline: Exactly. I was like, “Next time I have to remember: no crazy hand gestures.” Nonetheless, we’re ready for another episode. I’m really excited, as always, for today’s topic. We’ve been studying and studying a states of agile report that came out in version 1. I’m really excited. This is actually the 10th Annual State of Agile Report. We’ve been studying it, and we have a lot to share and talk about, whether it’s anything that surprised us or how it aligned with our strategies and thought process that we’ve been talking about and predicting even in 2016. Kupe, I’ll let you give your opening comments, and then we’ll jump right into the topic.
Kupe: This one, the 10th annual version one, came out April 2016, so they’re probably in the final touches of the 11th Annual State of Agile Report. I’m actually excited to see the differences since we’ve been looking at this one for a little while now. Today’s episode, we’re going to flip the tables a little: I’m going to be asking you some of the questions. I do think, for the most part, there wasn’t that many surprises. The great thing is to continue to see the numbers go up with teams that are doing agile. My hope is by the 12th one, it’s not even the State of Agile Report anymore but the state of software development instead of agile vs. something else. I think it’s time for everybody to get on board that this is the new way of doing things. There’s always room for improvement and changes in how you do it, but I think agile is what we do now. It’s not some off-the-wall, outlier way that teams approach things; it’s the way we approach things.
Jacqueline: Exactly. It’s not a trend or another gimmick. I completely agree because I find sometimes people get stuck and want to play semantics, or you have purists. Sometimes I like to address that at the beginning of classes and boot camps to get that out of the way. My thing is, to your point, let’s just put to bed agile vs. waterfall. It’s funny that I kind of put that out there as a teaser when I was promoting the show. I said, “Is waterfall making a comeback?” My answer is whether you’re doing a hybrid, the heart of agile is continuous process improvement. If you introduce a technique and it has an agile-feel to it, but you still want to be under the waterfall umbrella because that’s what makes you comfortable, it’s more dangerous to try to look at it as agile vs. waterfall. It’s project-by-project.
You look at the different components that make up the project and what’s the best of all worlds. We have a lot of experience and lessons learned out there, so why not pull from every source? Why cut off one source when that technique would help you with furthering communication, furthering collaboration, furthering the interaction and continuous learning experience. I always go back to the spirit of the agile manifesto. If it’s working for you, stick with your strengths but find opportunities to continuously improve and to address your weaknesses. That’s my thought about it. It’s a state of mind and is about continuously finding the best ways and what works for you to help you with the best software development and delivering value.
Kupe: Yeah. This is why I have webinars coming up, and I’m using the principles of modern agile. It’s the next thing, I guess, after the manifesto. There are more principles in modern agile, and it’s an open source principle-based thing. If you go to modernagile.org you can learn more about it. It talks about 4 principles, and one is making people awesome. The making people awesome piece is really just getting a clear focus on the customer, understanding what their pains are, and understanding the value they want out of the systems, the products, and the services that your team is building. And then they talk about delivering value continuously. If you know value, you have to constantly be delivering it. You can’t just deliver it every 6 months or every year. There has to be something in between where you’re able to consistently deliver value.
Also, making safety a priority. We’ve talked about this before, that good teams are put together, or teams in general get put together, especially one that’s transforming from a waterfall environment where there might be silo roles to an agile structure where the teams are working tighter together. They’re put together, but they don’t know how to have the conversation and how to work together in a positive way to be effective, and that’s what modern agile refers to when it says to make safety a prerequisite. It has to be a comfortable, safe spot for people to share their ideas, be able to work well with the people around them, and be comfortable that everybody has their back.
The last piece is experiment and learn rapidly, and that’s what you were just talking about; try things, learn from it, and adapt. Continuously be improving, and don’t wait for the big reorg with your company to improve. You can change your process and tweak the way you do things all the time. It doesn’t have to be this massive thing. We were trying to get to this report on the last call, but we never got to it. The way we work, Jacqueline, is if one of us doesn’t put our foot down and say, “OK stop talking about other stuff,” then we’re never going to get to move forward because we get sidetracked all of the time, which is a part of the beauty of our show. Hopefully our listeners enjoy that as well.
Let’s get to this report, and we have right now 6 things highlighted that I want to ask you about, get your feeling, and if you agree or disagree with the results of the report. One of the things they talked about is how agile is driving enterprise success. It’s accelerating product delivery and helping teams do a better job at managing the changing priorities. What’s your thought on that?
Jacqueline: One of the things I appreciate throughout the report is they really hit some of the key topics that are being talked about. With agile being around now for almost 15 years, organizations have dabbled in it at the team level, but they have started to have conversations. As you mentioned earlier, you can do agile in a siloed way. You can bring all your bad habits from waterfall, and you’re going to see the same results under the waterfall framework. If you bring in finger-pointing or any negative behavior that’s either anti-team or anti-collaboration, it will show up. You can do agile in a very siloed approach, but organizations are now recognizing that, “No, we have to still coordinate between these individual project teams.” Even above the program level, there are ways in which how people organize their portfolios impact the team.
If you’re swapping up priorities at the portfolio level and this initiative is now more important than that initiative, people are stuck in the middle. They may be in the middle of a project, and they have to shift gears. Having that top-down bottom-up communication and coordination so that the whole enterprise is using an agile mindset I think is a great conversation. I’m excited to see more people doing that. Again, it’s another new territory, so there are a lot more conversations about safe. Not to forget DAD, that’s also another scaled agile approach. I think that’s just showing the signs of our maturity. Back to what you said earlier, agile is here to stay, not just at the team level, but even the enterprises are embracing this. I’m excited about that. What are your thoughts?
Kupe: I want to ask a follow-up question about the switching thing. I think that’s part of the benefits of agile: getting teams in the mode of being able to switch priorities and be OK with that. Even though in theory that’s one of the benefits of agile, when you’re at a client’s site, what’s the overall appetite for being able to make those switches?
Jacqueline: It is tricky. It’s easy for people to get frustrated. I even hear people talk about how they should just go back to waterfall. I do hear those conversations, let’s be honest. That’s where I see you really have to nurture your team. We just went to the Super Bowl, but any team that’s playing, you have to keep feeding them and keep them rejuvenated to go back into the game and play just as hard, in our case, each sprint after sprint after sprint. It’s so important, and that’s why I love the scrum role. When people really embrace the scrum master, not just as another flavor of project management but somebody that’s nurturing and feeding the team. It’s asking a lot of people, because in some cases, by nature we resist change.
So, you have this team you have to embrace. Even in sprint when you’re designing something, you might be getting tweaks and changes. Then, you go to a demo and might get feedback there. Then, you have someone from the top-down saying, “I want to change the features. I don’t want the features to look or behave this way.” Now, even the initiative can change. There’s a mantra I plant in the minds of students: treat every sprint as if it’s your last sprint. The call could come in tomorrow saying, “Hey, we’ve changed our minds. What we’ve built is good enough. We’re ready to bring out the next initiative.” You can hear the air being sucked out of the room for just a minute when I say that, but then they start to nod.
I say, “Prioritize this sprint as if it’s your last sprint.” If you already come in with that mindset and live that every day, then I think it takes a little bit of that sting out. But, from time to time, you need to take your teams aside, reward them, and rejuvenate them, because sprint after sprint after sprint and changes coming from every direction can be taxing on anyone.
Kupe: Yeah. You made me think of the whole value vs. feature conversation. In the past and even some companies who have gone the agile route, the focus is still features and not value. What I mean by that is a team might think at the beginning of the initiative that to meet an objective, these 8 features need to be in the system. But, someone may come down and say, “That project or initiative you were working on is good enough. We want to move you to something else,” teams can get a little thrown off, like, “We only did 4 of the 8 features that we said we were going to do. We need to keep going.”
I think that’s some of the old-school thought. In reality, if you flip it and talk about value, it doesn’t matter how many features you do. You might do 1 out of the 8 or you might do 10 because that got you to the value. When it comes to this point in the survey, what I find is more teams are accelerating product delivery.
I just got off a phone call with a client, and they were saying they switched to agile, and they’re getting the quick wind. They feel so good that they’re able to deliver things faster than they ever have before. I asked the question, “Are the stuff you’re delivering faster than in the past the right thing?” They started laughing and said, “That’s where we’re still immature,” and that’s where they needed some support to make sure they’re not just delivering stuff faster, but delivering the right things faster and getting to the value points faster. I’m hoping the next iteration of this survey is about the maturity of teams overall, that they’re starting to do a better job at that.
Jacqueline: That’s so important: the language about accelerating product delivery. When I talk to directors and senior management, I tell them be careful of that language. I did have someone who said, “I don’t feel like we’re delivering faster. I thought this was going to be faster.” One of the things I often say is it’s going to be slower before it becomes faster because you’re changing a culture. First of all, it’s not just turn-a-key, turn-a-switch. “We went to a class and now we’re agile. Everything’s going to be faster.” What I pointed out was the things you are delivering first is high value.
The other piece I think also gets lost is one of my favorite mantras from agile, which is there’s value in the work that’s undone, the work that’s left in the backlog that says, “We addressed the problem, so we don’t need to do all of these other stories.” I would love that to be one of the KPIs management recognizes, because it’s saying, “Look at the money we saved. We could’ve spent our wealth and created all of these things.” That’s something I stress in class. We in IT have spent thousands of dollars on a $10 problem, and we don’t know when to stop because we could always code more and the users can always ask for more. But, have we already hit our ROI? Anything else we do is just spending money. In IT, we’ve set up this kind of “play money” mindset, because a lot of times there’s not real chargeback for IT’s time.
A part of agile maturity is when organizations come to agile, what they’re measuring should drastically change. It shouldn’t just be measuring story points or, as you mentioned, not just measuring how many features we completed because that’s bringing over the old measuring system that we’ve always done. That has to be challenged, which is the reason you need to have the whole enterprise buy in. If you’re going to continue to reward and recognize how many features you turn out, then that’s what the team is going to try and fulfill because that’s what they’re being acknowledged for.
Kupe: Yeah. You hit on a lot of things on the second point of the survey I wanted to bring up around barriers, adoption, and success. The top 3 highlighted in the report were culture, resistance, and availability of resources. I know you talked a little bit about resistance. What’s your take on these barriers, or do you say otherwise? Or do you want to go deeper into what they mean by culture?
Jacqueline: One part is, by and large, yes. What I’m seeing in the class and with the different clients we’ve worked with is absolutely; it’s culture, it’s resistance, and it’s definitely availability of resources. Let me take each one. From a culture perspective, even though we think we’ve been operating in a team environment, agile really forces that. When people say, “Well, we can’t really do agile because we’re not colocated,” I think we’ve gotten stuck on that ‘colocated’ where we can communicate in real-time. Between video cameras, instant messaging, and messaging systems, we have enough that we can still communicate real-time.
Colocate just means don’t just rely on the document or on email; find those collaborative tools and reach out. If you haven’t heard from someone even in the last 30 or 45 minutes, just ping them. See what’s up and see if there’s any way you can help. You can do it without being colocated. If you get people in the right mindset of why we’re using colocation to get the team to collaborate, you could find ways to be creative and reach out to people. It’s just getting people in those mindsets.
Another thing I see about culture is some groups start out good in establishing that culture and that team-building, but it’s just like anything else. When the going gets tough, when there’s a little bit of pressure, or when the story doesn’t turn out to be the way you thought it would, or even when something breaks and the team has to resolve it. I’ve used this story before about one of the teams: the first time something got pointed out that wasn’t quite right, instead of the team falling out and finger-pointing, the product owner stepped in and said, “Give us time. We’ll fix it; we’ll address it.” Someone even asked, “Whose fault was it?” and the person wouldn’t give anyone up; nobody on the team would give each other up. She was so proud of herself, and we got to talk about it. I applauded and recognized that. That is reinforcing, which is exactly what you need.
When your team knows you’re there and you’re going to protect each other, y’all don’t even have to be in the same room for you to have a cohesive team. I think that’s culture, and the biggest thing I see is upper management. The team is going down that path, then upper management can do some things to sabotage that. One of our clients had a great experience where the upper management wanted to cap a preview of what their teams were going to be taught, and they looked for their action items; what can we be doing so those teams can be successful after they come out of Boot Camp? I think that was the perfect combination, because it addressed it top-down and bottom-up. That’s culture. I’ll pause and see if there’s anything you want to say about that one, and then I’ll talk about resistance.
Kupe: Yeah. You hit on it. The way things were set up, that yes you were a team, but you had so many isolated tasks. Now, you’re put onto an agile team, and it’s different; you have to recognize that it’s different, and some people will be accepting of it while others will take a little more time to get used to it.
I don’t know if you do this or if you have done this in the past, but for family dinners, everyone in the family sits in the same seats every time we sit down for dinner. There are 5 of us: my wife sits in a spot, I sit in a spot, the kids are all in their spots. One time, one of my daughters sat in my other daughter’s seat, and you would’ve thought World War 3 just happened; it was the end of the world. Like, “How can you sit in MY seat?”
People get worked up about a simple seat at a dinner table, and now you’re talking about something you’re doing 8+ hours of the day. You’re going to work feeling comfortable about that routine, and now you’re totally flipping that over; in some instances, it’s a 180. You have to cultivate, know where people are, make sure they’re comfortable, and get them comfortable. That goes back to the modern agile piece about making safety a prerequisite. They need to feel like everything’s going to be OK.
You can eat dinner one seat over; it’s still going to taste the same, and we’re still going to have the same conversations. It’s not like you’re no longer going to be able to digest your food because you’re one seat over. That’s what leaders and teams have to make sure is happening.
Jacqueline: Absolutely. That’s also where I challenge the scrum masters. The scrum masters need to, in a playful way, change things up. From a coach perspective, when you change things up, you get people to start thinking, “Well, if we can break that rule, there are other rules we can break.” That gets you into disruptive and innovating thinking for even when it comes to the solution. It’s funny, but you almost have to give people permission to be a little bit radical, especially if you’ve been in the cookie-cutter following a methodology: if you don’t do this or that, your job is going to be in jeopardy because that’s a career-limiting move. If that has been the monologue in your head for years and years going into corporate America, then someone has to repeat over and over, “It’s OK. We’re going to do something a little bit different.”
I’ve told some of the scrum masters on the make learning stick calls; they said, “I changed up. Instead of our stand-ups, we did one approach, I did a different approach, I got all this feedback, and it’s back to the dinner table.” One scrum master said, “I feel like I do all the talking, so I’m going to switch up and deputize someone to be a scrum master for the week. They can run it and use whatever language, whatever type of talking stick. Do something fun and different.” She got blank stares, and I said, “OK, go back in there and do it again. Give the first person who does it a cup of coffee.” Whatever the case may be to get the ball rolling, because they’ve been indoctrinated into a culture that has been completely different. I think that’s where the resistance is.
They’re living in the past, and it’s not all their fault. They’ve been taught, and they’ve seen people who have been punished or they’ve been punished for deviating from a methodology, and maybe, frankly, they’re even scared. Sometimes you really just have to hand-hold and reinforce. Show them by example that, “No, you’re not going to get punished if we deviate.” People get stuck in the “good old days,” and they look back at “the way things were.” Anything you want to change, they’re like, “We did it this way.” But, is it working for you?
Someone picked up a book about agile or introduced agile to the company because somebody thinks things weren’t working, so you have to accept the fact that the way we were wasn’t working for somebody. That’s something I often have to say to those people who get stuck, resistant, or start throwing 1,000 reasons why agile won’t work for them. One thing I will say about resistance is address it immediately. Don’t wait; it doesn’t get better. I’ve never seen being passive to resistance successful. Find creative ways to talk about it. I also think it’s important for management to say, “What am I doing that isn’t letting this person feel comfortable about breaking out of the way things used to be?” Those are the two things I say about resistance.
Kupe: Right. Leadership has to have a commitment to this. To your point about being passive, if culture and individual resistance is going to be a problem, it is a change. It’s a change in how people are doing business, so it’s silly to think that’s not going to happen. Leaders need to be committed to say, “We are going to do this,” and give the team the empowerment to help define what this new life is going to look like. They need to have 2-4 principles that they really want to commit to, and reward when the principles are being applied. If someone is not doing the principles, find ways to get them across and then stick with it.
You said this earlier: there’s some reason why it’s being brought up, so understand why it’s happening and figure out ways to make it happen. Don’t allow people to fight it to a point that you start to roll back and do things the way you’ve always done. That in and of itself is anti-agile: not trying to improve and just going back to the way things always were. What do you think about the availability of resources?
Jacqueline: Absolutely. Again, they hit it on the head; it’s a big problem, and I hear it a lot. It’s funny — people want to read a book and be like, “An agile team is made of these 5 people and the product owner.” So, you go out and find someone, deputize that person as product owner. I look at it as the equivalent of giving someone a lawn mower or a vacuum cleaner for Christmas. You’re giving me work to do; it’s not a gift. Especially with the product owner; they show up to their first meeting and the next thing is being invited to do stand-ups. They’ve been prepping no other way other than being either a subject matter expert, working in the business, or having a strong view about the solution. But, nobody has addressed how you work, how prepared you are, or what’s expected.
This team now thinks that you’re engaged and part of their team, but nobody has relieved you of your other work and duties. I find a lot of product owners that are caught completely off guard. They’re not sold on the idea of how agile is even to their advantage. People tell me, “I have product owners that are resistant to agile,” and I say, “Well, then you’re not selling it right.” Somebody needed to ramp them up to the fact that “we’re going to agile because it’s better for the product owner.” If no one else, the product owner should see some advantage out of going agile. It shouldn’t just be because it’s convenient for the developers.
And then I also see, again, the bad habits that are brought over. It’s not good for waterfall and it’s definitely not good for agile when people are split on multiple, competing projects. So, I’m on this project team but I still have to support this one, I’m still getting phone calls over here, and one project needs to borrow me for a couple of weeks. That’s not going to help the agile team. It’s going to be disruptive. I see it a lot, and that goes back to management understanding, again, that this is going to be a change and an adjustment. What are you willing to invest to make sure that team is in a good environment and a good place so that they can be successful in agile? Definitely a problem.
Kupe: Yeah. I think there are some resource issues when it comes to the product owner, and I think that’s one of the reasons we have programs at B2T specific to the product owner. Most IT organizations are aware of agile, know what it is, and know why you should do it, but the product owners, if they’re coming from the business as they should be, might not know about it. You have to bring them along the journey and make sure they’re aware of why they’re being asked to do the things they’re being asked to do.
The other piece is when you talk about the team bring split on multiple initiatives and not having a single focus on one initiative at a time, is that less about availability of resources? Maybe that’s what people feel it is: having a lack of resources so as a team member I have to work on 3 teams. Is that lack of availability of resources or is it more a lack of trimming down the stuff and a lack of saying no to something because it’s of less value? A matter of letting teams dedicate, knock it out, and move on rather than trying to do a whole bunch of things yet get nothing done well.
Jacqueline: Good question. It’s probably both. It has to be a resource issue, and how you address that might, again, come from the top-down/bottom-up, because when you’re assigned to an agile team, you’re supposed to be dedicated to that team, and everybody’s working on that same sprint. If you’re taking someone in and out, you’re impacting the whole team’s ability. Especially if that’s not planned and worked ahead of time, then you all have committed to a velocity based on that person being fully dedicated. There are a couple of different things.
Sometimes I see where they’re saying, “Management pulled me off. Management gave me a special task. Another group needed me,” but I’ve also seen, again, some of those old behaviors where someone worked on a previous project and they’re still supporting it. They’re like, “They’re still calling me,” and I ask, “Are you answering the phone?” Well, they will continue to call you. Did you leave them with the necessary documentation and instruction? They’re going to have to schedule your time. Sometimes I find that when people say, “I’m needed,” I see it in the people’s eyes that, “I like being needed from that last project I worked on.” You have to let go.
Kupe: Well, I think that’s one of the old habits of waterfall, that hero mentality. On teams I’ve worked on, there were always people that worked all night because it got crazy towards the end. I had a guy who ended up being in the hospitable because of exhaustion. He felt he had to save things and save the day, so he used to work all night to try to make it happen.
And it does feel good. We like to be liked and we like to be wanted, so it’s a hard thing for individuals to break free from that and focus on the key thing. I say all that to say I get it, and I understand what’s happening. It’s difficult to break that hold, but I think that’s when teams and leaders need to reinforce the times where people are dedicated to their team instead of having that hero attitude.
Jacqueline: Exactly. Even when I’m having conversations with leadership — when you have people under the waterfall umbrella that were spread 3 different ways and had 3 different commitments and then you just send them to an agile class and they’re still split 3 different ways, then they’re going to have that disconnect. Sometimes I think management thinks agile is a silver bullet, and that they can use that same resource who is overworked and over allocated, and then I expect projects to start going faster just because you start creating user stories and Kanban boards. It doesn’t work like that. Don’t blame it on agile.
Kupe: Agile, in my mind, is less about having a Kanban board and having user stories than it is about some of these culture things. I mean, you can’t have one without the other. The accepted ways to manage work is through stories and using scrum and SAFe. You talked about using those approaches as guidelines along with Kanbans. Yes, those fit, but below all of that as the foundation are these cultural things that have to change. One of the things I see all the time is on the HR side. Teams or companies want to go agile, but on the HR side of the house, they still have titles for all the individuals, and those titles come with job descriptions.
Those job descriptions don’t align with the work that you do on agile teams, because the whole concept is that your title might be BA and your job description is a set of work, but when you’re on the team, your goal is to make sure you’re focusing on the goals of the team and to help the team in any way that you can. That might mean you’re doing work for a period of time that is not in your job description. If you’re being rewarded for work that you’re doing that’s in your job description, now it’s kind of at odds with the teamwork you’re doing.
So, you’re putting the employees of the team members in a bad position between a rock and a hard place. “I want to help my team, but at the same time, I might not get a raise, because I’m not getting better at this work over here that I’m being recognized for.” That ties in with a lot of the culture changes that have to happen.
Jacqueline: I totally agree. You have to evaluate something I call rewards and recognition. What is that? It can’t look the same, and if it’s the exact same, you’re going to get the same behavior. Management really has to reevaluate that.
Kupe: Yeah. I think we hit that one really good. There was a third one on the list that I wanted to talk about. The third thing was the top 3 tips for success with scaling agile. You talked about safe and some of the common frameworks that are out there. The top 3 tips for success were 1: a consistent process and practice, 2: a common tool across the teams, and 3. consultants and trainers. I want you to talk about that, what it means, and what you’re seeing on teams.
Jacqueline: Well, you know it’s interesting when you talk about consistency, because it feels like it’s opposite to agile to some extent. It is also talking about, as you start to mature and you’re having multiple teams doing agile, and then you also have your special services team, you’re having the conversation about scaling. You have to have somewhat of a common framework and approach in how you practice and apply that. You do leave some leeway for variations in teams, and I’ve seen teams be very successful in that as long as you all still have that overarching idea where you’re connecting the dots.
In the SAFe world, you have the agile-release train in which you have your packages that you’re putting on a train at a coordinated period of time. You might be running your sprints, but you know ahead of time what package you committed to for the next release train. You put your package out there, other teams put their packages out there, and we already forecasted what packages we’re going to deliver in this quarter. We know what dependencies have to come across the different teams, and then we’re ready to roll something out. The language of coordination and how we want to do that; one team might be Kanban on 2-week sprints, and another team could be agile on 4-week sprints. Just as long as you know from a quarterly perspective what our dependencies are and that we’re continually communicating and after our scrum of scrums to coordinate.
At the team level, you still can have some flexibility, and the program level is watching the bigger picture for those touch points and dependencies. It can be very successful. This is for people that worry about if we have to be completely lockstep. I’ve been asked to come into organizations and “make all of our teams look alike. Give us the same KPIs.” The KPI is for one team; what I’m looking for is continuous process improvement. If you’re in a velocity of 40, and they’re at velocity of 20 but from a value-point perspective, the number of features you’re able to deliver at that 40 is the same they’re delivering at 20, just for the sake of numbers, why should I push them to get a velocity of 40?
Then, we start playing numbers games and making every story super big or super small. That’s not the overall goal. The goal is are they both delivering value and are they incrementally improving? In that case, what I laid out is each team quarter by quarter should make sure that we are, from a velocity and continuous process improvement perspective, seeing incremental improvement and being stable across the velocity and our delivery. That’s the consistency needed. It takes different interpretations, and it may not always be obvious.
Kupe: Yeah. You and I both live in Atlanta, now, and we saw the Atlanta Falcons lose a game Super Bowl 2017. They lost to one of the greatest franchises of all time and to the greatest quarterback of all time. The one thing that you look at about the Patriots: they have a formula. People think consistency and guidelines are unfair, like, “You can’t hold us to doing stuff the same way.” But, if you look at a team like the New England Patriots, they do have a formula. There’s a way they pick players; there’s a way on how they treat their players. They don’t have one big star on the team that requires all the attention. They like to spread the ball around, so they pick players that, for the lack of a better word, mold to the formula they have.
It works, and obviously it’s successful. They have a formula, but they’re more successful than any other football franchise in the history of the game. If they have this formula, but at the same time are playing the game, it’s not the type of formula that they’re going to throw the ball to one player all the time. It doesn’t matter who they throw the ball to. Whatever works for that particular game, that’s what they’re going to go with. Yes, there’s a formula, but there’s also, as you said, some leeway that goes on within this formula.
You and I have talked about this offline before, around you seeing teams going away from some of the ceremonies that happen on an agile team. I think that’s falling into the same bucket around consistency of processes and why you do things. With it mostly around this continuous improvement, because I know you’ve talked about retrospect and how teams just decided, “We don’t do retrospect anymore because it wasn’t helping us.” Why don’t you talk?
Jacqueline: More than anything, what I’ve found in the classes and in the Boot Camp is people lose sight of why they were doing a ceremony. With retrospect, they’re like, “We’re doing agile. We’re doing sprint week after week. We don’t need retrospects.” I kind of reinstalled that it’s never final. We’re doing agile, which is continuous process improvement, and what you have to take into consideration is the project and its life cycle is changing. You might be interacting with different shared services at different points in the project, and I think people just get comfortable. They see these ceremonies as chores and say, “If I can shortcut, isn’t that a good thing?” I want them to acknowledge, “What do we lose when we don’t do retrospects?”
One of the things – and I say this with teams – in the Boot Camp, we have different groups broken up with everyone playing roles and wearing name tags that says what their role is. I can remember walking over to a team, and I observed one person sitting off to the side while the other 4 people were dominating where they were going to go next. No one had even noticed that this person was starting to sit off to themselves. I said, “Is everybody on board here?” One person stood up and said, “Yes, we’re all on board.” I said, “I don’t think so.” From a healthy team perspective, whether it’s a coach or a scrum master, if it’s not working for one person, it’s not working. You have to take into consideration that everybody has equal weight on the team.
That’s when you have to rejuvenate the team and re-instill the agile values. Out of everything we’re looking at giving up, which of these values would have the most or the least impact, and in what way might the impact be? The full benefit of agile is the combination of making sure you, at the very least, hit those 4 agile values, and then, as you mature, hit the modern agile values, too, which I think is just some of the values on steroids. I’m excited about the modern agile values just as much, and a lot of these organizations that, say you’ve been practicing 5-7 years and you think you’ve masted the core 4, well now it’s time to step up to the ones you highlighted about the modern agile values. Don’t get complacent, and sometimes get yourself refocused and re-calibrated.
Kupe: Awesome. Are there any final thoughts you wanted to give with the State of Agile Report? Are there any key things that you didn’t get to chat about yet?
Jacqueline: I do see the language and the problems or challenges that the groups are having are now being taken to that scaled level. One of the things that it talked about, the 3rd tip on success in scaling agile, was about coaching, consulting, and training. I think some companies are being challenged because you don’t want someone to just come in and start adding to your staff and increasing your overall cost and run-rate for your project, but I think, again, sometimes it takes someone that can be an outside observer to come in and steer you in the right direction. The right partnering where you want someone that can empower the people and talk from the top-down and the bottom-up.
Something I see and have mentioned before is when you talk about going from waterfall to agile, it’s a transformation. It’s a major project, just like any other transformation, so planning and working the plan itself. I’ve helped teams set up a backlog of what is necessary, from top to bottom, to transform to agile. We then prioritize those things, and as we’re learning things, we’re adding to that backlog to make it, back to continuous process improvement, visible.
It’s important to the teams down below, because sometimes it feels like management is just pushing agile on top of them vs. management showing visually how everybody is taking on that change, mindset, and culture and are making adjustments so they can see where some of those new culture-type activities are being addressed in order to lessen the burden of it just being carried at the team level. I’ve seen a lot of success with that.
Partnering with the right person, continuous process improvement, and it being a top-down transformation can help. Those are the main things I will leave with. There are some other areas about what tools to use, and you mentioned this, too. Before you think about exactly what tool, sometimes you have to first address the culture and be honest with yourself on why you’re doing this transformation. Is the time frame you’re doing it in realistic? Make it realistic to give everybody an opportunity, because a lot of times you’re going to go slower before you can go faster. In the end, it will be worth it. It’s an investment.
Kupe: Awesome. I think the report even highlighted it. You were talking about getting the outside help or the outside view is critical. I think the way you explained it is what’s necessary. Having a coach there full time is not critical, but definitely having one at critical points to keep you on track with that continuous improvement.
Jacqueline: The one last thing I will say is along the lines of six sigma and transformation. For an analyst like myself who has that six sigma background, this is our sweet spot. Seeing these transformations and helping with these transformations: this is our sweet spot. I really think from an enterprise, analyst, and from those people who have been a part of corporate change – organizations need to take a second look at analysts that have done this for the business side to help, because agile affects both the technology side and the business side.
You may have some hidden talents in your midst, and this is the time to cultivate them. Through our boot camps, we empower them to go back and be a part of those transformations and being that change agent. That’s the other thing I wanted to help connect the dots of. The analyst being not just a team player but leading the enterprise change.
Kupe: That’s a great point, and that’s our motto, too, at B2T. You hire really smart people. We want to help empower them so that you can get the most out of them to help with the success of your organization. Thank you for all of the insight you’ve provided, Jacqueline. I’m going to turn it back to you to wrap us up.
Jacqueline: Absolutely. It has been another great episode. Time flies when you’re talking and you have such a great topic and such a great host. You were the host today.
Kupe: Yeah, I kind of played host. We can go back and forth.
Jacqueline: Good job. I’m taking some tips from you, to just jump in and say, “Time’s up. Next!” We enjoy sharing this insight, and I love this format. Always want to remind our audience: we did a short episode, but we also do 90-minute episodes. Connect with us on Twitter. I’m always posting surveys out there. Also connect with us at b2ttraining.com. I’m email@example.com, and Kupe is firstname.lastname@example.org.
Kupe: And I’m @Kupe on Twitter.
Jacqueline: Excellent. Thank you again for listening.
If you have a question or comment, call 855-484-6837, leave a message and we’ll read it on our next episode. Also, please visit our Tech Expresso Cafe page on iTunes for this and other series!
Please enjoy our other episodes:
- Episode 1 | December 8, 2015: Podcast launch and general overview of business analysis today
- Episode 2 | December 22, 2015: 2015 in Review and Set Your Expectations for 2016
- Episode 3 | January 5, 2016: Your Business Analyst Career Path
- Episode 4 | January 19, 2016: Business Analysis Role Fits in Many Careers
- Episode 5 | February 9, 2016: Overcoming Business Analysis Project Failures
- Episode 6 | February 23, 2016: Good Business Analyst vs. Bad Business Analyst
- Episode 7 | March 8, 2016: Business Analyst FAQs
- Episode 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: Back to Business Analysis Basics
- Episode 18 | October 4, 2016: More Business Analysis Basics
- Episode 19 | November 3, 2016: Live from #BBCCon
- Episode 20 | November 15, 2016: Effectively Give and Receive Feedback
- Episode 21 | December 8, 2016: Business Analysis in 2016
- Episode 22 | January 10, 2017: Business Analysis in 2017
- Episode 23 | January 24, 2017: Is Agile a Methodology?
- Episode 24 | January 27, 2017: An Agile Mindset
- Episode 26 | February 28, 2017: Are BAs Becoming Obsolete?
- #AskAnAnalyst Podcast Episode 26: Are BAs Becoming Obsolete? - February 28, 2017
- #AskAnAnalyst Podcast Episode 25: State of Agile - February 7, 2017
- #AskAnAnalyst Podcast Episode 24: An Agile Mindset - January 27, 2017
- A Monthly Guide to Becoming a Better Business Analysis Professional - January 11, 2017
- #AskAnAnalyst Podcast Episode 22: Business Analysis in 2017 - January 10, 2017
- #AskAnAnalyst Podcast Episode 21: Business Analysis in 2016 - December 8, 2016
- #AskAnAnalyst Podcast Episode 20: Effectively Give and Receive Feedback - November 15, 2016
- #AskAnAnalyst Podcast Episode 19: Live from #BBCCon - November 3, 2016
- #AskAnAnalyst Podcast Episode 18: More Business Analysis Basics - October 4, 2016
- #AskAnAnalyst Podcast Episode 17: Back to Business Analysis Basics - September 13, 2016