the very first blog
by Konstantin Petrov
Here I am explaining my views on software development using agile methodologies.
All the examples will be from my experience.
Agile manifesto says:
Let’s address them one by one.
We are all different. Cultures, background, age, gender. It’s good, diversity gives us wider sight of the landscape.
However, it can be challenging. To effectively interact with people with background differing from ours we need to be more understanding, careful and usually we get to know colleagues quite deep to read all the signs going underwater.
It is good, again, for us as human beings, but it is hard. Each and every of us has families, many have kids so our minds are already busy with many relationships.
Keeping number of direct peers lower help save mental fuel to spend on creative work and if needed on deeper and more understanding interactions with fellow team members.
We are doing it not only for fun. Otherwise we would have amazing Scala-Kotlin-Node-Elastic-ClosureJS masterpiece with no purpose.
Software comes from the requirements. They are made by stake holders and forged by PO in form of actionable tasks. As my experience as substitute PO and also by observation of other POs I could tell that usually holders of the role is overloaded.
That isn’t good, because overloaded people get upset, make errors, forget details and become rude in communications.
Don’t forget that PO presents user stories to the team and this activity is one of the key actions in the sprint planning of the team - discussion, deliberation, estimation - or refinement, if you wish. The process of refinement is time and energy demanding.
Keeping team smaller can reduce discussion polarity, but also can lead us to have smaller projects ans narrower project scope.
With bigger PO pool there are possibilities of narrower specialization of each and therefore deeper analysis of all user cases.
Also, teams working together more and POs working together more can get better understanding of user needs. Example - many meetings became more productive when I was backing up our PO. It happened not only because she wasn’t roughly outnumbered but more because there was second opinion at our disposal.
With smaller projects and narrow responsibilities there are less space for parallel work - of course there is still space for it - and therefore change of the direction is easier. Smaller teams has less inertia.
tags: agile - scrum - product owner