social aspects of agile software development teams

1
social aspects of agile software development teams

• elizabeth whitworth
• XP Day, London Nov. 2007

2
Background

• User experience specialist
• B.S., M.A. in Human-computer interaction
• Interests
• communities groups
• personal relationships (technologically-mediated)
• human-centered software development processes

3

• Agile motivation, excitement high
  performance
• Why are these people so excited!?
• What is the subjective experience of being in an
  agile software development team?

4
What your getting

• Research method
• Interesting socio-psychological
  experiences/effects related to agile practices
• Questions at end

5
The study

• Literature review (agile, socio-psychologcal and
  self-regulating team theory)
• Interaction with agile community - conferences,
  workshops, and user groups
• Interviews with 22 participants
• developers, interaction designers/managers,
  project managers, agile coaches, QA
  documentation

6
Method of analysis
Grounded theory - systematic collection and
analysis of qualitative data Grouping of data
into categories of experience Construction of
theory that is grounded and confirmed by data.
Exploratory study
7
Method of analysis

• Semi-structured interview questions
• Describe to me the last project that you were on
  that you felt really excited about
• Which agile practices do you think were
  especially valuable for your team?
• How was this project different from other
  projects you have been on?

8
(No Transcript)
9
Final research focus

• What aspects of agile software development are
  related to team cohesion?
• Cohesive teams teams that click gel and
  really work together to develop software.
• Project chemistry, positive team climate
• Why, from a socio-psychological perspective, are
  agile methods so strongly related cohesive
  teamwork?

10
Agile culture speed ease

• Whole team involvement
• Agile values, e.g. trust, openness, respect
• Agile culture of action and change
• Collective vs. individual or task-based thinking

11
Social identity theory

• Individuals have several social identities
• Social identities correspond to perceived
  membership in social groups
• The salience of a given social identity depends
  on social context

12
In-group out-group bias

• Mere categorization into groups will instantiate
  a bias that effects motivation to communicate and
  collaborate

13
Identification with the agile project team

• Agile culture practices increase the prevalence
  of the project team identity - a shared identity
• Increase levels of security, comfort, belonging,
  willingness to cooperate
• Reduction in stress and tension associated with
  inherent role conflict

14
A clear objective

• the most business value to the customer in the
  least amount of time
• Quality
• Have you been on a really dysfunctional team?
• In some ways that spec driven team was a bit
  dysfunctional, but that might have just been my
  perceptions. Um its bits where theres more
  push to meet the spec than to meet the customer
  needs. I mean, in my view thats dysfunctional,
  but in terms of most software engineering teams,
  its not.

15
Agile planning the planning game

• User stories are estimated, prioritized, and
  planned for each iteration
• Planning conflict
• And then the other thing where there is a lot of
  tension is just when you develop a feature there
  is only so much you can do, you cant - well the
  product specialist will often come in with a list
  of a 1000 items on it. And frequently the
  acceptance criteria will include things that are
  just impossible to do.

16
Agile planning story boards
17
Agile planning is like dancing -)

• There is this dance that takes place and the
  developer estimates, they say well I can do 50 of
  those. and we will have discussions about that a
  lot earlier, and that also causes a little bit of
  tension because now the product specialists
  realize the implications of all they are asking
  for. And then likewise the developers realize
  that they actually do need to put some thought
  into how they are going to do something so that
  they can provide reasonable feedback and
  reasonable estimates.

Inherent role conflicts are easier to digest -
not subjective Increased responsibility for
current stories Reduction in stress increased
sense of control
18
Agile planning responsiveness

• Agile planning responds to team needs
• Increases feeling of flow excitement
• Team works to capacity and is not pushed past
  its limits

19
Short term planning ok, I can live with it

• seen as temporary/ non-fatal
• Team interactions are more relaxed
• exclusion by design vs. inclusion by default
• increased willingness to compromise or make
  concessions

20
Long term planning hard to do as a team

• Now that we are falling out of agile a little
  bit we are...starting to...not do waterfall, but
  we are kind of starting to forecast what we are
  going to be working on in the next year. So its
  putting a bit of a strain on development and us
  because, you know, development needs to identify
  how long its going to take them to do something
  and then we need to get requirements. But no
  ones even thought of it because its, you know,
  12 months from now. So were all kind of figuring
  out still how we can manage that.
