The last main day of talks at Agile 2009, and once again lost the morning to preparation and presenting a talk with Paul King.

Here is an overview of the sessions I got to:

Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level

The session I presented with Paul King, we got close to a full house and the session feedback forms were overwhelmingly positive. The slides are available in a separate post.

The Kanban Game

A full house to this session run by Tsutomu Yasui gives some validation to the fact that Kanban is gaining traction with the agile community. All the details and materials for the game are available at http://www.yattom.jp/trac/public/wiki/ProjectGames/TheKanbanGameEn. I only sat in on the first half of the session so I could fit in some other last minute talks.

Agile User Experience Design Emergent Practices

I had an aim to get to at least one talk by Jeff Patton (especially for bragging rights for one of my work colleagues, Teale Shapcott)! I actually got to have a brief conversation with Jeff later in the evening which was awesome.

• adapting to agile difficult for UX practitioners – Jeff Patton came late to usability but early to agile usability
• five stages to agile adoption (salesforce.com) anger, denial ,bargaining, depression, acceptance

Homonyms

• design – agile (how to build product), designer (what to build based on user needs)
• iteration – agile (short time box to build software), usability (builf representation of product idea for evaluation and change)
• story – agile (short description of what user might want built), usability (agile design for goal)
• customer – agile (someone who writes a user story), usability (a person who buys a product)
• small bit of software – agile (developer can build in a few days), usability (something a user can complete is a single sitting)
• test – agile (means complete and meets acceptance criteria), usability (user can use the software and it meets their needs)

Then:

• usability practitioners view of design and development – understand business need, understand user need, personas, create and validate high level design, create and validate UI design, create and communicate design specification, develop software, usability test finished product
• you could do all that for a sprint right? – agile changes usability practice but does not have to threaten it
• patterns have emerged as usability practitioners have adapted – had to go postal or figure it out – great idea is not a pattern, great idea that multiple people use is a pattern (at least 3 companies)

The emerging best practices are:

1. usability designers are part of product owner or customer team – in drivers seat, part of the planning, part of product owner team or the product owner. Product owners already take multiple roles, product owners are thinking about this release and the next release
2. research, model, design up front (but only just enough) – learnt how to cut up work, high level design but just enough, task model (but agile people think they are stories), usability people need to be connected to backlog, own and leverage it
3. chunk your design work – break up design work to perform incrementally throughout development, organise story into a map that helps communicate structure of the system (see The new user story backlog is a map on Jeff’s blog), organise the backlog (don’t just prioritise – communicate with user about what we are seeing)
4. parallel track development to work ahead and follow behind (see Lynn Miller – Case Study of Customer Input for a Successful Product on agileproductdesign.com) – time machine essential for product owner and usability team, design and coded features pass back and forth between tracks (design ahead, look at stuff already built and stuff that is being built now)
5. buy design time with complex engineering stories – product owners responsible for scheduling, sometimes highest value is to put a story that is easy to design but hard for developers to build to buy time! (Lynn Miller talks about SketchUp File – Save As as easy to design but took ages for developers to develop)
6. cultivate pool of users for continuous user validation – (see Heather Williams – The UCD Perscpective on agileproductdesign.com), Salesforce have a person that coordinates this, keep feedback fresh by rotating every few months
7. schedule continuous user research in a separate track from development – Kitchen Stories a silly Swedish movie has usability connotations, research is continuous, not just a phase, schedule visits with users ahead of how we know why we want to be there
8. leverage time with users for multiple activities – do some usser interviewing, do prototyping, show and review current software (one mand band), use RITE to iterative UI (rapid iterative testing and evaluation) (see numerous RITE articles on agileproductdesign.com), use time before sprint to refine design, test something and fix it to burn down failures
9. prototype in low fidelity – prototype in public so people can see what you are doing, look at Balsamiq as a tool
10. treat prototype as a specification – have a discussion
11. designer developers iterate design outside development iteration  (eg. CSS, HTML and visual design), “art is never finished, only abandoned”  (Da Vinci)
12. become a design facilitator – designers do collaboration and facilitation, practices like design studio and sketchboard technique to get developers involved, sick of developers armchairing their design (get them to sketch it out, developers get to weigh in good ideas, developers get their design ripped apart, usability people get people to read their designs)

Finally, most usability designers won’t go back after doing agile!

Agile By The Numbers: What People Are Really Doing In Practice

I was keen to go and see Scott Amber speak, you can view the session or view the data. According to Scott, this is what people are doing in practice and this talk is exploring some myths.

Majority of organisations doing agile?

