Agile – Special Interest Group (July 2015) Post Meeting Report

  • Published on: 29 July 2015
  • By: Lesley Michaelis
Agile – Special Interest Group

Following on from the group’s inaugural meeting, it was decided that the July meeting should be used to discuss Distributed Agile and how to ensure successful multi-location working.

Hosted from two locations, London and Liverpool, the group was connected via video conference.

The agenda covered the following aspects:

  • Setting up for success
    • Understanding the cultural differences and techniques to mitigate mis-understandings
    • Creating “one team” over distributed locations
      • Governance
      • Building a successful team
      • Roles and responsibilities
    • Tools and Technology
      • Communication tools
      • Collaboration tools
      • Planning tools
    • Case Study

The meeting started with a video demonstration of a distributed Scrum which highlighted some key issues of potential pitfalls of not taking the time to set up for success.

Issues highlighted were:

  • People arriving late
  • Video conference facility not working
  • Dial up back up - remote workers not able to hear
  • Unstructured approach to meeting
  • Scrum Master did not take ownership and look to resolve impediments
  • No consideration had been given to time difference
  • Both on-shore and offshore had been working on the same piece of work the previous day as there was no common tool or understanding of who was doing what
  • It became apparent that the deliverables that were due would be late due to some outstanding information that was needed - this had not been highlighted previously.

The issues highlighted in the unsuccessful Scrum were discussed throughout the rest of the meeting.

Understanding Culture differences

One of the key issues that was highlighted in the unsuccessful Scrum was the differences in culture between the West and East. To ensure that you are set up for success it is important that both sides accept that there are fundamental cultural differences between East and West which need to be understood e.g. the hierarchical nature of the Eastern culture, the perception of time, structured versus unstructured way of working and individualism versus collectivism. Once understood and acknowledged, there are many benefits that the cultural differences can bring which actually make this a great model for Agile delivery.

The Theory

Edward Hall was an American anthropologist who classified culture into two types:

  • High context: individuals have close connections over a long period of time and because of this, there are many contextual elements that help people to understand the rules. As a result, much is taken for granted and doesn’t have to be fully explained. This can be very confusing for someone who does not understand the 'unwritten rules' of the culture.
  • Low context: individuals have many connections, but for shorter duration or for specific reasons. Because of this, very little is taken for granted. Whilst this means that more explanation is needed, it also means there is less chance of misunderstanding; particularly when visitors are present.

Where do India and the UK sit on this scale?

Hofstede's cultural dimensions theory

Hofstede developed his original model as a result of using factor analysis to examine the results of a world-wide survey of employee values by IBM. The model allows quantifiable scorings for five dimensions of culture, allowing clear comparisons to be made. These dimensions are as follows:

  1. Power distance (PDI) – perception of power and authority
  2. Individualism vs collectivism (IDV): Individual vs “group” cultures
  3. Masculinity vs femininity (MAS): Competitive and assertive vs modest and caring
  4. Uncertainty avoidance (UAI): Tolerance for uncertainty, ambiguity and unstructured situation
  5. Long term vs short term orientation (LTO): Thrift and perseverance vs “saving face” and fulfilling social obligations

How do India and the UK compare?

The work style of different cultures will not always align. Understanding of the differences, bear them in mind and find ways to prevent any conflicts due to variances in behaviour or understanding.

Key differences between Western and Eastern cultures manifest themselves as below:

  • Perception of power and authority - Eastern culture work with a formal hierarchical framework
  • Time - Eastern culture will see time as continuous, hence will not be so “rule bound” as Western culture
  • Collectivism - Eastern culture will work in close knit collective teams; Western cultures tend to work as individuals within a team
  • Vocalising limitations - Eastern culture will not wish to say “no”/Western culture is more direct

The participants gave their insights into some of the issues they had faced and all acknowledged that had they understood the cultural differences at the start of the relationship, many of the problems they experienced could have been avoided.

It was recommended to hold a “culture awareness training session” to enable the teams to understand these differences. The sessions could be held as interactive workshops with all cultures in the room at the same time. This is not only team building, but by acknowledging the differences and making light of the cultural diversity it creates a relaxed atmosphere, helping to overcome some of the differences.

