Agile Outside Software with Raoul Encinas

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly podcast. I’m Drew LeSueur.

Roy vandeWater: I’m Roy van de Water.

Drew: Today, we have Raoul Encinas with us. How’s it going Raoul?

Raoul Encinas: Hey, Drew. How you doing? I appreciate the invite.

Agile Outside Software

Drew: No problem. Today, we wanted to talk with Raoul about Agile Outside of Software. It’s something that we are fans of as well. Raoul, can you talk to us a little bit about that?

Raoul: Sure. I think that’s an appropriate qualifier. Also, if you wanted to use the term “accidental Agile,” that would also be a fair way of describing it. The environment was a non‑profit organization where we had about 50 to 60 team members. Very few of whom had any visibility into IT processes, certainly none but the software development. It was an exciting way to use the concepts, and the philosophies, and the principles to a virtual work group.

Just a little brief on that organization. It’s called Southwest Job Network, and what we do here in the Phoenix Valley is provide professionals who are in career transition with career management skills so, networking, interviewing, how to do your resume, LinkedIn, and so forth.

Just a little bit of organizationally the cross section of people in terms of their skills and capabilities was all across the spectrum from HR, to finance, accounting, marketing, and of course there were some IT people there as well.

Deliver Something. Early And Often.

Roy: One of the important aspects of Agile’s to deliver something that works early, and get feedback on it so you can adjust course. On something where you’re delivering content, or delivering a service, or something like that, how do you deliver part of it? How do you deliver one piece of value, or break it up into small pieces of value?

Raoul: That was certainly one of our challenges, and if you think of the product that we’re trying to overhaul. You could think of it as software, because the product itself is curriculum. It’s an educational system where we use this curriculum in modules to teach people how to manage their careers better. We had an existing 1.0 version of that curriculum that was when we passed a need for overhaul.

During the course of applying Agile concepts to get our curriculum up to 2.0 we used two‑week sprints. We had existing product. The perfect scenario was that our customers for this product were actually the ones to helping to overhaul it. There was close customer collaboration as you could ever hope for because they literally helped re‑engineer it as we had new deliverables, new content, new terms, new output.

Accidental Agile

Drew: Awesome. I liked the phrase that you used “accidental Agile.” The team that you were working with on this project and service ‑‑ did they know that they were doing Agile? How did that come about to work in these iterations? Did you encourage that or how did it happen?

Raoul: I think we all appreciate the elegant design but sometimes you stump on elegance and just to back up a little bit around the situation or the context. What we had was a workforce of volunteers and you have to put yourself in that mindset of these are not employees. These are not virtual around the world. These are all people here physically who want to contribute.

The challenge with volunteers is that if you’ve ever had to manage a project that lasted more than a couple weeks it’s a very fluid workforce. Imagine taking in a large piece of software ‑‑ in this case our curriculum ‑‑ and having to re‑engineer that with a transient workforce.

We did compartmentalize and break down all of the pieces into as small of a chunk as possible and those are all concepts that you don’t need to understand software development or [inaudible 04:30] management to know that you break things down as digestible as possible.

We had virtual team segmented to different parts of the curriculum but what we were struggling with was continuity from team to team and having some type of reasonable pace of development and progress. Where the teams would be motivated by what other teams were doing. I can’t take any credit for bringing the Agile concepts. I was already doing some things that were around collaboration and self‑directed work teams and those were the things that I brought to bear.

I really have to credit Jim Brodie who is our local [inaudible 05:08] executive. He was with Hypercom for a while. An expert in Lean and Six Sigma and all the different approaches. He walked 50 of us through the “Idiot’s Guide to Agile,” and Scrum, and sprints, and so forth. It was a perfect match between what we already had in terms of scoping out the work and breaking out virtual teams and the need to have quick increments and quick cycles on the actual deliverable.

Once he brought that knowledge of how to execute the work, how to organize people, coupled with what we already had, it just was fantastic. In the process of six weeks we had 50 people who basically overhauled an entire adult learning curriculum. If you have familiarity with the complexity of that you would not believe that that was possible in a period of six weeks. Again, with volunteer labor, not subject matter experts.

Virtual Teams

Roy: You had mentioned that you guys were working in…I think you called them “virtual teams”? Was that an actual team? Were those virtual teams actual teams with people in them?

Raoul: They’re virtual in the sense that somebody could be a member of more than one team and they didn’t necessarily meet and collaborate in person.

Roy: You had mentioned that, because of the nature of volunteer work, that was very transient. We’ve noticed before that it sometimes takes teams a while to really form, and get through their problems, and start to mesh.

How does that work if people are constantly leaving and joining the team?

Raoul: It was an incredible leap of faith. One of the things, the unique nature of these volunteers are ‑‑ these are professionals. They have a lot of pride in the work that they’ve done, but they’re currently out of work.

You’re talking about, these are not recent college graduates, these are people who have experienced being in the workforce. They’re used to working on teams. They’re used to working towards a common challenge.

Being out of work and displaced they had a very high motivation to do something, and to collaborate. We were able to tap into that desire for collaboration and the desire to actually boost your own ego and pride by just getting some work done. There was a very natural desire to attack a common problem.

One of the things we did, I will say, all modesty aside, from a governance standpoint and from a centralized standpoint, is we did a really good job of defining the boundaries and the framework, or the sandbox, in which these professionals can play. We trusted them as adults, as professionals, to say, “None of us are going to make any money off of this. It’s for the greater good.”

