XPDay 2007: Specification by (executable) Example: Prosperity of the FITtest - Immo Huneke & Robert Brown

• Using Excel spreadsheets to import data into FitNesse test fixtures
• Wiki has “convert Excel table into wiki table” button on input, and conversely “output as Excel”
• Now using Excel spreadsheets directly

Using FIT made tests visible and helped communication in project

FitNesse got too slow after 350ish tests!

XPDay 2007: The Secret Backlog: Behind Every Bug-Report is a User Story - Antony Marcano

• Why not just capture acceptance tests directly from bug reports?
• Take bugs and unexpected behaviours as prompts to talk to the customer.
• Worked on a project for 9 months without a bug tracking system — just used acceptance tests.
• Bugs focussed on ugly thing that system does; acceptance tests much more positive — aimed at user goals.
• New features are easier to prioritise and nicer to work on than fixing bugs.
• Quite often end up with new features in bug tracking system anyway…

XPDay 2007: Fiat Lux: Testing With The Light On - Joan McGalliard, George Joseph & Pushpa Sebastian

Testing team in growing agile project

Teams split according to system functionality rather than business needs

• No one knew if a story was finished or not

30 devs, 10 testers, 7 BAs, integration team

Embedded testers in development team

At beginning of iteration wrote down stories for iteration

• each story had page of details: acceptance criteria

Active documentation:

• tests written in business English
• runnable
• italics for input, bold for output — when run, outputs are coloured red or green
• also had table tests

Documentation is always right since if they fail, the build fails

Tests linked from stories and checked in to source control

The story process:

1. agreeing acceptance criteria
2. dev complete
3. BA/show-and-tell sign off
4. tester sign off

Can colour code iteration plan to see how far each story has got

Technology involved

Originally used FIT — introduced idea of active documentation

But inflexible, developers didn’t like fixtures

Ended up using Concordion

Tests are written using JUnit but described in an instrumented HTML page

When they fail, they give a stack trace as well as the failures on the resulting page

How to introduce

How to catch up on legacy code?

• Forget about it — just test for current stories
• Ended up covering criteria for previous stories too

Having tests ready in time?

• Works best for 2 testers for every 3 developer pairs and 1 customer/BA

Takes quite a while to write the testing framework & tests

• 50% of developer time…?

Faulty fixtures

• Change test data and ensure test fails appropriately
• Reuse fixtures
• Pair testers & developers to write the tests

My thoughts: the fixtures are not visible to the customer, and the words in the active documentation do not actually have any connection to the testing code

XPDay 2007: Working With Customers towards Shared Understanding - Andy Pols & Mike Hill

This was a workshop session in which we brainstormed enablers & disablers, chose the best techniques and then talked about how we would use them and what would be the pros & cons.

Techniques that we chose:

• user stories
• show + tell
• rich domain model
• acceptance testing
• developers using the system

XPDay 2007: Agile Alliance ATDD Tools Workshop Report - Antony Marcano

Side issue

Research in Calgary on touch-sensitive table used for agile planning (Frank Maurer)

• enables card throwing :-)
• create cards using tablet pc with pen-based input, then appears on shared surface to be moved around

Intro

Antony's Blog — things about testing, aggregates other blogs too

Report

Workshop in Portland: discuss cutting-edge advancements in, and envision possibilities for, automated acceptance test driven development tools

• Tools that help communicate & share with customers to figure out what they want
• original name was “functional test tools workshop”

Looking at design process using tests

Had a debate: what’s the difference between an example and a test?

• some took examples and wrapped them, others thought they were different things

Levels of abstraction

• UCD: Goals, Activities, Tasks
• Fit tests work better at activity rather than task level
• Kind of translates to named methods (navigateToJourneyPlanner) vs individual “fill in field with id blah”’

Vocabulary

• Given, when, then
• behaviour driven development — RSpec (ruby) in process of integrating given, when, then
• taking hamcrest & literate tests and making a view that allows customers to interact with the tool
  • e.g. like a word processor
• looked at JDave — didn’t feel as comfortable and natural as JUnit/Hamcrest
• great for flow tests but not so good for:
  • do this and result in this data (row fixture in Fit)
  • truth tables — have some ideas but too immature right now
• Nat Pryce refactored tests to be literate, next step to output Word docs from tests
• Antony would like to enable customer to write tests (but still need conversation)
• Nat saying that customers need to write tests in conversation with developers, so in code is good
• thoughts: given, when, then: moving towards Z & specifications — anybody looked at synergy here?

