Deloitte Digital Agile with Alex Sloley

Episode 66

June 27, 2012

17:01

TBD

tbd

The Agile Weekly Crew and Alex Sloley discuss Agile in a consulting environment, estimating and 1 week iterations.

Episode Notes

Drew LeSueur and Alex Sloley discuss:

What is Deloitte’s Digital Agile?

Alex’s Agile vs. traditional Agile

Agile in a consulting environment

Forecasting and estimating

Overview of the entire backlog

Estimating velocity

Benefits of mobile application life cycles

1-week iterations

Transcript

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?

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.

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.

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.

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.

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.

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?

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.

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