Developer-centric Teams

The second conversation of our March Practical Agile session was kicked off from the question –

“How do you prevent teams and discussions being dominated by developers?”

The God-King Xerxes

All the God-King Xerxes requires is this: a simple offering of Code and Test

The first reactions were that it wasn’t necessarily the developers who dominated, but that it was not an uncommon scenario.

The underlying issue seemed to relate to the culture of the team and wider business especially where a more traditional waterfall mindset was the norm.

Other problems seemed to relate to the state of stories and it was felt that making sure we have a good and well understood definition of “Ready” (to start work) was available as if we know and are satisfied that the story was ready we also have a firm grasp when it would be done. This can cause problems though if the team try and use this as an excuse not to commit to a story and an appreciation that  “Ready” means “Good enough to Start” with an understanding that some of the finer detail can only be drawn out once work is underway.  On the other hand this cannot be allowed to lead to Feature Creep of the Story with the temptation to add “just one more thing”.

The Three Amigos approach where a Coder, a Tester and a Business Analyst go over each story in an informal kick-off session to give a common shared vision of what will be delivered and helps ensure that it is the voice of the team rather than just a single opinion. As well as helping to prevent domination by one area, the 3 Amigos helps communication between the disciplines and promotes understanding of the work required from each area; Development may be relatively straight forward but the test effort is significant (or vice versa). This closer working helps that understanding of what  all sides need to get the story into “Done”.

One area which could drive the perception of developer pushiness is in the technical detail and especially technical debt. It is felt that Product Owners may not appreciate the reasons and value of the technical side and the team needs to be clear about why this needs to be tackled early and the benefits both short (the system will perform better) and longer (future development will be more difficult and take longer) need to be be made clear. For example a conversation along the lines of if we take x hours to correct the code now we will save y hours developing future stories helps clarify that value of doing things correctly in the first place. On the other hand, developers do need to be realistic and there may well be reasons that a feature is needed now – ideally both business and development team need to understand why and what that is driving their needs.

In all cases the Scrum Master has a key role in managing any negative perceptions of dominance. They need to facilitate the ceremonies and meetings to enable all voices to be heard and valued.  They should make space to allow technical requirements and debt to become valued stories and not just an afterthought. The Scrum Master needs to protect the team by identifying and stopping Story Scope creep, encouraging the Product Owner to spin off a new story to address any new/missing requirement not identified when the Story was committed to the Sprint where reasonable, but also making sure that a Story is not approved where the minor details still need to be refined.

Finally what is needed is Respect from all sides, Communication leading to joint understanding of the project , and clear Value for what we are creating.

Advertisements