Wednesday, October 10, 2007

Scrum thoughts: cross-functional teams

For a little while we experimented with truly cross-functional teams, where we had copywriters, graphic designers, UX architects, frontend developers, backend developers, and QA folks all on the same team. I thought this was great, and our planning meeting was very interactive, as everyone had things to work on for new features. There was constant collaboration throughout the sprint: design/frontend, frontend/backend, product owner/QA/UX, etc.

As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly. There was a very real team vibe, very exciting. A lot of the UX/algorithm worked was never documented more formally than scratched-out notes on a whiteboard (yes, I think this was awesome, because no one had to spend time creating and updating intermediate artifacts like wireframes, and no one had to spend time waiting for those artifacts -- ideas were worked out together and then rendered directly into code). The six weeks that we operated like this were really fun!

Now, we did run into some problems managing dependencies between team members sometimes--e.g. a frontend developer would end up waiting for a design to be finalized and then only have a day at the end of the sprint to get it coded up. I suspect we could have ameliorated some of this by exchanging rough drafts, for example, or simply identifying the affected user story as being at-risk. We work around this in a purely development environment by stubbing out functionality to let other people keep working, and I suspect there are similar things that can be done with the other creative disciplines like design and UX.

Unfortunately, someone (or multiple someones) came to the conclusion that it simply wasn't realistic to have the team really be cross-functional. We've now retreated to a more waterfall method where we try to get design and UX out ahead of the sprints. This makes for really boring planning meetings and daily scrums, because those folks largely just say "I'm working on the stuff for the next sprint," and I have no idea what that stuff is. We also end up having to do design and UX work again anyway, because while it's really helpful to have the designs and wireframes as a starting point, they never exactly match what we can build in a sprint, and usually require some amount of clarification/adjustment anyway.

There's a claim that design and UX work takes a long time to get just right, and so it must be done ahead of time if the full feature is to be completed in one sprint. I'm not sure I totally buy this, though, as I could really say the same thing about writing code, which is itself a creative endeavor. We figure out what's possible in the time allotted, and that's what we do. If we're not satisfied with how it looks after one sprint, then we plan to alter/improve it in the next one.

Now possibly, there is some pressure around this because we've been actually releasing every sprint to production. I wonder if having a longer release cycle spanning multiple sprints would help give folks the courage to be able to "try the possible" for a sprint, where we might spend two sprints making new features and then a third sprint to prepare it for production and get it "just right".

If anyone out there has had successful experiences with multi-disciplinary teams, please leave a comment and let us know how it works for you.

5 comments:

Anonymous said...

I'd like to leave a comment actually. I am on the other end and am a graphic designer. We just started using scrum this week and a software system to manage it called VersionOne. It's too early to tell yet, but as a designer, I am already having some frustrations. For example I work differently that the typical programmer. A lot of times I don't know what needs to be change until I am actually doing it and looking at it with my eyes. Of course then I'll get another idea that will lead me to do something else. Truly what I have found (so far) is that the process of logging all of these tasks and backlog items tends to stiffle the creative process a tad. I'm not saying I don't want to do the work, mind you. . .I think the concept of Scrum is great. I have just had a hard time working with the software to log everything because it was written to be tailored to development teams and programmers. I'd like to just be able to attach an image to a task (not a backlog item) and just send it over for approval. I don't know if you use software for your tracking, but so far the VersionOne software has been somewhat complicated. So long story short, I see both sides. As a designer, I could see why the designers prefferred to have it done ahead of time and separate themselves from the development. Almost like a client relationship or an inhouse design department. I also understand though, the value of everyone being on the SCRUM system so that you can evaluate the velocity and see how everything is working.

Jon said...

Hi! Thanks for the comment. I'm not familiar with the VersionOne software specifically, but maybe you just need to pick your tasks differently. e.g. instead of, say, for a web page, making tasks like:

design the header,
design the body,
design the footer.

Maybe you decompose this and do:

produce first draft,
produce second draft,
produce final draft.

Where you might be able to timebox those effectively (we will allow someone to make a task that is as large as two whole days, but that's an engineering rule of thumb--maybe for graphic design it's acceptable to make the chunks bigger).

But anyway, remember that the purpose of the tasks are to assist the team with remember what they planned/signed up for, and to track time and estimates. So, if it works for you, maybe you just need one task which is:

design the page

(which should be pretty easy to track time against!). i.e. make the tasks fit your workflow well, not the other way around.

Scrum Problems said...

Thanks for sharing, I will bookmark and be back again.

sorna said...
This comment has been removed by a blog administrator.
Elizabeth said...

"I was very happy to uncover this website. I need to to 
thank you for your time due to this wonderful read on scrum thoughts!! I definitely savored every part of it and i also have you saved as a favorite to look at 
new things in your site"