Debate on process

A week or so ago our daily standup suffered from a minor conflict. In my graduate role I wasn't in a position to lead the situation as I might have previously, but; there are still ways to gain leadership experience by reflecting on the situation. My wife and I adapted an early-learning model called Notice-Recognise-Respond and I used the framework to shape my thoughts and inform my practice.

During our daily standup I noticed frustrations as team members were being asked to self-select tasks from a large pool, yet they felt they couldn't because it wasn't clear what is involved for the said tasks. Discussion arose around the use of processes, with one team member in particular strongly advocating for their use and others arguing process was responsible for slowing down development. That is to say, time spend in grooming, using sprints and retrospectives was time wasted. For both points; past experience was raised to illustrate project successes and failures based on both the use and lack of process.

I recognise there has been a lot of change in the team and we started the project with a very strong focus on Agile practices, their rules and expectations. The rules have recently been changed, including the scrapping of the two week sprint. The experience in the team is also pinpointed to a few senior members and their experiences have taught them different lessons.
I also recognise that in order to move forward as a team, it is important to be solutions-focussed, to ensure the team continues to communicate effectively and to make decisions which are understood and able to be actioned by everybody.

If I had been the leader in this situation my response would have been to drive towards a solution which showed a compromise between the need for process [robustness] and the need to avoid time-heavy processes which add little/no value [speed]. My response would acknowledge the experience of the group by asking them to identify specific processes which are essential and which are hindering development. I would ask the team to (together) create a 'lite' version of an agile practice (such as scrum) which would achieve a balance between robustness and speed. For example, keeping a sprint would make progress measurable while exchanging 2-hour retrospectives for an on-the fly channel in the teams app might help speed things along.

Most importantly, the solution would need to have measurability, so that the team can effectively evaluate their progress, prioritise both work and blockers and recognise/celebrate achievement of their goals.