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]
2 Responses
Velocity of each individual iteration will be a different figure. There are many ways velocity gets impacted. Apart from planned absence (planned leave, training etc.) and holidays, there could be unplanned absences caused by illness, personal emergency etc. which impact velocity. User stories that do not get completed in an iteration get moved to next iteration. This brings down the velocity of the iteration where the story was started and bumps up the velocity of the iteration where it got completed. This being the situation, good practice is to take an average of last five or six iterations as the velocity of the team. Team stability is another factor that impacts velocity. Teams that have higher churn will see higher volatility in velocity. Other factors such as change in technology, adoption of new tools, increase in automation, will also impact velocity either positively or negatively! However, if team is stable and has reached “performing stage” steady rise in average velocity will be seen over a period of time till any of the factors mentioned above comes into play and impacts it.
Thanks Milind, fully agree with your comment.
Finally, irrespective of the increasing trend in velocity, there is improvement for sure. This cannot be missed, if observed. One of the intent of my blog is to encourage this observation, by taking a mildly provocative stand.