So We need to be Agile! now what? -...

1

Getting After Every Outcome

How Agile May Be the Best (Or the Worst) Thing That

Happens To Your Team

A Guidacent Special Report

So...you got the word, “We need to be Agile!”, now what?

© 2018 Guidacent Consulting, Seattle, WA

What makes a successful Agile Transformation?

What are three things you absolutely need to know?

How do you put LEAN and Agile together to truly transform?

When it comes to Agile and Agile Transformation, these are just a few of the critical questions you need to answer to make sure you’re heading towards the BEST and not the WORST decision you and your team ever made.

To help our clients and invited guests answer these and other critical questions, Guidacent Consulting made Agile and Agile transformation, the focus of our Quarterly Roundtable event at the Seattle Yacht Club on April 19, 2018. This sold-out event featured a panel of three industry experts: Leslie Ekas, Expedia, VP Technology; Todd Wilson, REI, Director, Software Engineering; and Matt Deisher, Costco Travel, Director of IT Delivery. Along with Guidacent’s own Agile expert, Senior Consultant, Shoonya Mohanrao, who acted as host and discussion moderator for the evening.

The insight and information provided by our panel that evening was so spectacular we decided to publish all the questions and all the answers from our panel in this special report. There is also an audio recording of this event featured on the “Insights” section of our website.

Shoonya: Let’s start off with the question ‘What benefits should we expect from an Agile transformation?’ Leslie would you like to start?

Leslie: The reason that I got excited about Agile and the reason I'm still excited about Agile is that Agile, done well, gives you the ability to be responsive to changing business needs. In the old fashioned waterfall world that I grew up in, we had big plans. They took a long time….

2

A Guidacent Special Report: How Agile May Be the Best (Or the Worst) Thing That Happens To Your Team

...you'd go dark in development and by the time you came out, no one knew what you were doing. The business had changed what they wanted and it was awful, on a repeated basis. We actually delivered great software but it didn't always meet the needs of our clients. That really frustrated me and I didn't know how to fix it. I was entrenched in the way that we were building software. Agile to me was the first time I had really seen a technique that allowed you to be responsive to what the business

wanted. And I thought that was game changing. So that's what I've always pursued when I've tried to adopt Agile and help teams adopt Agile. There's a lot that you can expect from it, but the game changer is responding to changing business needs. That’s special because our world is a fast changing world. I'm at Expedia, we’re in travel and it changes constantly. If we can't respond to the needs of the business and how we build technology we will get behind and we will lose.

Todd: Certainly being responsive to the business is one of those key aspects and that was one of our major drivers when we looked at Agile 10 years ago. Some of the things that were obvious to us included having disparate teams

working in different areas and the handoffs were killing us from a response standpoint. Also we were putting out these big releases that were multi-month efforts. What we saw as we implemented Agile is that we were able to break these down into smaller problems, more incremental releases and as a result, lowered the risk from a delivery standpoint. That may be a canned response about an Agile transformation, but the benefits of Agile are real.

Matt: The environment that your business partners are operating in today is unlike any time in history. People are teaching classes on disruption and the focus on technology has become a significantly larger component of the business. Now it is a driver of business and as competitors are shifting and the market is changing, companies need to be able to react. As technology partners we need to adjust. If you're going dark for six months or a year as you're building technology, by the time you surface the business has already moved on and you're not there to support them. That’s the number one thing, just being able to be in lockstep with them, to be able to react to the crazy business they are in.

Shoonya: So it is the speed of change and being able to keep up with the business?

Leslie: I think that's it. And another thing that I would add is that because you can respond and stay in lock step with where the business is going, and remain engaged with your customers and stakehold-ers, you can actually start to deliver more of what they want. They're able to see what you're doing in much more real time so that you can quickly adjust as you're developing capabilities for them. So, it is speed, it is responsiveness, but it's also delivering what your customers need - and their needs change. By the time they see what you're delivering, they have a new visualization of what they need. So, it's a constantly moving relationship that you have to have a way to respond to. Agile allows for that response.

Shoonya: I'm curious, what attracted you to Agile? Was it already there or did you bring it in to the company and pursue the transformation?

Matt: Much of my Agile transformation experience was actually at Nordstrom. Before Agile, Nordstrom was hardcore waterfall, everything we did was waterfall and we were really good at it, but we didn’t realize that the world was changing around us, especially in eCommerce, and we couldn't respond to the business needs fast enough. So our senior leaders, who were closer to that pain, saw the issues coming and started realizing, “How do we get more nimble? How do we react? How do we become this new team that our business partners need?” So they went out and started searching for different methodologies trying to understand the landscape and who had gone through similar journeys. They ended up talking to Visa Business among other companies and learned about the Scaled Agile Framework. So they brought that back and said, “Hey everybody, we're doing the Scaled Agile Framework, let's go.” We had no idea what we were doing. But that’s when we started the Agile journey.

