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.

What is the perfect office environment for agile development?

The first of the April Practical Agile Meetup’s  conversations was about the best environment for agile development.

Disney Castle

When you develop upon a star…

And the first thoughts were “It Depends”.  Different stages of the development have different needs. Discovery needs a space for discussion, Development needs somewhere to sit.  A fixed space is bad and teams ideally should be able to determine their own layout (taking into consideration Health and Safety requirements).

The Disney Brainstorming Method was brought up. This is a process for creating and refining new ideas using Dreamer, Realist and Spoiler point of view.  The idea is using 3 separate rooms where only the Dreamer POV is allowed in the first, only Realist POV is the second and only Spoiler POV in the third. The idea behind this is many ideas can be examined and refined without stifling initial creativity.

Whiteboards proved a great source for discussion, with many teams using them to partition off their workspaces in open plan offices in addition to their more traditional role as scrum boards and idea capture.

It was felt that all too often that everything gets written down and they can quickly become noisy and out of date. We’ve all encountered the lonely whiteboard in a deserted room with “please do not clean” scrawled on it. If it’s important why not take a photo and then it can be filed and shared as needed and the board is ready to be used again?

The group discussed the virtues of Physical vs Virtual  Scrum boards. Many teams used both which led to the question of which one showed the reality? The majority opinion was it would be the electronic version but that it needs to be used properly with team members burning down estimates and making sure tasks and stories were updated in a timely manner.

The duplication of information has a potential of causing confusion and in some cases the Scrum Master updated the physical board to make sure it reflects the virtual board.

Many teams have large monitors to display the team metric. One point of view was that this can be seen as a pure PR exercise to show internal and external customers that this is a high tech hub activity. However real time data can be very useful to the team where it is appropriate and desired – for example build health.

The need for a public display of information was felt to be an important part of the Transparency needed for Agile by making easily visible the progress and status of work to the team, stakeholders and other teams. Again this brings up the need to identify what is needed and useful to communicate to the wider audience as well as the team.

One common issue always seems to be noise level; My team has a healthy buzz, Your team is making a racket. Communication is central to agile. Tolerance and Respect for each other would seem to be the solution, with team members feeling comfortable enough to call out when there are issues.

As an offshoot from the main topic under discussion, an interesting method of dealing with tardy team members ( a general sore point for everyone) was suggested. At every meeting an individual is late for a mark is tallied against their name.  At the end of the week/sprint the team member with the most tardy marks buys the treats.

Clock Cake

There’s always time for cake!

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.

Agile in a Waterfall World

When discussing how to run agile projects in a more traditional organisation a lot of the focus was around the tension around “iron triangle” projects where scope, schedule and cost are fixed which is very contrary to agile projects where scope often emerges throughout the course of a project.

One of the key areas discussed to address this was the importance of the role of a product owner in a scrum team as this person is generally the face of the project to the business and is key in earning and maintaining the trust of the stakeholders through transparency and regular updates.

There was mixed experience in the groups with some organisations having full-time product owners (often recruited specifically into the organisation to do that role) but others where the product owner role is assigned to someone who already has a full time day job and may struggle to juggle the commitments of the role.

This often leads to “proxy” product owners, subject matter experts taking on board some of the role, and in some cases panels of product owners for a single product. One thing that was universally agreed was that there must be a single accountable product owner at any one time – a “single wringable neck” who has the final say on scope.

Another area of discussion was that sometimes development teams implement agile practices but other business functions are not so responsive, for example there is often a dependency on teams to produce training or marketing collateral and these teams may be accustomed to lead time and absolute deadlines. With incremental and iterative releases and changing priorities these long lead times obviously cause issues.

Engagement with other teams with a dependency on a regular basis (such as sprint reviews, standups etc) obviously can go some way to keeping the business in the loop and allowing other teams the visibility of changing schedules and progress.

Often within organisations the road to agility is embarked upon by development teams in isolation, but where these teams have worked with other departments to explain and demonstrate the benefits of an agile approach it has been shown that these same practices can be adopted to manage their own workflow and their output can be delivered incrementally and iteratively in step with the output of the development team.

Please feel free to add your comments.

Practical Agile Is Born!

On Tuesday the 5th April 2016, we held our first session of Practical Agile. Agile professionals from prominent North East employers, including  hosts NCFE, Sage, HMRC, DWP, Orchid Software and Coatsink Software, met to discuss their experiences and challenges.

The night started with an overview of the aims of the group, which is to create a community to share knowledge and support each other in real-world agile challenges.  This was followed by a brief 5 minute run through of NCFE, their current approach to software delivery and the challenges faced.

20160405_181740

 

Following this, we broke into two groups and the conversation began.  The first topics up for discussion were decided based on feedback from those who had registered to come along.  These centered around the relationships between the multiple specialist disciplines within scrum teams, and getting the balance between agile practices and more traditional project management expectations.  You can read more about the key discussion points here and here.

The evening was well received, and we are looking forward to the next session in a months time where another company will share a brief overview of their team and the topics for discussion will be decided by a vote on the day.  If you have feedback from the event or suggestions for future topics, we would appreciate it so please add a comment below.  We’d love to see you there, if you would like to join us please register here.