• Increased apprehension, worry stress
• Reluctance to invest in team activity
• Insecurity lack of control over a project

21
Regular iterative delivery

• Increased sense of immediacy
• Increased energy
• You are working on something and at the end of
  the week it goes out to the customer and you get
  feedback right away. And thats great, because
  your work matters every day matters. You notice
  when we have a new product and you are working on
  it for 6 months and then it is really tough
  going because you are not delivering.

22
Regular iterative delivery looking for the
end

• Its not very pro-agile thing to say but I think
  probably one of the differences is on projects
  where there is a definite deadline, and a
  definite definite goal that has to be met. A
  little bit more, you know, just looking a bit
  more focused when there is some sort of fixed
  deadline.

The buzz is missing on projects with no
end-goal Group focus and motivation is hard to
maintain
23
Regular iterative delivery a history of
success

• The main point is that I feel more secure about
  what Im doing. Very strongly. You really prove
  after two weeks that this thing is really
  working, in a more or less stable way.
• We will do it. We always do it.

High levels of trust and security
24
Regular iterative delivery process
improvement

• In a waterfall project you can see two people
  say two different things and look at each other
  and say What? And you know, they may have
  worked together for three or four years. Because
  they dont have a holistic understanding of how
  they build things. And I mean, thats one of the
  biggest differences.
• Regular team retrospectives
• Strong improvements in team relations
• Increase in feelings of acceptance belonging
  Increased ownership involvement

25
Whole team awareness and acceptance

• Agile constant feedback to individuals that
  all team members share awareness of team
  activity, and commitment to team goals.
• Awareness and feedback from the team as a whole
• Construction of common knowledge

26
Daily/weekly group meetings

• Support whole team awareness and feedback

27
Daily/weekly group meetings

• Forum for non-task based items

28
Daily/weekly group meetings

• Social pressure accountability
• Recognition support

29
Daily/weekly group meetings

• Communication is not need-based
• It used to be, so for instance before agile was
  adopted...we would meet with the product
  specialist once a week and they would tell us
  what they wanted and what was going wrong and
  bugs remaining and so you get the overall
  impression was like they were demanding they
  were always complaining and never satisfied

30
Daily/weekly group meetings

• plausible, achievable chunks of activity

31
Information radiators

• Increase awareness and certainty regarding
  project activity
• e.g. Burn down charts

32
Information radiators noticeable measures of
progress

• And that little dot is like an endorphin rush.
  Its like, Woohoo! And the team sees the
  progress, and its great.

33
Information radiators noticeable measures of
progress

• High level of awareness of individual
  contribution to the team goal
• Increase the sense of importance of the team
  endeavor
• Increase sense security commitment
• Increase identification with team willingness
  to invest effort in the team endeavor

34
Socio-psychological climate of high-performance

• Agile methods associated with perceptions of high
  levels of self-efficacy control.
• Negotiation of a flexible plan
• Group forums for whole team awareness and
  feedback
• High levels of efficacy and control --gt
  increased performance due to motivational effects
  (Baron Byrne, 2000), and reduced stress
  resulting in a decrease in performance errors
  (e.g. Huang, 1998).

35
Further reading

• http//www.ewhitworth.com/html/ma.html
• Download my thesis to find
• Discussion Conceptual framework detailed
  description of the teamworking and
  socio-psychological theory considered in the
  study.
• elizabethwhitworth_at_gmail.com

36
Wrap-up

• Its not just physical! Agile methods create a
  social context that supports cohesive teamwork
• This study has only scratched the surface of what
  is really going on in agile software development
  teams
• A better understanding of such social processes
  could support the the development of tools e.g.
  for a distributed environment.

37
Que?tions
38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
Images of monkeys
43

• agile software development teams
• complex adaptive socio-technical systems

44
Regular iterative delivery get the big
picture

• On other projects or teams that I was on, it was
  very much you define a bunch of features and then
  you worked on them for months and then you bug
  fix for twice as long and that was the release.
• So you really didnt know what the big picture
  was, ever.
• You just knew that one of these or a couple of
  these features were what you were supposed to
  work on for however long and then you are just
  fixing bugs for ten months or well thats an
  exaggeration, but thats pretty much what it felt
  like.

Increases understanding of the big picture Allows
pride and involvement in collective effort