“Agile to me was the first time I had really seen a

technique that allowed you to be

responsive to what the business wanted. And I thought that was game

changing.”


3

Shoonya: But then after you did it, you saw the benefits.

Matt: It was interesting. When we tried it in eCommerce it was painful. We didn't know what we were doing and we were trying to figure it out. Our PMO was fantastic and they were smart enough to hire some great Agile coaches. We didn't even know enough to know we needed them, but they came in and we’d get an hour with an Agile coach a day. That just wasn't enough by the way. We were really making a mess out of it. But we did learn a lot by stubbing our toes along the way. Fast forward a couple of years when I moved back into merchandising, which wasn't fully embracing Agile and still very much waterfall, and there was a master data management platform that I was supporting. I realized it was an opportunity to learn from the scar tissue created from our Agile attempt in eCommerce, and take another run at it. Coming out the backside, it was fantastic. It's funny but when you’re closer to the business, you end up having empathy for your business partners through this process because you’re operating side-by-side and delivering at a much faster rate. The side effect becomes this weird kind of empathy that you have in connection with your business partners.

Shoonya: Leslie do you feel the same way?

Leslie: Going back to the question of how it happened with me, I had done waterfall for a long time. I ’d spent many years managing teams that were building enterprise software and I actually hated it. I was ready to get out of software. I have had five huge personal burnouts because I've done the big waterfall swing at the end where you finally put all your code together and try to make it work, and spent nights and weekends living at the office. I was disappointed in the sorts of things that we delivered to our customers. We were doing really good engineering. I just didn't think that we were delivering what we needed to deliver to our customers and I lived through the nineties where we tried to fix everything by applying a process to it, which was beyond horri-ble to me on top of what we were already doing. You'd fix the problem by working a process around the prob-lem versus fixing the problem.

So given all that, I was at a company that got acquired by IBM, when IBM was just getting into Agile. They picked a group from within each brand to go learn Agile. I was lucky enough to get picked because I was a big complainer. They said, “Go away and learn something else”. So I got immersed in a program with Tom and Mary Poppendieck, early experts on LEAN software development and Agile. It was like going to brainwashing camp where they get you out of your old thinking and then immerse you into something else. It was so amazing to me because they came from a LEAN mindset, and we went through a couple of days of revolutionary ideas like, quit prioritizing your defects and either fix them or get rid of them. That was life changing to me to think about because I've lost person-months if not person-years, prioritizing defects and doing things that we did in the old world. At the end of the day, I stumbled into Agile and I felt lucky that I had, because it was incredibly life changing – the ideas about how you could do things differently.

Shoonya: So, the LEAN mindset leads into Agile. Todd, how do you put LEAN and Agile together in terms of getting a benefit for the entire transformation? How are you doing that today?

Todd: Well, right now LEAN is being rolled out across the company in a very pragmatic way. We’re not making everyone a six sigma black belt, but more like, how do we use LEAN techniques to do things like problem solving, leveraging value streams to identify problems, and how do we become great operators? When we first implemented Agile 10 years ago, we did a scrum implementation and we had really good alignment all the way up to the executive level and good alignment between technology and business, so that went well. There have been ebbs and flows – some things we've done better than others and we're at a point now where we're trying to come back, to get better at Agile. We had gotten pretty loose with how the teams operate and so we're trying to bring that back, but we've also had a lot of leadership change across both the business as well as the executive team and technology. So all the work we did with those executives early on to get them versed in Agile and teach them how to operate and understand the delivery process is gone. Now we’re getting new executives that come in and may or may not be versed in Agile or understand how it operates. So the pendulum has swung and we're in this phase now where we're ready to bring the executive team back on board with Agile. What's been great is, because they're becoming versed in LEAN, they are able...


“...but we did learn a lot by stubbing our toes along the way.”


4

...to understand a lot of Agile concepts because these concepts were born out of LEAN. In other words, it's an easy way to say, “We're doing this Agile software development, which is part of being LEAN”, so they bridge very nicely. Now we're starting to think about it more and more on the value side of the equation. That’s where we’ve gone wrong, not putting enough emphasis on the value that you're looking to deliver for a particular sprint. Then, what are the KPIs that are measurable that come out of that sprint or pro-ject? Much of that is LEAN 101. So that's how I see it fitting together, it's creating a nice umbrella for us to roll deeper into software delivery and how we do it.

Shoonya: I don’t think I heard from you Todd, what attracted you to Agile? What's the one thing you love about it or why are you doing it other than the fact that it's your job description?

Todd: Honestly the thing I love most about Agile is the engagement that it creates with the teams. The empowerment that comes if you're doing a true Agile implementation. Teams are very empowered and with that empowerment comes engagement. Earlier in my career I was part of IBM when they were working to make RUP (Rational Unified Process) more Agile, and it was more about “just get it done and out the door”. But then when I came to REI as a software engineer, they were a more mature development shop. Working in that environment as a developer was fulfilling, and then moving into management, we had a set of managers and directors that recognized the power of Agile. So it was easy for me - not easy to do the implementation, but to get buy in, enthusiasm and support.

