Any company with enough focus and dedication can sustain a single pilot team. Ok, may be not any, but definitely many. When time comes to scale beyond the single pilot team various organizational impediments become evident and the real test for organization’s ability to go through with necessary changes begins.Almost every process under the sky has to change and adjust to support multiple teams working on multiple releases simultaneously: Defect Management, Source Code Repository management (branches, builds, etc), UX, Development Documentation (design specs and other artifacts). Before we started with the first pilot team we have identified all these processes and created spin-off teams each focusing on a single process and identifying the way that process would need to adjust to meet the needs of the Agile environment.
The biggest concern with scaling Agile is shared resources: POs, DBAs, Architects, UX Designer, Release Manager, Documentation, and the list goes on. This was always our top concern and therefore it became a prerequisite to scaling beyond the pilot team.
1st shared resource concern that we’ve addressed was a Product Owner role. With Product Managers spread thin already it was obvious that without some scaling mechanism in place the Agile wouldn’t work. We have introduced the concept of Product Owner Proxy to augment the Product Owner role. PO Proxy can be anyone from the team who knows the product well and can make decisions 50% of the time on PO’s behalf and answer team’s questions in PO’s absence. We’ve seen this role being filled by architects, QA and developers in other companies successfully.
2nd shared resource concern that we just started to address is UX Designer. With the constraint of not being able to hire another UX Designer we had to become creative to address this issue. From what we’ve heard from other people it isn’t practical for a single UX Designer to support more than 2 Agile teams. Based on what we’ve learned during the pilot project it became evident that in our environment it will be impossible to support more than 1 team… 1st thing we’ve done was to identify the minimum process changes required to scale: identifying user stories with UX impact in advance so that UX Designer could see 2-3 sprints ahead and know what might land on his plate. Next, we’ve analyzed all the responsibilities and deliverables of the UX Designer and categorized them into 4 categories:
a)Has to be done by UX Designer
b)Can be delegated to another team member under close supervision
c)Can be delegated to another team member under loose supervision
d)Can be delegated to a PO
This analysis has shown that even though UX Designer has a lot on his plate not everything has to be done by him and in many cases can be offloaded even if under supervision to other folks.
Of course it doesn’t stop there: with multiple Scrum ceremonies for each team, UX Designer’s time management will also become an issue. Each organization should identify how to manage that time best with minimum waste on one hand, and without losing the UX insight on the other.
After all, hiring a new resource is not always an option. Even if hiring will have to be part of a solution, in my opinion it makes sense to assume you can’t hire and see what you can come up with. Best ideas come to mind when constraints are present.
p.s. To see how we are scaling the Offshore Manager in the new Agile world read my post at the offshore blog: http://offshoremanagement.blogspot.com/2010/12/streamline-communication-accross-pond.html