Visualisation of flow

• Brian Marick blog
  • currently implemented in Ruby, uses Omnigraffle so Mac-only :-)
  • draw a picture and annotate it
  • fear that if pics too detailed, then lots of refactoring needed
• Ward Cunningham - Eclipse portal (not open source but tightly coupled to Eclipse project)
  • workflow involved in someone being nominated to be a committer on Eclipse
  • after the fact reporting on tests
    • can hover over steps and view form & data particular step
    • also have links to take you to that point in the application with data already set up
  • also used for help documentation — legal dept could see steps involved
  • actual tests captured in text-based format
• CubicTest — Eclipse plugin to visually design tests with states
  • generates an interactive HTML prototype, based on the tests you have written
• these tests were captured at task level, but reported at activity level

Model based testing

• Ben Simo — state oriented model
• Manually create state & transition model in Excel, and then generate tests from this model
• agitator — exercises all the paths through the code (uses code as model)
  • more recent tool allows you to generate JUnit tests from suggestions, can then tidy up and rewrite
• idea — generate a model from the first tests
  • can then generate new tests to explore the software against that model
  • helps find gaps in thinking (wouldn’t be used for auto-generating, more to suggest new tests)

Patterns of self testing software

• talk of setting up a wiki to start capturing these ideas

Conclusions

• tools will encourage appropriate level of abstraction
  • avoid refactoring overhead of writing at task level
• will allow multiple views on tests
• tightly integrate into documentation generated from application
• will become more popular to make tests more transparent — available to customers
  • allows customers to provide specific examples
• Frank Maurer has an open source project called FitClipse
• Rick Muggridge: zibrieve.com — refactoring Fit tests
• Green Pepper: using Confluence to write tests (also ties in with Jira)
  • one issue was tying test versions with app versions (may be sorted with Confluence subversion plugin?)

Q&A + Comments

Concordion, decorate an HTML page with tags underneath, and then JUnit runs it

• concordion.org — open-sourced last month

Profit — supposedly allows transformation between Fit & Java for refactoring

Online discussion: aa-ftt@yahoogroups.com

Jim Shaw/Shore has idea of customer unit tests (not end to end)

• forcing the customer to think in modular ways

Good thing for a coach to do — encourage always asking questions

• put on the tester hat and be persistent about asking questions
• tester is a role that is very useful in any team

Functional tests taking a long time

• run as separate continuous integration
• overnight tests did full thing
• during the day, had a different config that simplified stack and took less time

XPDay 2007: Keynote: Cheek-to-Cheek: why Co-Located Collaboration Persists - Yvonne Rogers

Video conferencing vs collocated

• can’t talk privately to others
• what happens after the meeting is almost or more important that during

HP Labs — mututally immersive mobile videopresence…

• Live video of the front and sides of the user’s head
• Mounted on a mobile robotic trolley

Issues

• Situation awareness — aware of what’s going on around you
• Non-verbal communication v. important to control the flow
• Research shows that it’s easier to switch between physical & digital artifacts when face to face

Research over the last few years looking to facilitate face to face communication

eSpace — interactions between (travel) agents & customers

• customer appears to be understanding and nodding, but really isn’t getting anything
• a lot of translation going on from information for agent and information for customer _(hey, that’s kinda what Kizoom does :-)-
• changed the workspace to be a side-by-side interaction with three screens
  • reduced social awkwardness
  • both looked at the screen and occasionally had eye contact
  • both took part in creating the itineraries

Theoretical approaches for supporting collocated teams

Multiple entry points

• when each person has their own paper and pen, it becomes easy for people to share
• when there’s only one pad, people fight over the sole entry point
• also at whiteboards — single entry point is the marker
• used mitsubishi diamondtouch + diamondspin s/w: touch-sensitive display table to provide shared workspace with multiple entry points
  • saw lots of turn taking and “turn inviting”
  • also people who were normally shy could take part more with the physical tasks

Distributed cognition

• traditional approaches to cognition talk about what goes on within a single person’s head
• distributed approach takes the system at large — lots of people with input to the group and output from them
• distrib. cog. tries to chart:
  • where the overlaps in knowledge are
  • levels of access to information
• this is the approach used by Helen Sharp (Yvonne is now working with her at OU)
• Yvonne shows picture of Kizoom’s bug wall and talks about how central it was to our environment
  • (in fact this was probably a breakdown since it just filled up and didn’t get addressed…)