Shoonya: What are the top three factors to a successful Agile transformation? We have talked about handoffs, being in lockstep with the business and LEAN, among other things. Is it the methods? Is it the roles? What do you think the top success factors are?

Matt: Ironically, I would say the big difference that we had between our eCommerce challenges and the suc-cess in merchandising was our product managers and having that product management layer act as a con-duit. When you're in an Agile context and you've got all these different teams and business units asking for things, it’s impossible to make anybody happy. The more you can funnel that into a product manage-ment layer that sets the priority, allows your delivery teams to actually focus on building software and not respond to all the noise, the better you’ll be. We ended up with a product manager in merchandising where I had a love-hate relationship. I hated the guy at times when he was facing us, but I loved him when he was facing outbound and he was able to handle the chaos of the business.

The business was reacting to Amazon, or whoever, and all of that chaos would come right into our delivery team. Our product manager was essential in terms of being a filter and a buffer. The more you can pull that noise out of your delivery team and let them focus on the software, the better.

Also, making sure we had the right coaching. I am not an Agile expert. I will probably never write a book. But I was smart enough to realize I needed experts. So I pulled a couple of Agile coaches out of our PMO, and made one a delivery manager and one a scrum master with the bigger mission of making sure that all the other scrum masters were mentored. They brought a lot of Agile expertise, but they also brought waterfall expertise because that was their bread and butter prior to moving into the Agile space. So I was able to leverage them to interface into a lot of our waterfall teams to make the conversion. That approach helped provide confidence that we were going to deliver what we said we were going to do and create the plan to do it. That was big.

“Honestly the thing I love most about Agile is the engagement

that it creates with the teams.

The empowerment that comes if you’re doing a true Agile

implementation.”



5

Shoonya: Leslie, what are your top three success factors for an Agile transformation?

Leslie: There are a couple of ways that I would approach this after working with a variety of teams and watching what works and what doesn't work. First of all, Agile covers a whole lot of how you work, how you work together, how you do things. It's extremely broad and it's hard to do, but critical to learn and start to adopt. I believe what you should do is first is be selective about where you want to start. It’s not easy to succeed. This is hard, so figure out where you are as a team and where you think is a good place to get going. Agile is hard from day one and as you get going and when it starts getting hard, you unconsciously do the things you're comfortable doing, which is why we talk about water-falling backwards. We see this happen over and over again. The minute it gets hard, which is literally day one, you fall back into your old patterns immediately, which is what will defeat you. So it's so critical to remember why you're doing what you're doing. I remember teams in the earliest days would say, “I do sprints, I do daily stand ups -- therefore we're Agile.” No, those are just mech-anisms to help you understand the principles of what you're trying to get, which is building quality with short feedback loops.

You've got to get into your mindset why you are doing things. What are the principles that you're going for? It’s not about doing sprints the right way. Again, the key thing that I learned early, is that Agile is quite hard to do and I'm serious that truly you’re not Agile unless you learn how to continuously improve. And it's hard to do that. It's very hard for teams to look at what they're doing and constantly make tweaks moving forward. The game changer to me with Agile is continuous improvement at the end of all of it. Keep trying to find ways to get better. There isn't a perfect Agile way. I don't think there's any perfect way to do anything. We're learning and if we aren't learning, we aren't making Agile better. The first team that I worked with was with Mary Poppendieck and she pushed me hard to keep trying to fix this one problem that we had. The teams wouldn't talk to each other and work together. Imagine. No, it's totally normal, but we had the problem over and over and over again until we actually found something that worked with that particular team. We didn't know that we could get better. We didn't know how to do it and we didn't believe in it. So you've got to learn how to get better. That's super critical. Agile is really tough. You've got to stick with it and you've got to train yourself to keep improving.

Shoonya: You talked about how hard it is. It's fine to convince yourself that you have to keep doing it. How did you convince your teams to do it or what was that success factor that convinced the teams?

Leslie: Well you need some early successes. Stick with things long enough to get success. I went through months and months where I really was about to give up on it and as a team we had gone all in at the beginning saying we're going to give this a try. We kept pushing and we actually got an outside consultant to assess what was going on with us. I almost gave up after about six months. But when we finally had our first breakthrough, the team changed forever and the team believed they could do it and it was a different feeling. So you've got to stick with it and you have to see a visible change in something that you're doing.

Shoonya: Matt, you talked about the product manager first and many places I've been have different definitions, so what is the product manager is supposed to do? Whose team are they on?

