Keerthi, a successful team leader in a Kanban team, got a promotion based on her outstanding contributions and was asked to be the scrum master for a scrum team that was being put together to create the next generation single sign on front end as the first step to integrate diverse applications that were part of the company’s portfolio.

Some of these applications were home-grown, while some others come to the portfolio through acquisitions over the years.

Keerthi understood the need for an overarching architecture that can evolve as applications are onboarded, as it is was not possible to do detailed assessments of each application and then come up with a design that will cater to all the applications.

She remembered that the 10th Agile principle said:

” The best architectures, requirements and designs emerge from self-organizing teams”

So, her first thought was to make the team self organizing so that the architecture would be created.

But, that was easier said than done.

Though the team was constituted with experienced members – as this was a very critical project for the organization – there were very divergent views on how to do this.

Mukund, the designated tech lead felt that he should be doing the architecture by himself and that the rest of the team can be onboarded after 2 sprints – by which time, he should have detailed it out.

Radhika, who was moving from a mainframe application team felt that it would be necessary to have a meeting with all the applications, get their specifications, get them signed off before the team can start anything.

Sukrit – whose 7 year experience was with various teams that had adopted Agile practices, felt that according to the principle, they should have a sprint 0 of undefined duration to explore, experiment and elaborate the architecture.

Keerthi was able to appreciate where each of these persons were coming from, but was not convinced that the principle was understood clearly by anyone, as her preference was to have an evolutionary architecture.

How can you help Keerthi interpret the 10th principle in her context and move ahead?

Suggested Solution:

I do not agree with this fully, when interpret as no upfront architecture is needed, or that a flexible-duration sprint 0 is needed to help the architecture emerge..

I believe that there should be only ONE ARCHITECT for a solution. But, this person may be assisted by multiple architects, to evolve a single architecture

This architect is somewhat like to Product Owner, who create the functional vision for the product. The technical vision that would influence the roadmap of evolving technology

In our guidance, we talk of the SM, PO, team and also a fourth role of a tech lead / architect, that is missed in the classic Scrum framework, but is included in SAFE, DAD or other models.

Adopting a service oriented architecture model would help the team to let smaller parts of the system evolve over time, with clearly defined APIs / web services / interfaces that would help integrate the pieces.

Having said that, it would also help to co-opt the application teams in the initial phase – such as a modified design sprint – to validate early assumptions and base the architecture on those findings so that the surprises in integration later can be minimized.

A collaborative approach is needed beyond this team and that is something that Keerthi should keep in mind.

So, I would interpret the principle as best designs emerge from self organizing teams and best architectures emerge from self organizing teams of self organizing teams. [scrum of scrum equivalent]