• large interactive surfaces:
  • OU waiting for MS Surface (due in November, but now arriving next summer)
  • reactable — physical interaction with music software

Dynamo — collocated people sharing & showing digital content

• shared screen with multiple mice & other devices
• can carve out sections of the screen and protect them against others
  • can then grant and revoke access to other individual users
• can seal parcels and leave for other users
• deployed into a 6th form classroom
  • interaction tended to be a few people using it and others watching as an audience
• not yet deployed into a software company, but if you want it, let Yvonne know

Conclusion & Q&A

Collocated teams will always work better than distributed teams

• but no quantifiable effects here

What’s the value of these technologies over index cards?

• Helen’s research shows that cards have great value that won’t go away
• if developing a product that requires you to interact with digital content, then this tech gives an advantage
  • especially if making connections
• people overlook emails and other digital content — posting it on a public space makes people take notice (honeypot effect — they all gather round)

What happens with larger groups?

• Yvonne’s research is mostly with groups of 2-3
• When groups get to 6-7 then group segments and division of labour sets in
  • “I’m working on this bit and you can work on that”

XPDay 2007: Mr Agile Goes to Washington: The Impact of Politics on Agile Projects - Panel Discussion

Panel

Sallyann Freudenberg — internal agile coach (permanently employed)

• previously did PhD in collaborative software development
• approach: gently let things bubble up and then deal with them

James Davison — head of PM at Razorfish (previously at ThoughtWorks)

• has come across a lot of politics
• don’t think you can stay out of it — perception is very important
• try get everyone into the same space by socialising

Stuart Blair — investment bank

Mike Feathers — object mentor in US

• travelling coach

Rachel Davies — independent coach

• often working with several companies at one time
• facilitating retrospectives: ensure voices are heard in a neutral way before jumping to solutions

Discussion

The focus of the group seemed to be of within large corporations rather than smaller companies working with other companies.

Politics:

• covert action to get what you want from scarce resources
• decision making process not clear — individual roles not well defined

Good politics:

• Aligning projects with high-ups objectives
• Finding right person to present the case on your behalf
  • Externally, this would be called sales; but internally called politics…
• Try reframing their goals in a more positive way
  • At least lets you work with them
  • When you catch yourself saying bad things about another, it’s time to stop and step back
• Having a strong manager who can recognise political games and call people on it
• We often assume intentions
• Selling the success of the project within the organisation
  • We find it hard to celebrate success

Bringing politics into our practices:

• We don’t really have a lexicon for political behaviour…
  • Need a rudimentary politics for software developers
• Getting to Yes — by Roger Fisher (from Harvard Law School)
  • also others in series (Getting Past No, etc)
• Can we have a patterns book for politics…?
• De-politicising a situation:
  • Listening
  • System thinking — showing how things all fit together

In any group have a tension between wanting to belong to a group and wanting to be an individual

Dealing with customers who play games?

• Build a relationship with them
  • Delivering to 11 countries
  • Turned up in Austria — greeted on front door of building: you’re here to implement a system that means the office will be run from London; go away
  • Had to do a sales job; had to get sponsor on phone to convince him
• Very difficult to build a relationship with someone when hiding something
• Can bank integrity in relationship
• Ask questions of everybody in the company
  • Find different points of view
  • Understand perspective of lots of different people

How do we get recognition within hero-based culture?

• Always have to sell success (even if not being massively successful)
  • what we are delivering is useful, provides value, ready on time
• some clients have culture of celebration when a project is completed
• agile projects release often and regularly
  • need to celebrate that
  • tie in to business successes
• hold an end of year retrospective
  • show off all that has been achieved
  • lots of issues overcome, just not by panicking
• hero culture can cause problems — expose the problems and compare with smooth delivery
• make time to be seen to be doing a good job — and build that in to project planning
  • regular show and tell

What to do when gantt chart and burn down chart start to disagree?

• agile bubble in a non-agile company
• often pressure for report comes from middle management: just query with higher management
• use extra features and benefits of agile methods to sell
• if the agile project is the first to report that it’s running late…?
  • be honest — hard conversation early on (risk of getting fired)
  • speak their language (e.g. use gantt chart)
  • that’s the project manager’s job
  • it’s going to be late or you can have this instead
  • saying “no” in a way that can be accepted

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