Matt: The model that we used at Nordstrom is that they reported into the business, so they were in alignment with the business strategies, but they were also able to articulate priority in executing technology. We need that capability at the horizon and then we can start to work back, estimating, and breaking down our releases. At Costco Travel our product management team is part of technology. It's a different dynamic. If you’re with the business, you're a little detached from technology, if you're in technology you’re a little detached from the business. So it's figuring out what's best for your organization.

“The game changer to me with Agile is

continuous improvement

at the end of all of it.

Keep trying to find ways to get better.”



6

Shoonya: Can you tell us what that breakthrough was and why you think it was a breakthrough?

Leslie: Absolutely. We had a fairly large team by what you'd call a good Agile team size. It was the whole range of development, test, product, program, and we were trying to do one month sprints (which I no longer believe in). We were really struggling and we would have reflections, and at every single reflection we all talked about how we weren't working well together. This team wasn't working well with that

team, and this was back in the day when we were all co-located. So we didn't really have the non co-location problem. In fact, we all sat very close to each oth-er and I'd have somebody coming in and saying, he didn't say this to me and she didn't include me in that meeting, and they made this decision without me and this went on and on and on, with tears and anxiety. It was awful. So Mary Poppendieck said, “Leslie, you guys have to fix this problem.” I was desperate and we kept trying things. We'd say, all right, we're sticking with the same problem, and we’d try something and it didn't work, and we try something else and it didn't work, and tried something else and it didn't work. We were all pretty much at our wits end. We knew we had the problem. We knew we needed to talk

to each other and somehow that just couldn't happen. So we had an external coach come in and he sat us all down and we had a big conversation about how we were working. He said, “I think you guys should try bullpens.” And we said, so what's a bullpen? His description of it was, a two to three hour meeting where you don't meet and discuss status, you meet and do real work together.

Everybody in the team, everybody in the pod, has to be at the meeting and they have to be paying atten-tion. They have to attend in one form or another. You may not be an active participant in whatever we’re talking about, but there's no excuses for not being there. You do work together. Then came a bunch of questions and the same complaints – “we don't want to do it”, the whining and blah, blah, blah. I was the leader of the team, so I just called management rank and I said, “we're going to try it tomorrow and we'll do it for two hours and this is what we're going to do.” Everybody grumbled off and we tried the bullpen meeting the next day, and we didn't really know how to start. Finally, one guy volunteered and said, “I'm coding this and I'm having this problem.” He started to show his code and what the issues were and im-mediately got feedback on, “hey, you know, there's another way you could solve this problem. We could help you do this.” Literally from then on the meeting just took on a life of its own and the team started working together. It was the most remarkable thing to watch and the team loved it so much that they ended up doing it two to three days a week and I kid you not, the team visibly looked different in the weeks that followed because they started working together.

They started to learn how to work together and it was what worked for them and by the way, my email went down by two thirds be-cause people we're talking with each other in real time. The key is teams have to find what works for them. But literally the team knew that things had changed, we hit our next reflection and that wasn't our problem. We then tackled the next problem. Try different things. Each team's got to know that they can start fixing problems and it's not going to be the same fix for every team.

Shoonya: Leslie, you talked about two ways in which you had teams fixed - you talked about bullpens…tell us about the reflections.

Leslie: The reflections are the reviews. At the end of every sprint have a 15 minute reflection. What did we do well? What could we fix? What's the next thing? What's the biggest thing getting in our way? I really recommend if teams aren't doing reflections, get into the practice of doing them. Keep it quick, you don't want to marinate in problems. That's not going to help you. Pick a problem, try something and then move on. Keep trying to get better.

“We were all pretty much at our wits end. We knew

we had the problem. We knew we needed to talk to each other and somehow that just couldn't happen.”

“...and I kid you not, the team visibly looked

different in the weeks that followed because they

started working together.”



7

Shoonya: Todd, what are three top success factors for you?

Todd: I'll talk about the conditions that made our original implementation successful. Some of these maybe weren't the right idea, but at the time it helped boost us. There's the financial component to Agile or working in a product based way. Ten years ago each of our brick and mortar stores had a one percent fund. In other words, each year they got one percent of their revenue back to do store improvements and maintenance. Our VP of eCommerce at the time made the case that the online store should also get a one percent fund. He got the executives to buy into it, so all of a sudden he had $7,000,000 to spend on improvements to the website. Next, our director for eCommerce and the director in IT that led delivery for eCommerce were in lockstep, they were progressive thinkers, and at the time Agile was becoming more mainstream. We knew that Agile was the next evolution of how we wanted to deliver software. So the $7,000,000 sat outside of IT and it didn't go through the traditional IT governance process. It was basically there for us to spend. So we took our teams, broke them up into six or seven products, essentially a check out team, a search team, and so on. That launched our transformation and allowed us to bolster efforts with coaching. However, we definitely had some outliers that didn't like moving out of traditional roles and into cross functional teams.

Shoonya: They didn’t like the concept of Agile? How did you know when your teams were ready for Agile?

