Deloitte Digital Agile with Alex Sloley

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur, and with me is Alex Sloley, who works for a company called Deloitte. Alex, what kind of work do you do for Deloitte?

Deloitte Digital

Alex Sloley: Deloitte is a global company. I work in the consulting functional area for Deloitte. I’m in a service line called Deloitte Digital. We’re a brand new service line. I am a senior engagement manager. On a tactical basis, effectively, I’m a scrum master or an agile coach here within this service line.

Drew:: Is that what it means by senior engagement manager is scrum master or agile coach, or is it more to it?

Alex: Yeah, senior engagement manager, also for consulting company. We deal with external clients, so from the senior engagement manager side, managing the relationships with the clients, but internally and tactically, I’m running multiple Scrum teams for the clients as we work on their projects.

Drew:: You’re helping your clients implement Scrum, and run Scrum, and you have been coaching them through that.

Alex: Actually, we develop mobile applications and mobile optimized web sites. We’re building internal product here using Scrum, and delivering it for our clients.

Favorite Flavor Of Agile

Drew:: A lot of people have different takes on Agile and what it means to them. How is your flavor of Agile different from what you might read in a book?

Alex: I think I came from a product of Scrum background personally before I came to Deloitte Digital. I think the big difference here is that you’re working in a consulting model. There are several key differences between what I would call traditional Scrum, and the Scrum we execute here.

The biggest being that the product owner is typically not co‑located with the team. For example, if we’re working with Alaska Airlines on an iPhone application, the product owner is on the client side, but is located at Alaska Airlines corporate headquarters and not with the team here. We work out of Seattle at Remind Studios. The development team is all here at Remind Studio. Part owners remotely located next ‑‑ that’s the biggest difference.

The other big difference I see in the consulting world of Scrum is that there’s some level of upfront estimation that needs to be done on a project for contractual reasons, so that you can provide a general level of effort, estimate to the client and in general, how much the project is going to cost in the long term.

Upfront Estimates And Sprint Zero

Drew:: You’re confronted with having to provide kind of a little more hardened estimates than, maybe, traditionally people in Agile projects do. In my mindset, you try to focus on the iteration, every sprint having a potentially deliverable product. The plans in the future are fairly fuzzy, and you kind of focus on the iterate of development.

Because of the contracts you have to do, you’re not able to do that as much. How have you handled that? Has it been very hard or how do you do that?

Alex: I definitely think it is a challenge. In general, I think it leads to certain practices here that we need to do to fulfill those contractual requirements. Number one, I think we probably do more road‑mapping than is usual, because we’re trying to forecast ahead of time.

The other thing I would say slightly different is that we try to get a general feel of the entire backlog in a Sprint Zero. Sprint Zero is critical here in the consulting world, because we have to get a general overview of the entire backlog, a general estimate of total story points, so we can come up with a long‑term vision of how long the project is going to take at a standard velocity.

We also have to phrase our contracts in such a way that it’s clear to the client that this is ongoing work. I think because we’re in the consulting world, we do have to do more evangelizing, and socializing, and educating of Scrum and Agile methodologies to the client.

Drew:: A lot of times, when I try to estimate things in big projects early on, I fall short a lot or it just turns out way different than what you imagined. In your practice, is there a negotiation phase where it looks like we’re not going to make it? Or maybe the product owner says, “You know what? I kind of want to shift paths on this, which will kind of invalidate some of this other stuff.” Do you do that much, or not much?

Alex: The thing is, because we’re in the mobile application world, the actual life‑cycles, the products themselves, are extremely rapid. We can produce a mobile application for a client in three to four months.

Drew:: You’re still on a short time span in general.

One Week Iterations

Alex: Yeah. I prefer to run one‑week iterations at this point. Some teams still run two‑week iterations, but we’re moving pretty much, as a service‑line, towards one‑week iterations exclusively. That means changes are extremely rapid. But we don’t have the kind of impact from a dependency that would affect an 18 month long project.

Since the scope is really refined, and somewhat narrow, I think it makes it a little easier to do that upfront estimation. But I think we do place a lot of emphasis on sprint zero, simply because working with a client is much different than working on an internal product for say, an enterprise company.

Remote Product Owner

Drew:: When you talk about the product owner not being close with the team as far as proximity, do you still get daily stand‑ups? Do you still get those sprint reviews and demonstrations, that kind of thing?

Alex: I think that’s one of our efforts when we go into that sprint zero with the client, is we have to set these expectations. “Hey, look, you’re signing up to provide a product owner.” We clearly lay out what the product owner role entails, how much time and work is involved. Yes, on a project I expect the client, product owner, to be available for all stand‑ups, plannings, reviews, retrospectives, meetings on architecture, anything that you would expect from our PO in a co‑located team.

Commitment Driven Planning

Drew:: Now I also saw on your LinkedIn profile that you had experience at Microsoft. How has that helped you, your mindset, where you are now?