Governance

Effective and pragmatic governance is essential when working in Agile. In approaching a good governance model it is important that you consider the key aspects of what you want to achieve from the governance model.

The group discussed what a “Governance Authority” needs to ensure:

  • Portfolio priorities are aligned with business strategy
  • Projects initiated are aligned with these priorities
  • The right stakeholders are engaged with the project
  • Projects properly resourced, prepared and planned
  • Project priorities and status are always visible
  • Transition to live use is properly controlled
  • Project performance is measured and improvement encouraged

Mapping of a Prince 2 model against an iterative approach

Many of the group highlighted that the governance models that presently exist within IT were modelled on Prince 2 methodology and there was a conflict between how the Agile team worked within the model.

A number of organisations were piloting mapping of Agile methodology to the Prince 2 governance model and working out how best to align the two frameworks. This was seen as very much “work in progress” and evolving, but was a good way of beginning to create a new way of working that suited both methodologies. 

The one team approach – roles defined

The group discussed how important it was to ensure that you had a strong team, with the correct skills and roles and responsibilities understood between all team members. Recruitment of team members and working together in the same location to build the teams was key. It is advised that this is not done remotely.  All Scrum teams should be super-headed by a business sponsor and ideally made up of seven to ten members. Through the help of an “Agile coach”, the rest of the below roles should be decided in Sprint 0.

Product Owner

The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the Product Backlog, and prioritising it based on business value.

The Product Owner:

  • Is responsible for product vision
  • Constantly re-prioritises the Product Backlog, adjusting any long term expectations such as release plans
  • Is final arbiter of requirements questions
  • Accepts or rejects each product increment
  • Decides whether to continue development
  • Considers stakeholder interests
  • Signs off the stories and approves for release

Scrum Master

A Scrum Master is the facilitator for a product development team that uses Scrum, a rugby analogy for a development methodology that allows a team to self-organise and make changes quickly. The Scrum Master manages the process for how information is exchanged.

The Scrum Master:

  • Facilitates the Scrum process
  • Resolves impediments
  • Creates an environment conducive to team self-organisation
  • Keeps the team focused
  • Enforces time boxes
  • Keeps Scrum artefacts visible
  • Promotes improved engineering practices

The team:

  • Is cross-functional (e.g. includes members with testing skills and often others not traditionally called developers: business analysts, domain experts, etc.). Self-organising/self-managing, without externally assigned roles
  • Negotiates commitments with the Product Owner, one Sprint at a time
  • Has autonomy regarding how to reach commitments
  • Is intensely collaborative and self-organising
  • Is most successful when located in one team room, particularly for the first few Sprints
  • Is most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams.
  • Has 3-9 members (originally 7 ± 2 members)

Who does what?

The most effective way to decide who does what in a Scrum team is to define the tasks and then decide as a team, task-by-task, who will be responsible for what.

Here is a suggested list of all the tasks that need to be completed before a Sprint:

  • Scope
  • Cancelling a Sprint
  • Changing the product scope
  • Conveying the product vision
  • Prioritises product backlog
  • Prioritises Sprint backlog
  • Writes user stories
  • Facilitates meetings
  • Facilitates retrospectives
  • Builds the product backlog
  • Commits to a Sprint backlog
  • Remove impediments
  • Motivates the team
  • Protects the team from outside distraction
  • Chooses the amount of work in a Sprint
  • Commits to completing the Sprint
  • Inspects and adapts to improve their performance
  • Manages the team
  • Points out other people’s mistakes
  • Ensures the product works
  • Accepts a story as ready
  • Recognises impediments
  • Accepts a story as ‘done’
  • Ensures something useful is built by launch date
  • Represents the business/customers
  • Keeps stakeholders informed

There are a number of “team building” exercises that can be done with the team to enable deeper understanding and also to obtain “buy in” from the team members of the roles. The group learnt about these exercises and also discussed their positive experiences of having spent time and effort on team building, leading to long term success.

Tools and Technology

