XPDay 2007: The Social Nature of Agile Teams - Elizabeth Whitworth

Why are agile developers so excited?

• What aspects of agile dev are related to team cohesion?
• What makes a team really gel on a project?

Speed & ease of interaction:

• whole team involvement
• trust, openness, respect
• culture of action & change
  • immediate action that they could take in the near future
  • individuals could see themselves make a change
• agile participants had a more collective viewpoint

Social identity theory

• in-group out-group bias: just naming different groups biases the dynamic
• agile culture increases the strength of the project group identity rather than dev, biz, etc

Planning

Planning game makes the conflicts more visible and allows developers to take more ownership over development process

Planning responds to team needs — tasks are neither to hard (anxiety) or too easy (boredom) — increases feeling of flow

Short term planning increased willingness to compromise — team interactions more relaxed

• increased feelings of security & comfort

Long term planning hard to do as a team

• gives rise to feelings of insecure, apprehension, stress
• having to make decisions for things 6 months in advance

Regular Iterations

No definite end goal caused loss of “buzz” — group motivation & focus hard to maintain

Consistent delivery over multiple iterations gave rise to feelings of confidence & security

Whole team awareness

Constant feedback to individuals that all team members share awareness of team activity & share commitment to goals

Supported by daily group standup:

• Forum for non-task based issues
• Extra motivation (disapproval from team) and validation of requests
• Recognition of what’s possible and what’s not
• Communication is not need-based — allows other topics

Group standup supported by chunked activities

• Something to report if small enough chunks
• Loss of motivation if stuck on same task for whole week

Information Radiators: noticeable measures of progress

• completed stories “give endorphin rush”
• also supports awareness of individual contributions to team goal (others as well as self)

Performance

Increased sense of control & self-efficacy improves performance

Conclusion & Questions

http://www.ewhitworth.com/html/ma.html

Have a list of weaknesses at end of project, for example:

• agile focussed on developers — makes them feel good, but QA & documentation felt isolated
• high-level of interaction sometimes resulted in burn-out

Data collected from:

• 5 participants from one company
• 17 participants each from different companies

Agile is a method that helps people work as a team in the software development environment

Frank Maurer (Uni. Calgary): agile planner — distributed planning for agile teams

XPDay 2007: Building a Ubiquitous Language Using Naked Objects - Dan Haywood

Irish Govt’s Dept of Social & Family Affairs are very committed to agile

Synopsis

• Eric Evans’s Domain Driven Design — tackling the complexity of the domain itself … not even specific features
• Martin Fowler — models are just a map of the real world, they “are not right or wrong, just more or less useful”
• “Ubiquitous language” aims to unify the vocabulary between business and developers

Tangibles

• Uses reflection APIs to expose domain objects directly in user interfaces
  • (Written in Java 1.1 so can be exposed as a .net dll)
• Goes beyond CRUD as can expose public methods as actions on objects
• DSFA had a green screen environment previously, so any user interface was an advantage…
• Generic user interface:
  • repositories down the left (can locate entities by type)
  • then window shows representation of entity with properties and references to other entities
  • also shows actions on properties (e.g. name —> “Legal change of name”)
  • generic interface needs training to use, but can be skinned
  • protocol between client and server is pluggable
    • Irish system is stateless, has optimistic locking and doesn’t get updates live
• used to build self-contained apps to demonstrate
  • but customers didn’t have enough experience/installed software to properly understand the application
  • so built Wink demos to use in browser’s flash plugin

Development Environment

• Based in Eclipse with plugins
• Uses Spring to tie things together
• Use fixtures for test data — use composite pattern so can reuse over user stories
• Can build as Swing app, web app based on Jetty or RCP app

Business rules available:

• Can hide or disable properties
• Can validate before accepting
• Uses modify before set — in order to set up bi-directional relations

Sister projects:

• Naked RCP
• Naked REST — exposes Naked Objects as RESTful web interface
  • Dan’s project for 2008…

Conclusions

As default user interface becomes good enough, discussion turns to domain model instead.

Wizards are for transient apps (Inmates are running the asylum — Cooper)

• Sovereign apps gets used everyday, all the time
• Naked objects are good for sovereign app and building the domain model (not so good for wizards)
• Could then add a custom object that maintains its own state for building a wizard, or else use POJOs that were generated from within some other framework
• Use Naked Objects for building and debugging the domain model

Q&A

Are there any compromises in order to use Naked Object UI?

• Navigating large collections can be awkward
• Probably want to alter the domain slightly — view most recent, search by date — rather than view all

Since can code quickly, can actually think of pair programming with your customer

What advantages does Naked Objects give over Rails?

• originally, MVC controller was to control the objects; been distorted so that it now controls the user
• Naked Objects allows you to adjust domain easily independent of user controller
• Rails insists on a user controller or just offers CRUD

XPDay 2007: Embrace Uncertainty - Jeff Patton

I came in 10 minutes late for this keynote. Train problems…

Results of stories don’t need to completely satisfy the customer — the aim is to get value and reduce risk. Iteration retrospectives should evaluate on these two goals:

• Did we get some value? Could we get more value? Biz should answer this.
• Did we reduce risk?

It’s ok to do the simplest possible thing that could possibly work, rather than the simplest thing that could be released.

Three different customer prioritising strategies:

1. Follow the money — go for a single business benefit at a time
   • cuts out whole swathes of stories and simplifies iterations
2. Don’t choose your solution too early — look at what the user wants to accomplish and defer choices as late as possible
3. Build up feature quality iteration by iteration — need everything but can build up quality and complexity
   • e.g. building a bus — can’t
   • e.g. leave out AJAXy stuff until later, improve performance gradually
   • if build to ideal quality in each iteration then may miss out vitally important function
   • customers say “great, it’s done, let’s move on”
     • so have a report card across the features: D to A
     • can say to customers, “you have your X but it’s D quality now. You’d really want better”

As soon as you start to be dogmatic about following the process, you’re dead!

Q&A

What’s your idea of the role of business analyst in agile?

• in commercial software company like Yahoo, there’s no such thing — instead they have designers
• would like to see BAs take more design responsibility for what they’re doing
• in enterprise software houses, have business people talking to BAs, talking to developers

How do you deal with multiple business voices?

• use user-centred design & scrum product owner
• product owner takes responsibility for direction of product
• understands the different factions and can answer to them why the development is going in that direction

In Yahoo, have designers but also product managers — how do they fit in and can we learn from them?

• they choose direction of business value from choices given by designers

If stay uncertain, how much is it going to cost?

• strategies outlined before came out of fixed price projects
• play space is users to support, kinds of things to do, quality of resulting product, etc

See Jeff Patton's blog version for more details