Alex: Microsoft in general uses a flavor of scrum that I call a “capacity scrum,” similar to Amazon, in that you use ideal hours and capacity, and you plan for load of individuals on the team. I think that I made a conscious decision to actively move away from that model, while transforming the organization here into the use of scrum. But I think Microsoft is great place to start, and to hone your enterprise‑level skills.

Drew:: Can you explain a little more “capacity‑based” scrum, and hours? I didn’t really get that.

Alex: At Microsoft, a typical scrum practice is you establish an individual team member’s load, which is just how many hours per day they can do actual work. A typical percentage at Microsoft is 50 percent. If you have one dev on a scrum team, he can provide four hours a day of actual work.

Drew:: Because the rest is taken up by meetings or interruptions?

Alex: Yeah, exactly. Then you calculate capacity based on the number of people, the person in each day, what they can work, called “load.” Based on your iteration length, you calculate how many hours are available per sprint. Then, when you’re doing your estimations for stories, you break them down into tasks and assign hours to those tasks, and tally them up, and subtract them from the capacity until you reach zero. That’s how you determine how much work you can do in a sprint. They do the exact same thing at Amazon, except they just call it “ideal hours.”

Drew:: I do something similar, at least I have. We call it commitment‑driven planning where we’ve got our sprint velocity, and we can get an idea based off our previous velocities or the average of how many stories we can take in. But we won’t necessarily commit to all those stories until we break it up into tasks and figure out, based off the hours, “Do we have enough time?” Is that different than what you use at Deloitte?

Alex: Absolutely. Within the group of my studio here at Deloitte Digital, I advocate strictly story point estimation and no hour estimation whatsoever.

Drew:: Does that causes you to focus on something else? Or why the shift?

Increased Planning Time

Alex: The shift, I think, is through my experience. There were several reasons I discontinued the use of that practice. Number one being that it just takes more time to break stories down into those granular tasks and assign hours to them. I’d say probably it increases your planning time by 400 percent, somewhere around there.

Number two, it gets the team away from thinking about tasks or stories in a relative fashion. They’re not thinking about, “Is this bigger than that, or is this smaller than that?” They’re thinking in hours.

The other thing I think is that it’s great for senior executives or managers who often focus on, “Is the team working to their capacity?” They’re looking at that burn down chart, and all they really care about is, “Is that trend reaching zero, zero, zero?” I actually prefer burn up and looking at how much value is added over time.

Incorporating Fun

Drew:: I can see that shift. Also, I read on your LinkedIn profile that you mentioned your job should be fun. How do you try to incorporate that in the work that you do?

Alex: I do fun little things. During estimation for example, if I get bored, rather than estimating on zero, I’ll say something like, “We’re estimating on banana.” Then I’ll say, “Pomegranate, peach, pear, banana,” and little silly things like that.

I’ve also used retrospectives of fortune cookies. Those are pretty cool. Those sparks some interesting conversations. I’m a big believer in holding retrospectives, if not at a local bar, then getting a couple of six‑packs, and bringing it into the team.

I’m also a big believer in doing some very basic exercises every now and then, like tribes and constellation. You’ll see a lot of people use those kinds of things at open spaces. I also like to do regularly planned morale events, take the team out to the shooting range, take the team out and go to whirly ball, stuff like that. That’s important.

Transitioning To Agile Consultant

Drew:: That’s all good stuff. To close here, we talked a lot about different flavors of agile and different ways to implement it. For you, what is your passion with this stuff? Why did you gravitate your career towards helping other people implement agile and running agile software projects?

Alex: That’s a great question. I think, for me, it was spending a long time delivering in the waterfall model, and seeing it fail again, and again, and again. Then, going into agile where really the focus is on the team and the people. I do like process, and I’ve heard people talk about it. “Is agile or scrum a process or not?” I think it’s a framework that allows you to operate in an agile fashion.

Yeah, I guess I would call it a process, but it’s a very clean and streamlined process that puts the emphasis on the team and the individuals. I think it just leads to better work‑life balance. I’ve seen it lead to more successful projects in terms of actually delivering on time.

The thing I’ve seen happen more than once, which is probably the ultimate validation of this methodology, is spinning up an agile team, bringing in a product owner from a client who doesn’t really know much about agile or specifically scrum in our case. Then, through the process, they learned to love it, and go back to their company and implement scrum or agile within their company based on the success that they saw working with us. I think that speaks volumes.

Drew:: That’s all good stuff. Thanks so much for joining us, Alex. Do you have anything to promote or share as a final word?

Alex: I welcome everybody to go to DeloitteDigital.com and check out some of the clients we worked with like Alaska Airlines and Target and REI. We will be hosting a mobile, agile, QA conference in Fremont, Seattle, October 19th, called the MAQcon. You’ll be able to find more information online by googling, soon.

Drew:: Sounds fun. Thanks a lot. For the listeners, if you want to join in on the conversation, find us at Facebook.com/AgileWeekly. Thanks a lot, Alex.

Alex: Thank you.