Todd: There was a lot of demand to move to a more Agile delivery process. So take that financial model or that financial freedom, sponsorship, and then two directors that are aligned and ready to go. Then at the time we had brought in a vendor to do our production support. Prior to that the teams were always on call. It worked to outsource it because it eliminated all of that churn and noise that came with production support. It moved that out of the team so the teams could focus on product delivery. So those three elements together really allowed us to get the ball rolling. Don’t get me wrong, a lot of things we did were mistakes and we're coming full circle with some of it. But, that's a practical story of how we initially kicked off our transformation.

Shoonya: What are the common pitfalls of an Agile transformation? How do you avoid these from your experience?

Todd: You've got to be aware of the downstream teams that are going to be a recipient of the software. What happened with us is that we were successful in delivering more software and more capabilities, but we never addressed what happens when that software gets shipped down to the infra-structure teams to deploy it. Interestingly enough, after we had kicked off our Agile transformation and I moved over to manage an infrastructure team that was responsible for middleware and database, it created a lot more work for them. We were getting all this software cranked out, but no one addressed how would we deploy more quickly, it just became more demand on the infra-structure teams to deploy the software and support database requests.

Shoonya: So the infrastructure team is not upstream but downstream?

Todd: Well, in our case we had established infrastructure because this was eCommerce. We were doing database changes that had to go to the DBAs and when a release was ready, there was another infrastructure team that deployed that. All of a sudden we're getting all these new releases and trying to keep up. The moral of that story is, you've got to figure out how you address the architecture and the underlying deployment if you really want to get the benefit of Agile, you want to be able to deploy that software more frequently and be more iterative and reactive. We suffered through that for a while and then we aligned on our continuous delivery journey. Since then we've reduced that cycle time to get to production.

“You’ve got to be aware of the downstream teams that are

going to be a recipient of the

software.”



8

Shoonya: So one of the pitfalls is not understanding the downstream or upstream teams and how they're affected by what you're doing.

Todd: It goes back to the whole value stream. You can improve the speed of a software team, but if they're dependent on infrastructure for deploying, you're not going to be able to get that quick delivery, unless you figure out how to address that.

Shoonya: How did you solve it though? Did you bring the infrastructure team into the Agile frame-work?

Todd: We did. DevOps was still grassroots at that time, but that's when we were able to start applying some of the Agile techniques. We started adopting Kanban within the infrastructure team and then we started embedding infrastructure engineers with our platform team. We weren't just building automation at the software level, we were starting to push automation down to the server level so that we could complete the whole value stream and get code out to production.

Shoonya: So I got two things, automation was one of the ways in which you addressed the issue and then integrating with the infrastructure team was the other one.

Todd: If you're not at the point where you have self service capabilities for the developers, then you want to have teams working side by side to promote automation.

Leslie: I agree. One of the things you mentioned - a challenge teams have in terms of going Agile is being able to move quickly enough because of their build processes, their test processes, their ability to turn around, stay on the same working piece of software…as modern as we are, we lag. We allow ourselves to get be-hind on having a good build, having the capability to constantly test as we go, having a CI/CD (continuous integration and continuous delivery) pipeline that works. That's all really hard to build and if you don't keep the rigor of having working software working so that you're turning things around quickly, it's going

to be tough to succeed with Agile.

You're going to be trying to do everything else when the car isn't running very well to start with. Therefore, one of the things to think about when you're starting Agile is to look at your working software strategy. Meaning how well are you doing CI/CD? How well are you doing test automation? How well can you keep that engine running, to enable Agile to work? The second part that I see with teams is that they don’t commit. They are used to what they’ve always done. So they go halfway in, “I'm going to try this, but I'm go-ing to hang out with half of my old behavior”, which is really a disaster. You have to go all in on the things you go all in on, and work to make them work. I'm not a believer that you can do “halfway Agile”. You can't have sprints that don't get to done. You can do mini-waterfalls, but you will not get what you can get out of Agile. So one, having the infrastructure so that you can move

software through the sprint cycle very quickly in a rigorous way that you maintain quality and two, when you go do it, go do it. Jump off the cliff, don't hang out at the edge and dip your foot into Agile. I've never seen it work well that way.

Shoonya: Any other thoughts?

Matt: One of the big things is expectation setting – both internal and external. During the Nordstrom eCommerce tran-sition, we were switching our methodology at the same time as we increased our technology spend by 25 per-cent. We were accelerating into an environment that we’d never done before. So make sure you are expectation-setting with the business. As soon as you say you're going to go Agile, first thing that they hear is, “Awesome, all the technology you used to deliver every year, now we're going to get it every month, right?” The reality is mak-ing sure they understand that that's not going to be the case. The other piece which is both external and internal is the learning curve as you're transitioning over. I was going through some old artifacts and looking at ...

“I’m not a believer that you can do “halfway Agile”. You can’t have sprints that don’t

get done.

You can do mini-waterfalls, but you will not get what