As demonstrated at the beginning of the session, planning for and implementing the required tools prior to setting up the delivery organisation is essential to success. Much time and effort is wasted trying to find a room, a conference phone and other equipment to enable communication with the offshore team, in addition to the wasted time and effort of not having shared tools to control workload management.

It is vital that standards and tools are defined upfront and that there is acknowledgement and understanding in order to operate as one team. Aspects to be considered are:

  • Communications e.g. teleconference, video conference, Skype, Instant Messaging
  • Collaboration tools e.g. knowledge sharing, artefacts, screen sharing
  • Planning tools e.g. progress, backlog, resource planning

Distributed locations make communication more difficult due to issues around:

  • Distance
  • Different time zones
  • Lack of face to face meetings
  • Cultural differences
  • Common understanding
  • Working practice

When assessing the appropriate tools it is important to consider the following:

  • How large is your team (how many users)?
  • How scalable is the tool and pricing structure?
  • How do you implement and what level of technical support can be expected?
  • Is the solution hosted or will you maintain the infrastructure behind it?

The answers to these simple questions will not only drive your organisation to the ideal tool, but will also help determine the cost.

The group discussed the benefits of effective communication tools and the key features and functionality required:

  • Key features of communication tools
    • Audio and video conferencing
    • Group and private chat
    • Screen and application sharing
    • Active windows and privacy features
    • Real time drawing and highlighting tools
    • Shared notes
    • Remote control
    • Move between application displays
    • Collaborative input
    • Speaker identification
    • Share files
    • Polls
    • Pausing features

The benefits of collaboration tools are as follows:

  • Effective usage of collaboration tools brings the team closer and enables successful delivery.
  • Onsite developer will have better understanding of the user requirements due to thorough formal and informal communication with users. Such information has to be documented and passed on to offshore team.
  • A wiki can be used to accommodate information from informal meetings, discussions, blogs, help documents, release plans, user guides and patch documentation etc.
  • Knowledge management should be accessible to both onshore and offshore teams. Process improvements, best practices and lessons learnt are some of the key knowledge areas that will benefit the offshore team’s learning curve.
  • Team members can quickly adapt the tool-based collaboration by choosing tools that provide rich user experience
  • Key features to consider:
    • Micro blogs
    • Forums
    • Employee directory
    • Information/resource sharing
    • Wikis
    • Groups
    • Real time chat and communication
    • Idea collaboration
    • Mobility
    • Third party integration
    • Intelligent search
    • Decision approval

Key features and areas to consider in choosing an Agile project management tool is:

  • Customisable
  • Ease of adoption
  • Ability to scale
  • Project visualisation
  • Strategic planning
  • Manage complexity
  • Reporting and analytics
  • Enterprise collaboration
  • Third party integration
  • Deployment flexibility

Conclusion

The event concluded by Quantum Plus providing an overview of a case study where over 60% of the total Agile development activity is performed offshore by 8-10 dedicated Scrum teams.  This capacity was built over a 12-18 month period and the increase in development capability has enabled significant business value to be realised.   

Key to the success of this case study has been:

  • Having a dedicated meeting room with video conferencing and audio conferencing fully available for the teams. The video conferencing equipment was built into the original business case
  • Effective knowledge transfer plan with robust sign-off criteria
  • Ongoing visit and training schedule; the cost of which was built into the original business case
  • Operating as “one team” – competitions, reward and recognition
  • Ensuring the offshore location was seen as an extension of the onshore location e.g. branding, corporate identity, mission and values all part of the offshore teams working practices
  • Ongoing communication plan – Town Halls, IT Senior Leadership team involvement with offshore team
  • Ramping up gradually rather than “big bang”

The group ended with a video of a successful distributed Scrum providing a clear view of what can be achieved with effective planning and putting in place the building blocks as described in the session.

Quantum Plus would like to extend their thanks to all participants and in particular to the customers who provided their facilities for hosting this event, and also the contribution of case studies and real life examples.

Quantum Plus’s next Agile Development Special Interest Group will be in the autumn. If you would like to understand more about this or Agile in general, please contact Lesley Michaelis.