Communication in Agile Teams

The second of the April Practical Agile’s Meetup discussions concerned communication in Agile teams.
Tin Can Phone

The first subject that came up was how do you signal your availability to communicate? A “Headphone” standard was proposed as follows:

  • Both Headphones in – I’m in the zone. Leave me alone. Send me an eMessage.
  • One Headphone in – I’m busy but available to communicate.
  • No Headphones in – I’m eager to communicate.

This did lead to the question of how much headphone usage was acceptable? We’d hope that in a self organising team that individual would be putting the needs of the team first and would be actively listening and ready to contribute as necessary – not just to their immediate team, but to the whole .  If the job is getting done is there a problem? It goes back to the concept of T-Shaped People.

How much communication needs to be recorded was a clear topic. The Agile Manifesto values “Working software over comprehensive documentation” but we need to remember that the documentation side still has value. An interesting perspective was that the User Story was a promise to have a conversation. Decisions should be logged somehow – and the use of tools such as TFS and Jira can be easily used to record PO decisions etc. The standard rule of thumb seems to be if you need to ask the question record the answer.

An interesting perspective was that the User Story was a promise to have a conversation – which aligns with the Agile Manifesto valuing “Customer collaboration over contract negotiation”.

Over communication can be a problem with “Reply To All” being regarded as the work of the devil – though perhaps the original emailer may be to blame for distributing it too widely in the first place?

Definition of Ready can be useful by clarifying what criteria is needed to start and leading to discussion of If and Why a story is not ready. BDD and Given-When-Then style criteria (Gherkin) can help clarify any issues and pick out any assumptions,

A team needs to be realistic and be comfortable that some of the finer detail can be thrashed out once the story has been started. The team should be empowered enough can consider whether they feeling any “missing” details are within the remit of the team to determine.

Amigo sessions were once again highlighted as useful tool – helping to kick off communication and common understanding.

It was raised that a mature team’s definition of ready can be unspoken, but on the other hand this could cause confusion for any new joiners.

Who would cross the Bridge of Death must answer me these standard questions three, ere the other side he see

Monty Python and the Holy Grail - The Bridgekeeper

What is your name? What is your quest? What is the average velocity of a 2 week sprint?

The daily Stand-ups were discussed. The value of the 3 standard questions was questioned. An opinion that a simple update as to what you were working on should suffice as the team should already be aware of any issues and problems was generally agreed with.

The Stand-up can also be used as a check before any new work is started that there are no in-play tasks that could be assisted with. The team need to be focusing on the bigger picture rather than just their “own” tasks and a Story isn’t done till it’s all done.

A useful Stand-up tool that has been mentioned before was a confidence check.  After the updates  each participant gives their confidence in completing the Sprint goals by revealing a number of fingers – Five for Very Confident to One for Very Worried. This can stimulate conversation and potentially address problems early by focusing the team on them.

Finally, I think what really ran through the discussion is that Communication is about Respect. I’m off to put on my headphones and look forward to seeing you next time.

Advertisements

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.

T-Shaped People

The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own. – Wikipedia

The first topic up for discussion at our March Meetup was about “T-Shaped People”.

Mr. T

I Pi-“T”-y the Fool

A T-shaped person was considered to have a specialisation (Coding, Testing, Analysis) as the Vertical to the T but with at least an understanding of other complimentary areas as the Horizontal to the T. The idea that a person could be skilled in all things was felt to be an unhelpful ideal and rarely existed in reality.

The discussion then brought up areas where it seemed a T shaped forms almost naturally. Examples included Testers having great analytic skills, Analysts having customer focus and so potentially able to see testing and UX skills. This led to the feeling that T shaped people need a Team, where they can be critical of themselves  and allow themselves to be criticised, in order to be most effective.

T-shaped people will develop when the team is actively pulling together to meet the teams goals. The team must appreciate that the team succeeds (as in the story is done) rather than the individual succeeds (the coding in complete, a bug has been found).

A useful tool repeatedly referenced as a way of helping increase the awareness between different specialisations was “Three Amigos

With the Three Amigos a Coder, a Tester and an Analyst come together to discuss a story’s criteria and remove any misunderstandings about what the story should deliver. They can then discuss the development and testing approach to increase understanding and potentially reduce any duplication of effort. This early working together can help increase appreciation of the others jobs and add to the Horizontal Bar of the T as each of the Amigos learns from their counterparts.

The Three Amigoes

I’m Business!  I’m Development!  And I’m Testing!  And together we are The Primary Perspectives!

The subject of closer working was considered. Pair programming has many benefits – including better code quality. Pairing a Tester and Developer seemed very desirable especially where Test Driven Development was the idea. The pairing works together not to “find” bugs, but to identify and address issues as quickly as possible in order to be able to drive a story to “Done”. There was some concern as to making sure that a critical distance was maintained to ensure that neither side was dominating the scope of the testing or development.  Again the 3 Amigos technique helps to drive this behaviour by forging that common understanding up front.

One further question raised was how deep should a tester go? Should they be reviewing the code? It was felt that that it is helpful for a tester should know the basics which would be sufficient to “talk” to the developer without needing the fine detail.

In conclusion there seemed broad agreement that a T Shaped Person is defined by their Mindset (What can I do?) rather than their Skillset (I can do this) and the desire to ensure that the Team succeeds and not just the individual.