you can get out of Agile.”



9

Shoonya: How long should it take for an individual delivery team to become Agile in your experience?

Todd: I don't know if there is a good answer to that. If you're not seeing results in a few months, to some extent then you know, take a look at what you're doing, because there's going to be a J curve. You're going to go through a trough where you're going to get worse before you get better, but you want to try to get out of that as quickly as you can.

Shoonya: So, take a few months of a test drive. See if you get better, and evaluate what happens. That's a very Agile answer. So does wAgile or Agilefall exist? How do you navigate through the middle ground?

Leslie: Yes it does exist and that's because of all the things that we've talked about. It's very easy to try Agile and get nervous about it and stick to your old thing. Teams typically get very good at small waterfalls, thinking it’s Agile, until they recognize that they're do-ing that. I'd love to not see a team do that, but our natural inclination is to do what we have done before. The key is to recognize you're doing it and snap yourself out of it. That's really the tricky part because the first thing that everybody starts with in Agile are the sprint boundaries and the daily standups. The sprint boundary makes you have to do something by the end of that boundary and you get better with what that something is in terms of getting to done, and getting to done is really hard. A lot of times we waterfall our way there. So it absolutely does exist and some teams get fooled into thinking that they're there when they are doing small waterfalls. So the key is to recognize what you’re doing and find a way to really snap yourself out of it.

Shoonya: What is the right mix of training and certification versus practice and education?

Matt: I have not been impressed with the certified scrum master programs. Meaning, the one-day go away, come back a certified scrum master certification. It gives you some context if you're going to be on a delivery team and

at least it helps you understand what a product is and some of the vocabulary. But, there is no substitute for scar tissue. Getting folks in that have done it, that have learned the hard way is what is best. There are PSM programs, like one of the scrum masters that I pulled out of the PMO was what they called PSM level 4, one of 146 people in north America with that level of certification, and the guy

was dialed in, and also extremely rigid, shockingly. But it was a combination of not only the certifications but also the real hands on practical knowledge. So, if I have to pick, I'm going to take scar tissue over certifications.

Shoonya: Todd and Leslie? Same question. What is the right mix of training and certification versus practice?

Todd: I have a similar opinion as Matt. If you're assessing someone coming into the organization and you know they’ve at least had some level of training, it’s helpful. But, I think it's hard to replicate the hands on working in the trenches with teams. I generally look for more practical experience versus certifications. We didn't send all the teams off and get a certification. I'm not saying that they're not valuable, but we definitely orient more towards experience.

...velocity measurements that we have for our teams. I wanted to see if we were getting better. Are we getting faster and are teams being more effective? What we found is we got worse and worse and worse. Then we bottomed out and finally launched. At the end of the year, we were 500 percent more effective than we were when we started. But that was a big trough and it was months before we saw a measured improvement. That wasn't a sprint. That was month’s worth of sprints. Sprint over sprint, over sprint of getting worse – and us learning and trying to figure out how we do Agile. The other piece of advice is starting small. We started out in the eCommerce space with the Agile transformation because that was the area that was under the most pressure externally. Then everybody said, “Hey, this is cool, I want to go Agile too.” But not all of the other teams and systems were ready. So start small, get your legs, figure out how it works, how you do things, and then bring more and more teams online when you can actually train the trainer and support them.

“That’s really the tricky part because the first thing that everybody starts within

Agile are the sprint boundaries and the daily

standups.”

“...but there is no substitute for scar

tissue.”

“I generally look for practical experience versus certifications.”



10

Leslie: Generally I’m on the same bandwagon. What I've seen is that it helps for teams to get training on what Agile is and what the possible ways are that you can expand upon Agile. I'm a huge user-story fan. I used to

have a big session that I would do on user stories as I found tons of value in them. I want teams to understand what the basic principles of LEAN and Agile are and how to apply them. Let's understand how to do test automation frameworks or how to make that successful. Let's go look at better ways to work together, like paired programming. There's CI/CD training that you can do. I think there are a lot of areas where you can go get really valuable training and keep sprucing up the knowledge and the opportunities a team has. But I'm less impressed with what I've seen from a certification point of view because teams need to get grounded and they’ve got to expand their skillset and knowledge. One of the things that I've seen teams say is, “oh, we've got to have a scrum master, and this is their job.”

I'm a little opposed to that because what I've seen work in teams is to rotate the scrum master. You might hone in on somebody that it fits well, but it helps for everybody to play the roles in the team to understand how to be a better team. I'm a little bit less attached to doing it a certain way versus experimenting and making things work.

Shoonya: That is an interesting approach, to rotate the scrum master role. I don't think a lot of teams think to do that.

Leslie: We did that and I remember it horrified people. In reality, we found a couple of people that nobody expected would be good at it and we found that they brought something to the table that other people hadn't brought. By rotating, you experience it, you get to know what it's like to be in that position and each person brings something different to the job. Teams get better and better as you start to transfer those skills and share those skills amongst the teams, but whole teams are responsible collectively for working together to get that job done. As a team, they all have to continue to learn to work together and to even improve their own skills and expand their disciplines.

