Moving Towards Frequent Delivery

As we all know Agile/SCRUM often needs to be tailored to the team it's being applied. More often then not. However, it is important to understand that tailoring Agile to "the team" means tailoring it to the situation. I propose to evaluate your situation through the following 4 dimensions:

Product type (Consumer/Enterprise/Specific vertical)
Product Lifecycle (where the product is in it's lifecycle and the competitive situation)
Technology (Mobile/Web/Systems)
Deployment Model (SaaS/On Premise)

The situation is constantly changing as the dimensions change, and therefore the approach that worked for your team few months ago, may not be the approach for going forward.

The combination of these dimensions will often dictate the Release Cadence. For example, you can organize the team for frequent delivery, but if the product is an on-premise solution, the customers may not want to absorb frequent releases. Mobile/SaaS world is different and there is an expectation for frequent delivery. If you add an enterprise aspect to the situation, then again, the frequent delivery may not be very welcomed even though the Mobile/SaaS nature of the product allows for it.

When we started the development of a v1.0, we had one big team of 12 people. When the team grew to over 20, we stayed in a one big team model, with the standup still taking under 15 minutes, which was really cool. However, the nature of the standup wasn't any more to coordinate the work, but merely to share the status, therefore losing it's real value. The functional teams were split by platform (mobile, web, server) in a service model, where the Server team would get a request for changes from the Mobile team. With the demand to deliver more frequent releases this stopped working and wouldn't scale, considering we wanted to keep the organization flat.

Because of the current competitive situation and considering how early the product is in the lifecycle, it was decided that frequent delivery model is to be followed even though the product is targeted for the Healthcare industry that doesn't absorb frequent changes well. With the pressure to deliver more frequent releases to the market we needed to reorganize.

The Product: Cloud based Mobile&Web app, Healthcare industry. v1.0 just 6 months ago.
The Idea: Cross-Functional Feature Teams + Parallel Releases

The approach we took was to assemble the cross functional teams around the next priority feature, the next feature and so on. Each team would have their own Feature Lead, responsible for the coordination of the work and making sure the design is getting done and documented etc. Think "Feature Team Scrum Master". With this approach the stand-ups make more sense: the people on the team are planning their project's work.
The next step is to lower amount of work in progress and amount of features in each release. This allows part of the team to work on the next release, eventually increasing the overall release cadence.

Can we scale it? Yes we can!

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