August 14, 2014 | Time: 13:15 | Subscribe in iTunes
A discussion with Jim York of FoxHedge, Ltd. and Elizabeth McQueen, Branch Chief of International Trade Data System at Customs of Border Protections, on the effectiveness of the agile software development approach at the Customs and Border Protection agency – what it takes to make it work, and what happens when it does!
Listen online or read the full podcast transcript below.
About the Speaker(s)
FoxHedge Ltd, Co-owner
For more than 25 years, Jim York has led, trained, and coached individuals, teams, and organizations in the implementation of Lean and Agile ideas. He is a Certified Scrum Coach and Certified Scrum Trainer. His coaching and workshops blend his practical experience in Scrum, Lean Software Development, Extreme Programming, Product Management, and traditional project management. Jim shares his passion for teaching as a frequent presenter at conferences, users groups, public and onsite workshops, and as a business process coach. In 2007, he cofounded FoxHedge Ltd with his wife, Melissa York. Their mission is to coach leaders to build effective teams and products.
PMIWDC / U.S. Customs and Border Protection, DHS
Chapter Chair / Branch Chief, International Trade Data System (ITDS)
Meet Elizabeth McQueen - the new 2015 PMIWDC Chapter Chair and CEO. Elizabeth served as the Chapter’s Vice-Chair and COO in 2014, following 9 years of increasing volunteer involvement that started when she attained her PMP certification in 2005. Beginning as a volunteer with the Business Process Assessment committee, Elizabeth moved on to managing the chapter’s Business Process Definition project before serving as the chapter’s Assistant Vice President, and then Vice President, for Records Management. Elizabeth was elected as a Director at Large to the Governance Board in January 2012. The Governance Board appointed her as Vice-Chair for 2014, switching her tenure with another DAL to allow her to subsequently serve as Chair in 2015.
From a professional perspective, Elizabeth’s career has centered on all aspects of organizational maturity, from developing corporate processes and metrics programs to teaching project and program management, as well as preparing organizations for certifications and audits in support of meeting universally accepted standards. She is currently the Branch Chief for the International Trade Data System (ITDS) for Customs and Border Protection, within the Department of Homeland Security. Prior to this project she taught Acquisition Program Management at DHS, via Process Evolution Group (PEG), her business process improvement and project / program management training corporation.
Elizabeth graduated in 1988 from the University of Texas at Austin, with a BS degree in Advertising. She lives in Alexandria, VA with her husband Steve and their tri-color Shetland Sheepdog, Bella. Outside of her professional work and time spent volunteering with the Chapter, she enjoys cooking, yoga, and travel with her family.
00:02 Elizabeth McQueen: It started from, "What you're doing is not working and we're not gonna keep throwing good money after bad. Come up with another plan."
00:09 Jim York: Agile is what you do when your back is up against the wall, naturally.
00:13 Kendall Lott: A proselytizer, a skeptic, and a believer walk into a podcast.
00:18 Voice Over: From the Washington DC Chapter of the Project Management Institute, this is PM Point of View. The podcast that looks at project management from all the angles. Here's your host, Kendall Lott.
00:28 KL: When it comes to Agile, I was the skeptic, particularly in terms of it's viability in government organizations. But after two recent encounters, I knew it was something I had to address. For this podcast, I brought together Jim York, co-owner of FoxHedge Limited, an Agile and Lean coaching and training firm, and a colleague of mine, Elizabeth McQueen, the branch chief for the International Trade Data System for Customs and Border Protection. She is also the Chief Operating Officer of PMIWDC. She knows a thing or two about project management. I had no idea of the passion and joy that this topic generates.
01:04 JY: Most often, I hear people refer to agility when they want to be able to respond in a timely and appropriate manner to change. It's a process where you deliver quickly and because of the opportunity that that early delivery gives your customers in terms of providing feedback, once you show someone something, it actually generates change. We all know that when we deploy something into a production environment, or once our customers gets their hands on it, instantly, they find things that they were not aware of before.
01:36 KL: Is that your experience as responding to business stakeholders in your environment?
01:39 EM: Absolutely. And I think the corollary of that and something that I know Jim has heard a thousand times is we really very much embrace the notion of failing quickly. So that in fact, if after a two-week period of time when our scrum teams have been developing something and then we show it to our stakeholders at our biweekly sprint review and demonstration, and someone is not pleased with something as simple as the verb-age on a button, because it's not consistent from one part of the application to another, we hear about that immediately from our user base, have the opportunity to address that within the next two-week period of time. It's a completely different paradigm than when you used to wait a year and a half, get the entire thing delivered, and only then discover that there are things you'd rather have tweaked.
02:23 KL: And you do this in a cycle fast enough with this Agile... I don't even wanna use the word methodology, approach, way of being.
02:28 EM: Sure.
02:30 JY: I'm glad you didn't use the word methodology.
02:31 KL: Is it an approach? Is it a religion? Is it something in the water?
02:34 EM: For us, it's our new way of doing business. It's how we are developing. The mindset of having embedded in each of our development teams representatives from the user community, in our case, because we are developing software for customs and border protection, we literally have people from the Office of Field Operations, folks who work at the borders, at the ports, come here for a 13-week period of time, get embedded in our team for one of our increments, and take part in developing the software. So they work with this stuff day-in, day-out and know what's gonna work.
03:15 EM: And we've also got a level of transparency that you just do not see almost anywhere else in the government by virtue of our biweekly sprint review and demonstration where we invite pretty much anyone who has any interest. We webcast it, folks can call in. We have done live demos of showing their data that that particular agency is concerned about parsed from one of our entries and sent directly to them, and then the response that comes from their system to take whatever action based upon that data, literally watch that live.
03:46 KL: So I just heard some interesting things in there. Accountability, transparency and failure is an option.
03:52 EM: Yes.
03:53 KL: That's what works.
03:53 EM: We encourage failure early.
03:54 KL: Early, yeah.
03:55 EM: Right. It's the Edison theory, right? Can't get it right...
03:58 JY: It's how we learn. We're really putting into place a framework that allows an inspect and adapt cycle. We do some work, we inspect the results, we make adaptions to improve both the work product and the process by which we were creating that product.
04:12 KL: It's almost like it's a high speed evolutionary cycle.
04:15 JY: Absolutely.
04:15 KL: If you look at adaptation to an external environment.
04:18 JY: It requires a lot of discipline. For teams that I've coached, when they initially see Agile, they say, "Well this is gonna be kumbaya and it's not gonna have any rigor."
04:29 KL: Elizabeth screaming.
04:29 JY: And without exception, every team that I've coached that has been successful in implementing Agile comes back later and says, "This is the most rigorous process that we have ever encountered." Where did the rigor came from? And it came from themselves, because they were accountable.
04:50 JY: You have this experiment that's running every cycle on the product increment and everyone can see what has been produced. So if a team is underperforming, the result of that is seen by everyone. And it doesn't need to necessarily be called out, there's a feeling of, "This wasn't as good as it could have been." And it is often self-correcting.
05:11 EM: There becomes this awareness with these tight cycle times that their future pain that they will feel if they don't take steps now to prevent that is real, and is only going to snowball.
05:25 JY: Yeah, the signal...
05:25 KL: There's a level of excitement that has to... There has to be energy in the system at some level.
05:28 EM: Yes.
05:29 JY: There is energy in the system. And when you walk into an environment where teams are working in an Agile fashion, there is a palpable buzz of energy in that room because they're working together in a collaborative fashion, they are working on things that are meaningful. They get feedback when they're doing things that are appreciated. They get feedback when they are doing things that might have missed the mark. They are able to take that feedback and immediately react to it and then they see the result of that immediate thing. I think it's that immediacy.
06:00 EM: Yes.
06:00 JY: We are kind of turning up the dial on the intensity of the signal.
06:05 KL: How have your IT side of these teams handled this kind of transition? They can burn out. This is a lot of high paced, high speed thinking. Were they able to adapt? Did you change who you hired? What happened?
06:17 EM: There were growing pains, certainly. Well no, so we did change who we hired. So one of the things that's also a typical government paradigm is that you maybe come up with the requirements on your own, you might even get help with that. But you then throw the whole thing over the fence to a contracting organization and let them do everything. Each of our development teams is led by a federal government employee developer. And we have got contractors and federal employees who are developers working side by side. So, we are not procuring the whole solution, we are procuring participants in making the solution happen.
06:52 KL: How are people accountable in an environment like that?
06:54 JY: It's interesting because, I'll use Scrum as an example. Scrum is a very simple work management framework, and it's intentionally specific in how it divides accountability and responsibility and rights amongst the team members. So, for example, we have a customer role. In Scrum, we call this the product owner. This is the single business decision maker. They are ultimately accountable for the results of the work that is being done. Now, they may be spending someone else's money, the investor may be someone else, but the product owner in Scrum is empowered by that investor to make those decisions.
07:39 KL: So based on how you've seen it happening and how you teach about it, what would you have predicted, how this would work in the government? What are some key characteristics they would have to do to make that work in a two to five-year budget cycle process that they go through, and a tradition of waterfall and a tradition of many layers of business owners moving away from you. What are your predictions for what they have to do, or where there's hurdles to overcome?
08:02 JY: One of the biggest problems is finding and assigning the accountability and empowering them to act as this decision maker. That is in many ways, the secret sauce. If you get that put in place, other things become significantly easier.
08:18 KL: Would you like to speak to that? Was that a problem, is that a non-problem?
08:21 EM: Oh, absolutely. That was something that very much had to be engineered from our living in a very, very waterfall environment. So, the way we actually got around that, we do in fact have product owners, we have a couple of them for different large facets of our system, because it's a very, very complex system. We have also what we call capability owners, who are empowered by the product owners, so they're sort of a product owner lite. And there's literally one of those in each of our development teams.
08:52 KL: Is that so they can be present and represented in each of the areas?
08:55 EM: They make those decisions and then they coordinate with the actual product owner to ensure that we're harmonizing our highest priorities and that we're doing things the right way.
09:04 JY: There's no one best method. You have to navigate your own sea.
09:09 EM: That's what you're kind of describing?
09:11 JY: Yes, absolutely. The key here is to get the best possible decision making at the right time.
09:23 KL: Does this approach in the world change the commitment and interaction on the business side?
09:29 EM: Absolutely.
09:31 KL: Is their amount of effort in dealing with the IT system different at that senior level?
09:35 EM: So, what's interesting is that I don't think we had a feel prior to heading down this path for just how disconnected the business side was from the work.
09:47 JY: And vice versa. [chuckle]
09:48 EM: Well, sure. And frankly, the most difficult part, I believe, of our whole journey has been to change the mindset of the product owners and the folks on the business side that they in fact have that ongoing responsibility to be involved in getting what it is that they need and they want. Instead of sitting back and letting someone develop it for them, only to come back and tell them everything that's wrong about it. If there's something wrong about this tiny piece we did in this two week period of time, this is your window to tell us about it. You had better be there and be engaged and understand what it is you're asking for, or you're robbing the team of efficiencies.
10:28 KL: So one of the earlier questions I was gonna have is really around how much of this is related to organizational culture change. The way I got started here was some senior people outside of the environment said, "We need to try this new way of doing things." Is that where it came from?
10:41 EM: Slightly upstream of there, I would say, because it started from, "What you're doing is not working. You've spent X amount of money, you've achieved X minus what you needed to and we're not gonna keep throwing good money after bad. Come up with another plan."
10:57 KL: So there was a real requirement for change and that's what allowed you guys to get to it pretty quick?
11:00 EM: It was do or die.
11:02 JY: Agile is what you do when your back is up against the wall, naturally. It's the things that focus your energies on what's truly most important.
11:11 KL: Why is that true? Why isn't that a natural way for us to wanna work? So, what's going on here that that makes that the terror approach?
11:17 JY: I think it's a lack of urgency, I think it's a lack of urgency. A crisis makes it much easier to implement change, and what Agile brings to this mix is this idea that we're going to eliminate the things that are wasteful in our processes.
11:36 JY: I think we're on that bell curve, where we're basically in the mainstream now, there's wide-scale adoption of Agile.
11:44 EM: The folks at our parent department, DHS, are very interested in having a new additional track of their acquisition lifecycle, that involves this whole Agile paradigm, and they are asking for our input and participation in developing what that's going to be. It's been a slow turning this massive ship around, but it's one of these things where success will breed success, and then hopefully, all of the folks who'd been very involved in the success of this program will be part of propagating that in other places.
12:23 KL: Got it? The Agile approach starts with a senior level commitment to a process that forces requirements owners to become much more engaged and therefore, more accountable. And because it's built around teams that have to respond to feedback in rapid life cycles, there's an immediacy and transparency that's not usually found in government projects. But as we heard, Agile is, well, Agile. It can be adapted to accommodate a very complex stakeholder environment. Special thanks to today's guests, Jim York and Elizabeth McQueen. Our theme music was composed by Molly Flannery, used with permission. Post-production performed at Empowered Strategies, and technical and web support provided by Potomac Management Resources. I'm your host, Kendall Lott, and until next time, keep it in scope and get it done.
13:12 S?: Final milestone.
About the 'Project Management Point of View' Podcast Series
© PMIWDC and Kendall Lott
This podcast series is a collection of brief and informative conversations between MPS President, Kendall Lott, and a wide variety of practitioners and executives. His guests discuss their unique perspectives on project management, its uses, its challenges, its changes, and its future.