Shoonya: So if teams learn to work together and they didn't get any certifications, do you consider that more valuable?

Leslie: Yes.

Shoonya: What do you say to the folks that say we need the certification? Is that just the initial process of learning that executives, or people into getting introduced to Agile, need?

Matt: Agile is one of those methodologies where everybody's got an opinion or a style, more so than waterfall or some of these other methodologies. There's something about the Agile methodology that makes it very evangelist. People get very passionate about this is the only way, this is the right way, we have to do Agile this way. At one point I was in a similar boat where I thought I needed somebody that had some sort of baseline knowledge, so I was looking for certifications to be that baseline. If they're trained in this common way, I'm going to get some sort of consistency in my practices. It just didn't play out like that. There just wasn't enough depth or substance there.

Shoonya: Let's move to a few audience questions…

Guest 1: My question is about the people. I've been in IT for a long time. I'm curious to know from an engage-ment standpoint, how does an Agile transformation impact the people side?

Matt: My view of the universe tends to be very people-centric. I have had philosophical debates with folks, related to: if you're bad at something do it a lot, and I have this huge resistance to that because I feel like all you're doing is throwing them through a meat grinder. I think helping and supporting those folks through the transi-tion and helping them understand that they’re getting better by showing them evidence using facts and data to show that their velocity is increasing is beneficial. The counter argument is if you're really bad at build, and it’s a really painful experience, do it constantly. That doesn't resonate with me. In my early years of...

“One of the things that I’ve seen teams say is, “oh,

we've got to have a scrum master, and this is their job.” I'm a little opposed to that because what I've seen work in teams is to rotate the scrum master.”



11

...supporting that merchandising team, my role as a leader was helping them see that they were successful and helping them see that they were making progress. So we would have standups, and at the end I would say to them, “you guys see, we're doing it! We're actually starting to do this thing.” They would light up and see it. Being able to show them some metrics by letting them know that I’d been plotting their velocity for the last six sprints and outlining the im-provement was a big lift. They had no idea, because they don't see it day to day, right? They’re just in the trenches, grinding it out.

Todd: On one hand, it is really amazing to see what transformation does from a collaboration standpoint. People start working much closer to-gether than they might've previously been. I think an important aspect to that is there's the Agile training, there's the technical training, but then these people are in new situations and working on the soft skills, the communication, the empathy, those are all important aspects to recognize as well.

Leslie: From an Agile point of view, you get outed as an individual. For ex-ample, if you're a software developer and you tried paired programming, it can be terrifying. Or someone might think “Matt’s going to understand that I really don't know much about databases, and I'm going to have to tell him, and he's going to see that I don't do this very well”, or whatever. Teams go through all that. You go through all these nerves thinking that you’re exposing what you're good at and what your bad at. Then what happens in reality when you start doing it, is that doesn't happen at all. You start to help each other. It doesn't become about what you know and don't know. It's about how do you start to do this to-gether. When I see individuals go through that type of a process in various scenarios, people start to like it, but there's a ton of fear upfront, because people are getting to know you a little bit better and you may not want to tell them all the stuff that you may not think you're very good at. There's a process by which peo-ple learn how to get into these scenarios, where they find that by working closely together they learn to help each other. But that's a tough bump to go over.

Guest 2: This is in the product management space. How do you handle ongoing things, the care and feeding of your applications? So patching, lifecycle management, is that something the product manager helps with or do you handle it separately?

Leslie: That doesn't strike me as something I would want a product manager to do because I would hope that at some point, in terms of the care and feeding of the application, that process becomes a really disciplined part of how you manage your software and how you manage your releases. My desire is to have product managers be hard to find because they're out talking to the customers all the time and understanding what the market is. I feel that the care and feeding of the day to day parts of the software really belongs to the engineering group. I'm not super rigid there, but I really want product managers to have their first order of business to be with the customers.

Matt: We have a product manager that oversees one of the value streams that contains our architectural maintenance. The point is that it is a technology driven prioritization of the backlog. The product manager needs the visibility because they’ve got to manage the capacity. So it becomes a pre-negotiated conversa-tion of let's reserve X percent of our capacity for reinvesting in our platform and architectural maintenance.

Todd: What you mentioned about product management is a gray area for us because we started out with prod-uct owners and then they got rebranded as product managers, but they've still been operating as what I would consider in a product owner role. We do want them elevating and being involved with the business. So because of that, because they're engaged in sitting with the teams, they are in those conversations around prioritizing. A lot of our teams run their own software and they're doing the upgrades. For all the teams we're trying to allocate a certain percentage of time which is dedicated to maintenance, operation, and to some extent support. The product managers are involved but more just from a prioritization stand-point.


