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.

Optimize (Globaly!)

At this moment we have 4 Agile teams in different levels of maturity. These teams are working on 2 parallel releases. With almost all engineers “accounted for” we saw challenges with triaging smaller projects that do not “fit” the overall theme PO is driving with the Scrum team for the nearest release. These include internal Engineering projects, hot support issues, customer commits, etc. In pre-Agile world the decision was mainly driven by skill set appropriate for the project and the priority of that project relative to other projects. There is no reason why it would be different in Agile, but for some reason it became more difficult to apply the same criteria for decision making. My take on this is before we thought we are making the right calls as far as priority goes, while now we are forced (by Agile process) to have the honest discussion on cross-team priorities and figure out which team takes a hit.

One of the cybernetics principles (that I learned about from Jurgen Apello’s book “Management 3.0”) states that optimizing the outcome for a subsystem will in general not optimize the outcome for the system as a whole. I think this is one of the challenges with Agile transformation: keeping the global optimum in mind while planning the work for the multiple teams. Both Engineering Management and Product Management need to keep the entire picture in mind rather than focusing on themes worked by individual teams. This approach will undoubtedly force discussions with painful decisions, but this is Agile living to it's promise: shining the light on problems in the organization.. It's up to you whether to fix the prioritization and decision making process or not.