Is it possible to make agile work for platform development?

Question

Is it possible to make agile work for platform development? Picture a set of dev pods each responsible for a unique functional area of a platform. Now picture 2-4 app dev teams that use the platform to build software apps to the public. How do you make agile work in this scenario?

Answer 1

I think it depends on how you define agile. Agile is an umbrella term for a bunch of methodologies and practices.

In Wikipedia it is defined as such:

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability [...].

We practice an agile approach where I work, where the architecture team works in a pretty non-specified agile way and the feature teams use Scrum. By non-specified I mean that there are no strict rules as to how the process is but we use several agile principles. Most importantly development is not done the waterfall way, but iteratively.

Throughout the core software development department we use continuous integration and a lot of automated testing. Daily stand-ups are by definition a practice used by the feature teams, but also sometimes for the platform team, depending on the situation. The platform team has an open weekly presentation of what they did. Also, user stories are not only used for the feature teams, but also sometimes for the platform team, when responsibilities overlap and a product requirement turns out to be a more general platform requirement.

So, yes, I think agile is possible for platform teams, as long as the circumstances (i.e. management and/or product requirements) allow it. What you use and how you use it is up to you.

Answer 2

Agile can work in platform development for the same reasons that it can work in application development, and it can fail in both cases for the same fundamental reasons.

Agile processes, by definition, adapt to their environment. Usually it is the people using the process who adapt it, in order that it remains fit for the purpose of the task that is is being applied to. This adaptability makes agile processes inherently robust, provided that process adaptability can be tolerated in the work environment.

In platform development the release schedules are often further apart and more stable than they are in application development. At first sight, this means that delivering increments of functionality is less useful, and does not provide the same feedback loop as you would get by delivering a usable increment of functionality to a customer. On closer inspection, this is only true if nobody is waiting for the functionality that is being produced, or if it is only the complete deliverable that is of any value.

On the one hand the environment is more conducive to success; on the other hand one of the essential mechanisms for an agile process is missing. As long as the process can be adapted to compensate for the missing mechanism - e.g. by having testers or application developers use the interim deliverables - then the adapted process should still be fit for purpose.

In terms of software design and construction, the software (including specifications) is written in more-or-less the same way: one line at a time, and by more-or-less the same sort of people: software developers; with more-or less the same characteristics in terms of motivation and attention span. The scope of the new functionality might be larger, and the goal defined with a longer term schedule, but it still has to be reached in steps, and those steps can be defined to fit into iterations with some sort of demonstration of progress at the end. Development managers often think in terms of milestones as well as deliverables, so this might only be an evolution from the current practice.

I have seen the Scrum process used by different teams for both platform and application development. The teams implement the process in different ways according to their different needs and different understandings of the process, however the main success factors are the capabilities of the teams (and the individuals within them) and the capabilities of the teams' management.