Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is it possible to introduce scrum to a consulting environment? On any given week I might belong to 4 different teams, each with a different PM, BA and dev team (I am a designer). It doesn't seem feasible, time wise, to be able to be part of that many teams/projects as there would need to be daily stand-ups for each, sprint reviews, etc. I should add these projects are not necessarily software, but mainly ecommerce web projects.

Can someone who has done this speak to how you approach it?

Edit

I think my situation is different and I should have discussed it further.

Our dev team is in India, so finding a time in the US morning/India evening for daily stand-ups are hard, especially when we almost always have client calls in the US morning/India evening so dev can be present if necessary. Instead, what our PM's have done is have 1 daily meeting for the US team (BA, Design). However, they go through ALL the projects at once. So, if you're not on that project, you're screwed and have to wait till your project comes up. This can be 30min-75min a day, for me. Insane. This does NOT cancel our weekly status call (30m-1h) with the client (x however many projects you are on). This is obviously not scrum, as there are no devs present during any of this and it's just action items being listed for the US team. However, I'd love to get to a point where our 'scrum-like' dev team (they develop in sprints and have sprint planning meetings) can be part of daily standups with the US team and we transition to an actual scrum framework.

share|improve this question
    
How much time does 'context-switching' cost you and the company? Too much concurrency may be bad...could you please clarify how that is handled especially when >1 team needs access to you. –  PhD Jun 2 '12 at 3:43
add comment

2 Answers

One common problems in Scrum is that sometimes you'll get a Procrustean manager who wants to do things "by the book". They forget that the goal of using Agile/Scrum isn't to do Agile/Scrum but to deliver better quality and more user responsive software in an iterative fashion. You also get a lot of "Scrum In Name Only" managers who think that having a short daily meeting is all there is to Scrum. It can also become an enabler for micro-management prone managers.

In your situation, I think you and the Scrum masters in the various groups should be able to determine if you're needed for a stand-up on a particular day. For example, if the team is currently working on sprint that doesn't involve you directly, such as working on object models and the database, then you don't need to be there.

Given that you're providing work for multiple teams, you're more like a vendor, an ancillary role, rather than a development team member, a core role. That may be the way to approach it if your management is too by the book. If you're working alone, you may end up solo scrumming on your sprints. There was a good discussion of doing a solo scrum in this thread.

share|improve this answer
add comment

How much time do you spend in team meetings for each project, each week?

I'm going to assume that there is a weekly status meeting for each project, and that each meeting runs for about an hour.

A 10min scrum each day for each project would save you 10min a week for each project. Doesn't seem like much, right? But in that hour long status meeting, how much time do you prepare to go to it? It ends up pulling everyone on the team from the zone. It sucks if you haven't even worked on that project that week b/c you end up doing a huge context switch that is a full hour block of your time for a project that isn't so high on your priority list atm.

With a scrum it is fast. Everyone finds out who is working on what daily. PMs can get the quick overview of their project, devs know who is working on what part so bottle necks can be identified sooner and team leads can see quickly who is going to go over on a ticket and do some damage control before it gets out of hand.

I work in a multi project environment, and I have to say I prefer the projects that are run with scrum over the traditional status meeting. We tend to be on time and on budget more, and it is refreshing to know if someone is actually spending time on that project on any given day.

One project I was on at the end of last year moved to scrum near the end. The PM cancelled the weekly status meeting one day, then sent out a meeting invite for that afternoon. We did a quick status update, then he scheduled another meeting for two days later. We continued at every other day until crunch time, the it turned into a morning stand up and the PM normally brought donuts to encourage us to all be there.

The project went from being a set of tasks that the devs would get to, to clearly defined goals and tickets to work on by the next meeting. When you have to give your status update tomorrow and not next week, you want to make sure you have something to say. :-)

I honestly believe scrum can fit into any project if the team is committed to it. It opens up communication so that everyone is on the same page, something that you expect a weekly status meeting to do, but rarely does.

share|improve this answer
    
Tyanna, please see my edit. Thanks! –  Darla Jun 2 '12 at 15:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.