Scrum thoughts: cross-functional teams
Series [ Scrum Thoughts ] Tags [ cross-functional, teams, Scrum ]
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.