• Agile Adoption Survey 2008, 69% yes (biased survey)
• State of the IT Union Survey – 76% yes (not as biased because not related to title of the survey)
• just because majority doing agile, not everybody needs to do agile
• CONFIRMED

Majority of teams doing agile?

• in 76% of organisations, 44% of project teams doing agile
• BUSTED
• numbers claiming to be doing agile, can’t test this theory, expect number is high
• how do you measure agile?

Pretty much all development in agile?

• agile practices that most effective – CI (65%), daily standup (47%), TDD, (47%) iteration plan, refactoring, retrospectives, pair programming, stakeholder participation, shippable software, bundown tracking
• practices that want to adapt – almpot all technical – acceptance and developer TDD at top of list
• PLAUSIBLE

Agile is just for small teams?

• 1-5 and 6-10 success, starts to taper off for teams 11 and up, but success at all sizes of teams
• BUSTED

Does not apply to regulatory situations?

• 33% need to apply to legislation
• BUSTED

Agile and CMMI don’t work together?

• yes 9%, only small amount of people doing it
• no statistical differenece between CMMI and non-CMMI agile projects
• BUSTED

Agile process empirical?

• teams collect and act on metrics, 51% collect but do it manually (according to Scott Ambler, don’t trust manual metrics as they are behind and altered to tell a better story and meet bureaucracy), 26% no and 19% majority automated
• CONFIRMED

Agile teams doing greenfield development?

• 78% working with legacy in some way, 57% evolving legacy code
• BUSTED
• need to start sharing the real work because Michael Feather’s book Working Effectively with Legacy Code and Scott Ambler’s book on Refactoring Databases about the only books out there

Becoming a Certified Scrum Master is a good idea (2 days)?

• 78% think certification is meaningless
• nobody respects this, shame on certification trainers, better way to earn a living, step up, 2 days on a business card is not a good idea, preach less and act more
• BUSTED
• Ambler certified for a good laugh

Most agile teams are co-located?

• 42% co-located – good thing, reduces risks, 17% same building, 13% driving distance, 29% very distant
• a third of teams have geographic sistribution issues
• BUSTED, majority of teams distributed in some way

Agile teams don’t provide up front estimates?

• majority of teams do up front estimates
• need estimate to tell senior management to get project off the ground
• 36% reasonable guess by experienced person
• BUSTED

Agile teams just start coding

• on average takes almost 4 weeks to warm up – modeling, set up environment, design, …
• BUSTED

Agile follows common development guidelines?

• practice in XP
• 49% project / enterprise conventions (19% enterprise level conventions)
• 22% UI convention, 25% data conventions, expect lower than development because not as cool as code
• PLAUSIBLE (but borderlne) – room for improvement

Rights and responsibilites are part of agile culture?

• 58% defined for development team vs 35% for stakeholders
• PLAUSIBLE

Agile test often and test early?

• developer TDD 71%, 52% still doing reviews / inspections, 45% end of lifecycle testing, acceptance TDD 40%, one third of teams have independent team who look at system independently
• CONFIRMED – doing testing throughout lifecycle

Agile don’t do up front requirements modelling?

• 76% do this, need to come up with stack of cards now
• 52% capture in word processor, 45% capture as tests
• BUSTED

Agile don’t do upfront architecture?

• 70% high level architecture modeling
• metaphor is a total waste of time
• organising a conference is just like organising a conference…
• BUSTED

Agile write interim documentation?

• 56% yes
• CONFIRMED

Agile produce supporting documentation?

• 70% write these, minimal amount of stuff that need to be developed
• CONFIRMED
• sometimes when compared, agile write more

Agile works better than traditional?

• hell yes!
• all approaches reasonably close 65% vs 80%
• quality much better
• functionality delivered higher
• make money – good, but hacking better off
• time much better
• so similar, but better way to spend money wisely
• CONFIRMED

Finally:

• difference between what we say and what we do
• just because some people succeed, doesn’t mean you will
• visit ambysoft.com if designing a survey – there are too many crap surveys!

Open Space – Scrum Is Evil…

Jeff Frederick ran his Scrum Is Evil session that I had first seen at CITCON in Brisbane earlier in the year. It was interesting to see that the outcomes were exactly the same half way around the world!

Conference Banquet & Keynote User Interface Engineering

It’s very hard to take notes in a banquet with the lights dimmed, but Jared M. Spool gave a very entertaining keynote on User Interface Engineering, including some iPod vs Zune bashing and an old Apple video on future design.

Here is another post I found from this session: http://www.agilitrix.com/2009/09/user-interface-engineering-agile-2009-banquet/

The night was finished off with a Chicago Blues band and some conversation late into the night at the hotel bar!