AgilityBeyondTheSoftwareDevelopmentTeam

From SPA Wiki

Contents 1 Agility Beyond the Software Development Team 1.1 Useful questions for analysing the problem 1.2 Brainstorm: external constraints on agile development teams 1.3 Outputs from work groups in session 1.3.1 Group 1 1.3.1.1 Problem 1.3.1.2 Goal 1.3.1.3 Steps 1.3.2 Group 2 1.3.2.1 Problems 1.3.2.2 Goals 1.3.2.3 Measures 1.3.3 Group 3 1.3.3.1 Problem 1.3.3.2 Background 1.3.3.3 Resolution 1.3.3.4 Alternatives 1.3.4 Group 4 1.3.4.1 Problem 1.3.4.2 Goals 1.3.4.3 Do differently 1.3.4.4 To change it 1.3.5 Group 5 1.3.5.1 Problem 1.3.5.2 What's really important to the dev team? 1.3.5.3 What's really important to others? 1.3.5.4 Goals 1.3.5.5 Options

Agility Beyond the Software Development Team

This was a 75 minute session. The purpose was to explore and discuss external constraints that can hamper the productivity of agile development teams.

The participants divided into groups of 4 and each group picked a specific scenario from the experience of one of its members to work on. They defined their problem, thought about what the goals of the dev team and the other party were, and started to consider the next steps towards the goal. The last step was rushed - a lesson learned was that this session would benefit from more time.

Useful questions for analysing the problem

The group worked with these questions to decide on their goals. (Note: you don't have to answer every one!)

• What do you want?
• What other choices do you have?
• What’s really important to the dev team?
• What’s really important to the other party?
• Where are you willing to compromise?
• What can you learn from this?
• What needs to be done differently?
• What can you do to make a difference?
• What’s the worst thing that can happen if you leave things as they are?
• What’s the worst thing that can happen if you change them?
• What’s the best thing that can happen if you make the change?
• If you can't change a part of the business, can you change what surrounds it?
• Are their requirements really as rigid as they seem?
• Can you find a way of giving them the information that they need while allowing your team to remain agile?

Brainstorm: external constraints on agile development teams

• Fixed price contract
• define detailed scope %2b price %2b timescale up front
• Testing organisation with a fixed schedule (work queue)
• Low tolerances on budget
• Getting customer sign-off at the right point
• Customer buy-in
• Getting customers to prioritise
• Quarterly meetings to approve projects
• Hard to find someone to take the role of/represent the customer
• Prevented from talking directly with customer
• ISO-9000 certification
• Lead time on language translations

Outputs from work groups in session

Group 1

Problem

• Dictatorial PM paying lip service to agile.
• Single channel of reporting to senior management

Goal

• Change of PM behaviour to facilitate agile. Remove choke point on reporting channel

Steps

• Replace PM by senior management
• Open reporting channels
• Any other ideas welcome...

Group 2

Problems

• The "customer on site" is not helpful in prioritising stories
• The velocity of the team does not stabilise
• Consequently, forecasting is impossible

Goals

• Line management: understand risks of not meeting planned delivery date, steps that could be taken to reduce the risk
• Team: Get good experience of XP and deliver quality software
• Team: Work in stable, predictable environment; avoid frustration
• Customer: Get all planned features delivered with high quality

Measures

• Education
• Team members must master the practices and techniques better
• Customer and management must understand their obligations in the process and the benefits to be gained
• Prescription: run planning game and XP game sessions to help both of them learn about Scrum/XP
• Talk to business analyst and customer to explain that there is a problem
• Hold monthly planning poker sessions and retrospectives
• Spread expertise by mixing up programming pairs (seeded by XP coaches)

Group 3

Problem

• Management wants to stop pair programming to double results

Background

• Long project (10 months) using XP
• Near delivery date
• Excellent results in iteration in terms of deliverables, quality and schedule
• Senior management (CIO) pushed to end pairing
• CIO not close to project team
• External influence from parent company

Resolution

• Advocacy, fight back against the decision
• Results dropped after one iteration without pairing
• Backed by metrics

Alternatives

• Trialling the change on a smaller project (if similar is available)

Group 4

Problem

• Laborious checking of specifications

Goals

• Team: wants to get on with development
• Management: wants spec checked so that they can be signed off for CYA

Do differently

• Customer must be less remote - or get good proxy customer
• Sign off on detailed scenarios rather than full spec

To change it

• Educate management and get them to change sign-off criteria
• Encourage customer to engage more, or shorten communication chain to customer

Group 5

Problem

• Four different groups
• Dev team
• Project management
• short-term customers (traders)
• long-term customers (business managers)
• Competing priorities and goals
• No obvious point of common interest to resolve conflicts

What's really important to the dev team?

• People want to be heroes
• People want to be a team

What's really important to others?

• Traders want to make money; short term concern
• Business managers want to hit long-term constraints
• Project managers want to demonstrate influence and control

Goals

• The dev team has a common goal
• The delivery team has a common goal

Options

• Sack the heroes
• Let the heroes play to their strengths
• Incremental change
• Radical change
• Expose the problem