“I think an important aspect to that is there's the Agile training, there's the tech-

nical training, but then these people are in new situations

and working on the soft skills, the communication, the empathy, those are all

important aspects to rec-ognize as well. “


12


Guest 3: With Agile, speed is an important component and sometimes people can get so attached to the speed that teams start spending more time on just delivering than thinking broadly about design. So what happens is you end up with products that might be functional and usable, but they are not reli-able and scalable over the long term. So what would you propose to prevent that?

Leslie: The speed that you get from Agile, when you do Agile well, is having whole teams working together and pushing quality in as you go - building rigor into the system. The speed that I've seen teams get is not from working faster, it's from working smarter, and that's what's really hard. Not only having the rigor to have the right builds, the right pipeline, the right quality plan, the right test automation, so that you're constantly learning and building and finding problems early and fixing them, it's also about better throughput, because just speed is dangerous. You have the potential to work really fast and still work just as poorly as you do when you work really slowly. What you want to do is be working a whole lot smarter. There's a lot you can get from the rigor of good engineering practices and there's a lot you can get from the whole team learning to work together. The biggest key in improving throughput in Agile is about those two things and staying in lockstep with those constantly. With one of the teams that I recently man-aged, we made all of our pods able to work on any of the technology stacks that we had. Our ability then was when we had some of the critical work coming in, we could move people to that critical work in a sprint by sprint basis and get that work done. The apparent view of that is you're going faster, but what that means is you're delivering what is highly prioritized sooner because you can apply more teams to it. Having people work faster is a no win, you're not going to succeed that way.

Matt: I've seen a similar experience when the addiction is points. They get hooked on it thinking, I did 15, now I have to do 16, then I’ll need to do 17. They get trapped by that mentality. You've got to have the quality of your product, the scalability and some other key components as additional factors that you're measur-ing and bringing into the conversation. We tend to allocate a certain capacity for architectural runway, and that allows them to get points but also helps with the platform scalability.

Leslie: One more proof point to back that up is that years ago there was a team that was trying to make their work go faster. They had gotten beaten up for speed. It took a long time to get a build in. Anything more than a day meant that it was two days at least, to get code deployed and tested. So they took some time and they said, we're going to fix our build. What they did was they made it so that they could turn a build around quicker. They did a whole lot of tuning, got new build capabilities and got it to a point that they could get a build done in 30 minutes, run a 10 minute test automation, and use automatic deployment to test machines. They literally got it so they reduced a build from two days to 30 or 40 minutes. The team could work together, check in code, see it and all be working on it within an hour. That made the team work better and their throughput increased. It wasn't because they went faster, it's because they built a better engine.


About Guidacent Your program’s success is our top priority. We have seasoned experts focused on delivering outcomes

Guidacent is a local consulting firm that specializes in executing critical projects; in other words, we help cli-ents get things done. We provide outstanding project and program leaders to achieve technology and busi-ness outcomes, whether programs are “on track” or “at risk”. We work with our clients to understand their ultimate outcome, create the conditions for success, plan initiatives and lead them to completion. We call it Guidacent Grit and Grace. We come in with Grit, roll up our sleeves, grind out the work and drive toward outcomes – but we do it in a Graceful way, collaborating with your team, blending into the culture, mentoring your people and leaving each team better off than we found them. We believe that it’s more than just gener-ating the outcome – it’s about the experience along the way.

13



Todd directs several teams including site CI/CD platforms, and internal software platforms using Spring Boot and Docker. Responsible for the software engineering disci-pline and community, driving adoption of DevOps practices, and principals across the enterprise.

Leslie leads a global team of software professionals to build, deploy, maintain, and continuously improve an integrated suite of Customer Sales and Service tools for the major Expedia brands

Matt Deisher—Costco Travel Director of IT Delivery

Leslie Ekas — Expedia, VP Technology

Todd Wilson— REI, Director, Software Engineering

Thanks to Our Roundtable Panelists and Moderator

Moderated by Shoonya Mohanrao Guidacent Senior Consultant and Agile Expert

Matt supports scrum delivery teams as well as the Application Architecture team at Costco Travel. Prior to Costco Travel, Matt spent 13 years at Nordstrom in various software delivery leadership roles and was a member of the original Nordstrom Agile Transformation effort within eCommerce followed one in Master Data Management.

Getting After Every Outcome

2018 Guidacent Transformational Roundtable Series

September 27, 2018

Cloud Transformation

November 8, 2018

Guidacent Networking Mixer Fun event for clients and guests

Our Events Fill Quickly, Please Contact Greg Bennett for Early Registration

[email protected]

For Additional Information on Guidacent contact Jon Fleming, President

[email protected]

https://www.linkedin.com/in/leslie-ekas-2397a96/

https://www.linkedin.com/in/toddmwilson/

So We need to be Agile! now what? -...

Documents

Transcript of So We need to be Agile! now what? -...