People were able to check their egos at the door and really focus on a good design and a good work product. It may have been a fluke or a one‑off but it really was a phenomenal achievement by this team of 50 people.

Volunteers Given Freedom

Drew: You gave the members of the team a little freedom to do what they want with their project within the certain greater bounds that you put.

Raoul: Yeah, and I’ll give you an example. Our originally curriculum had been split into maybe eight modules, or chapters. We started with eight teams, just because you have to start somewhere.

What happened is ‑‑ I wouldn’t say after the first two‑week sprint ‑‑ but maybe after the second one, it was pretty clear that some of those breaks, for example between chapters six and seven, were just artificial. There was just no logic or reason for there to be a break there.

As we were getting more product back and the teams were collaborating, what happened is teams six and seven naturally wanted to collaborate. They were in the midst, in the details, in the muck, and they realized, “Hey, this is an artificial break. Just because the legacy content was split this way doesn’t mean that this is what we have to continue to do.”

It seems commonsense now, in retrospect but, as you know, when you’re in the middle of team meeting and work product with people you never worked before it’s not that easy, necessarily to call out the obvious. They called out the obvious.

They collaborated with each other. They broke away that artificial break point and merged those two modules for some better seamlessness. Those kinds of things.

There were all kinds of very interesting breakthroughs, a series of small to medium breakthroughs that just made the overall product phenomenal. Mostly our job was to get out of the way of the teams.

Working Directly With Customers

Drew: That’s awesome. I like what you said earlier about working directly with the customers, the people who are actually going to be using the service, as you developed it.

Can you talk a little bit more on that?

Interviewee: Sure. Each team had at least three and as many as maybe seven or eight people. One of the framework elements that I pushed for, and we were fortunate enough to have enough of, were we had enough professionals with a background in training, or HR, instructional design, or adult learning, or something. [laughs]

It was a little bit of a stretch sometimes but we were able to have each team populated with at least one, for lack of a better term “process person.” And the process in this case was adult learning, or education.

We were able to have enough of a cross‑section of maybe, an accounting and a salesperson, or an IT and a marketing person, on other teams, where people bringing this cross‑domain knowledge was quite powerful, quite impactful. The process person provided that framework and kept reminding people to stick to learning objectives, which is an element of adult learning, and making sure that certain things were phrased with very precise verbs. There’s some rules around design in that space.

But, within that sandbox, these [laughs] marketing person and IT person collaborating was pretty powerful, in terms of their ability to just share domain knowledge and even cross‑train on some components. Those parts were pretty exciting, again, to see people who had never really worked together before to figure out a way to make it work.

Drew: Did you guys, just curious to any sort of retrospectives after your iterations or anything like that? I know one thing that we value as a team is after we’re done with our sprint, which is usually a week long, we’ll get together as a team and talk about what went well and what didn’t go so well as kind of a formal small ceremony. Did you guys do anything like that?

Raoul: Certainly not as formal as we could have. We were better around celebrating successes overall, amongst the larger group. There was a core group of maybe just six or seven of us who were more of the governance point. We did that among that group, a little bit more around lessons learned, and what do we need to do, and how are the teams progressing, as different teams would go at different speeds.

We did that, I know for certain, around that core group. Given to do it over again, I think it would have been terrific to be able to spread that level of maturity to the further teams, but I think that would have been overreaching a little bit. Especially, since it was in essence a one‑time gig.

You Have To Trust It Will Work

Drew: It sounded like it was a fun project. What would you say was your biggest take‑away? If you could take away one thing from the experience, what would you say that would be?

Raoul: Even thinking about it now, and it’s been a bit of a time since we’ve done this, to a very large extent, and it sounds silly, but you have to trust that it’s going to work.

It’s incredibly risky to stand in front of a group of 50 or 60 professionals, very seasoned people with 10 to 20 years of business experience across all these domains, and convey with confidence that this structure and this way of working, which may be very foreign to [laughs] many of you. This style of project management, and this approach to collaboration, to stand up there and have the confidence that it’s going to work.

I think we were able to convey that energy and that confidence, and we showed that we trusted each of these work teams through our actions. We didn’t override the decisions that they made. We weren’t looking over their shoulders.

To a very large extent, this was a peer‑driven group, and having that trust and taking that leap of faith, basically taking your intellectual property, sharing it with this public group and trusting that it’s going to be protected, and taken care of, and curated, and all these important things, that was an inspiring, emotional, and a rewarding, the most rewarding element, I think, of the entire effort.

Drew: Awesome, great take‑away. Raoul, thanks a lot for having us on the podcast, or thanks for joining us on the podcast. If you have anything you’d like to promote, or share with the audience?

Raoul: Just since we’re on the non‑profit theme, to the extent that people want to contribute their professional skills in a voluntary capacity, a terrific organization local here in the valley is called Hands‑On Phoenix, and you can use your favorite search engine to find them.

Hands‑On Phoenix is a non‑profit organization that brings together volunteers, functions as a broker for other non‑profits, and puts those teams of people to work in a variety of different capacities for the greater good of the community. If you’re looking for a way to contribute and give back, and want to use your professional skills, that’s a great place to start. Certainly, you frequently get back more than what you give in that regard.

Thanks for having me guys. I appreciate it.

Drew: Thanks a lot, Raoul.

Raoul: Cheers.