How to Get Buy-In for Agile Methodology
Member shares passionate perspective of how Agile can be utilized in any environment and how to get buy-in.
Moderator: David is asking about Agile experiences. Where has it worked, and where has it not worked?
Lisa Z: This was one that I really was excited to hear about, if I could share a little perspective. I have been doing Agile since the nineties, actually, before it was even called Agile. I would tell you, Agile can apply anywhere. The value of Agile is that it can be modeled, and the different components under Agile, you know, the different methodologies under Agile, can be applied as needed.
We are actually using pieces of Agile, components of different Agile methodologies, on infrastructure projects. That is not something that anybody would have put as a potential for an Agile project, right? Because those are ginormous; they are deeply technical, enterprise-wide types of things. So, you know, I love Agile. I would say it could work in almost any situation.
Topic: Managing scope change
Aaron E.: Lisa, do you find yourself, for these projects that you are using Agile with, because in the past, my experience has been, there needs to be at least some flexibility in the schedule or in the cost. From what you are saying, it does not sound like that is necessarily the case.
So, I am wondering how you handle, I guess, the changing scope. Maybe I am thinking of Agile incorrectly, but if there is changing scope, how do you manage that, and I guess, how do you kind of allow your stakeholders to understand that the best interest of them is what is driving this, and it is not necessarily the cost or the schedule?
Lisa Z.: You know, that is an exceptional question. Regardless of the methodology, we are still bound to that triple constraint, the cost, the scope, and the time, right? Agile can be very challenging to your point, especially with new introductions of Agile in an environment. Even initially, the scoping and sizing at the beginning of a new Agile project can be pretty squishy.
So, it is managing those expectations and understanding what we are trying to do at the end. One of the things that I always say is, there is not a component in Waterfall, per se, in that traditional software development lifecycle, that is not used in Agile. It is just used differently.
For example, when we start out, we are only defining what is good enough, what the happy path is. Oftentimes what you will try to do, and what we try to do in the Waterfall methodology, is solve for everything, right? I think one of values in Agile is that we tend to focus our resources on, with the business and actually the technical side, identifying at the highest priority.
So, we are really reallocating our resources to the things that we know deliver the greatest value, and then, through the backlog process, work down. Some of those things, by the time you are done, may not have any value, and you are able to say, you know, do we move this into another phase, do we still need this?
I hope I am explaining this clearly. I think it is a reallocation of resources within that same scope, budget, and timeframe, but focused on the things that we all agree deliver the most value, instead of equally across the entire project or the lifecycle. Does that make sense?
Topic: Stakeholder buy-in
Aaron E.: Yes, it does. I appreciate you explaining that. Just, I guess, to add one more question to that, from what you are explaining, I am trying to run this through my environment, and it seems like you would absolutely have to have strong buy-in from your key stakeholders or from, you know, leadership. I do not see how this could work without that. Is that correct?
Lisa Z.: That is really crucial. I mean, one of the ways that you can do that is grass-roots, if you do not get it immediate support from the top. But, it is important, and the reason it is, you know, in a for-profit environment, and I have implemented Agile in government as well as for-profit, everybody has day jobs, but there are very tight metrics associated and deliverables associated for those for-profit roles that you need to have engaged.
So, having the support of your leadership team that this is important, that you really own this and that is why we really want you to be engaged in this, you know, the business message, is really great. I mean, it is a critical success factor.
I would say I have never seen a technical team not willing to go feet first into Agile. They are really excited about it. The challenge that I have encountered for the most part is helping the business understand why it is important that they become engaged, that they really now own their own destiny, and that we are collaborating.
The separation of church and state between IT and the business, we take that away. Let's work together. Let's build it the way that you want. Let's do it right the first time. Let's do it more quickly. So, they get pretty excited when they get that message and they have support.
Topic: Managing resistance to Agile adoption
Moderator: Thanks for that, Lisa. I put up this next topic. You may have kind of touched on it. It is asking; how do you introduce Agile into large corporations that have an established process where there may be some resistance? Why don't we just change that to any corporation where they may have an established process and where there may be resistance? How do you introduce it?
Lisa Z.: Let me tell you a story that I have used, actually an approach that I have used over and over. What I will do is I will solicit volunteers. This is within the business side, your thought leaders. You know, I would really like you to walk through something with me and get your feedback. Are we on track? Does this meet your expectations? What have we not thought about? Get them together and actually break them up into small groups.
Where I start is, I walk through a process, booking a hotel room. I say to them, there are no wrong answers here. Now, I want to book a hotel room, and I start with a user story, right? I need to be able to book a hotel room in Kansas City, because I want to go to the art festival. Yes, this is clear to everybody.
The next stage is, is that enough to book a hotel room? Why or why not? No wrong answers. I take them through high levels, using this example, some of the components that are in a use case. What would have to happen to be successful? What are some of the rules that apply no matter how you are booking that hotel room?
For example, whether you are calling in, whether you are a Hilton Honors members, whether you are a Priceline shop, what are some of the rules that apply across the board? You know, you have to have a credit card to book the room. You have to cancel by 6:00 not to get a penalty.
So, I kind of walk them through this, and I take them through high levels in a scenario that they understand. Then, I introduce them to a user story that relates to a project. I break them up into groups and have them do each component of the user story and come back together.
But, I should back up. Before I do any of this, I walk them through the process we have lived through and are living through today, which is your traditional, linear software development lifecycle process, where you say, you guys define the need up-front, and you help with the requirements. I show them all the steps in the process that happen before they see it the next time, which could be, in some companies, user acceptance testing, or it could be production.
Everyone in that room has lived through that scenario, where they have seen at the end, either at new AT (?) or in production, it is not what they expected at the beginning of the process. We have all lived through that, right?
What I do then is compare and contrast that to the cyclical nature of Agile, where we define up-front, what are those rules that will apply no matter what? What are the conditions of acceptance? How are we going to test it? This is for our user story. How are we going to test it, and what does it look like when it is done? Who is using this? Is it different for the different users? OK, we build a little bit, you look at it, and you say, yes, I like that. It is done here. Or, no, we did not think about this, this needs to be different. We build a little bit more, you look at it, and it is done here. Or, it could go into a full circle.
Through this process of walking them through the existing environment, helping them to kind of understand the difference between the two approaches and their engagement, taking them through this hotel booking case, and then actually hands-on in this workshop having them take a user story and break down what they just learned, it is phenomenal. The feedback that I get 100% of the time is like this. You know, I have worked at this company for 15 years, and nobody has ever asked me my opinion. We have never done anything like this. Can we do this on everything?
So, it is very, very exciting. I call it an edu-sell. It is educating them on the change, how they are engaged, and how they can adopt it, how simple it really is, and why it is important that they are a part of the team, helping them to sell the concept throughout the organization. Does that make sense?
Moderator: Great story. Does anybody have follow-up?
Jack C.: In regards to what she just said and the question up there, as far as a large corporation, I can understand if you have a small group or a small business having those users feel involved. But, if you really do have a large corporatization, then you have got to separate out just logistically how many people you can talk to and have involved in the process.
So, how do you keep the same old just a few people kind of design the system in a larger corporation, entering into what she just described?
Lisa Z.: Well, I should explain to you that I introduced Agile to PayPal for the implementation of Pegasystems. Now, if you are familiar with either organization, PayPal is very large. We have three major offices in the United States, in Dublin, and in Singapore. Pegasystems is one of the most complex but phenomenal tools on the market. We did both at the same time, introduced Agile to implement Pega. We essentially did it the same way, but we started with the leadership. We took the leadership through that process at the strategic level.
Then, we took the operational level through the process, because what the operational folks really needed to understand is, what do you need from me? You know, what is it going to do for my staff, right? When are you going to need my staff?
We started at the top through the essentially the same process, went to the operational level, and then we identified the staff around the globe that would be engaged on the business side. It worked. You can do this in a small company but the model scales.
Topic: Selecting Agile team members
Jack C.: What were some of the attributes of the people you identified from the staff? I mean, clearly those people are not shy and more engaged and probably more super user type people, I guess. Is that right?
Lisa Z.: That really is important, because those folks become your liaison to the rest of the business. They also become the change agent to help everyone to adopt this. After the implementation, they become your first line of--I do not want to say first line of defense, but they are the first points of contact within the business before it hits your service desk, because they have already gone through it.
Jack C.: In this case, maybe, did they have already some business functional analysts who already had sort of a role in IT as professional people who did this? Or did they end up kind of becoming that, or do you try to avoid those types of people, or what?
Lisa Z.: There is a big debate within Agile as to the role of a business analyst. My experience is, absolutely use a BA if it is appropriate for your business. That is what is important, is if a BA is a critical role to be successful in this model, use a BA. You know, do not listen to what you might have heard. In this scenario, we had product managers that reported to me that wore three hats.
They wore the hat of a product manager, they wore the hat of a project manager or Scrum Master, and they wore the hat of the business analyst. So, they had, then, folks within their businesses that helped fulfill some of that business analysis piece, but ultimately they were leading the charge for the different business units.
