And so much time was spent on referring to this book or that book that we just had to link what books we unwittingly covered in what we like to call Tony’s Oprah Winfrey Bookclub!
Chasing the Rabbit or now known as The High Velocity Edge by Steven Spears; recommended by Tony as a great Lean book.
Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larson; there might be a reason why this wasn’t discussed, but Renee did read it recently; it was okay but potentially an overrated book.
Quotes:
“Some tribes are stuck. They embrace the status quo and…
Chaos, Chaordism and Agile: When have you slipped away from Agile and moved into chaos? What is Chaordism? When is chaos acceptable? How do you move out of chaos?
Quotes:
“I don’t program software anymore, I program people”
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)
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
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
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)
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)
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)
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
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
prototype in low fidelity – prototype in public so people can see what you are doing, look at Balsamiq as a tool
treat prototype as a specification – have a discussion
designer developers iterate design outside development iteration (eg. CSS, HTML and visual design), “art is never finished, only abandoned” (Da Vinci)
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.
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
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, …
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
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.
for teams that are already doing continuous intgration, it gives you a target to obtain
is obnoxious after insane (where to for teams that are already at the top level)?
tooling makes continuous integration trivial now (when Cruise Control was released many people thought it crazy that you might build on every release, not its a given)
the model was developed because people assume what is possible is based around their personal experiences
the model shows the industry norms and targets, and if your team is not at these levels you are behind the curve
The discussion branched out around the following ideas:
scrum does not prescribe continuous integration, but continuous integration is a good development technique
that it should be acknowledged that there is a difference between project builds and full product builds (which can take days)
I raised the idea that perhaps there should be an element around team principles, and that things like performance (and more importantly, the team realisation that performance should be monitored and improved) should be an indicator to maturity (there was much debate about this!)
a number of industries potentially have their continuous integration processes audited, such as defence, gaming and financial organisations that have Sarbanes-Oxley requirements
it was acknowledged that most large organisations have teams at different levels on the maturity scale (this is certainly my experience)
dynamic languages and don’t really build or deploy. This then raised discussion that dynamic languages are not compiling as opposed to not building, and that in many cases one man consultants can manage their deployment process in a much more lightweight manner
parallel to CMMI, is there a payoff to getting to insane?
maturity is often determined when we move from dropping code to testers versus testing the development build (where testers are writing the code while the code is being developed)
where is the line that determines that the build is complete? It should be the entire team, not just the developers or the QA team
the QA team is traditionally where much of the auditing happens, therefore many testers are reluctant to change as they have built up processes to deal with audits over a number of years
For the record, the cutting-edge agile teams I have worked with over the last few years were at the following levels:
Building (Intermediate)
Deploying (Intermediate)
Testing (Insane)
Reporting (Intermediate)
We still have work to do!
Virtualisation & CI
I used the “law of two feet” during this session, but was interested to hear that many people are using virtualisation very effectively in their test labs, and that it makes getting environments and data ready for testing much easier.
Long Build Times
The discussion was well-established by the time I got to this session, but some of the key points for me from the discussion were:
question as to when static analysis checks should be run in the build – the consensus that running them first means you get the quickest feedback
longer builds should be run nightly so as not to hold up developers
prioritising build queues or using different machines sounds like a good idea, but nobody is doing it
you can reuse functional tests for performance tests, but targeting specific tests seems to work better
Atlassian use JMeter for performance tests and have a variety of Maven and Ant builds, but use Maven for managing repositories
Ant is still well regarded, Idea support is awesome, many people do not understand the power of custom ant tasks or the ant idoms
the build should be regarded as part of your code
discussion about using a Java build tool, such as Hammer and why we can’t articulate why it seems wrong
not enough people understand Maven, usually there is “one guy” on the team
Jeff Frederick led a discussion that he is led at previous CITCON’s around the world
The team first debated why Scrum is Evil. During this discussion I really thought the whole agile movement was done for. Jeff asked the group to finish the sentence Scrum Is Evil because…:
it becomes an excuse
that’s not Scrum
tested as a silver bullet
hides poor personal estimation
master as dictator, project manager
two days to agile master certification
daily standup equals agile
agile by the numbers
is dessert first
you lose the baby with the bathwater
Scrum teams don’y play well with others including customers
it has certification
is the new RUP
Jeff then proposed a way to think about Scrum adoption as outlined in Geoffrey Moore’s “Crossing The Chasm”. The early adopters had success while the early majority are putting their faith in training everybody as Certified Scrum Masters (a problem that appears to be a far greater issue in Europe than Australia).
Then, just as though all hope had gone, Jeff asked the group to finish the sentence Scrum is Good beacuse…:
people can get it
an easy introduction
a good starting point
it is better than a cowboy shop
people can actually follow it
improves visibility
blockers are highlighted
testers can start work early
provides a forum for communication
can engage customers in a much richer way
states there should be a facilitator
results focussed
makes everybody responsible for end result
better communication from end result
The key outcome by the group was “Scrum is not evil… people are evil”
This was a great way of trying to tease out the issues and advantages to using an agile process and one that we may be able to use in the enterprise with teams who have been on training but appear to be resistant to change.
Seeding Test Data
A good discussion about ways to seed test data
Erik Petersen introduced the group to GenerateData.com, a free site that generates real adddresses and data based on factors a random amount of times that you can then inject into SQL – the site looks awesome!
others in the group mentioned LiquiBase that can be used to version the database, is designed for database management but can be used to seed data
WebObjects by Apple is a lot better than it used to be
Extending CI Past Traditional Dev & Release Process
I led this discussion, and whilst it focussed mainly on different usages that I have been involved with (with assistance from Paul O’Keeffe and Paul King), we also had a good discussion about Tableaux and the build process at Atlassian.
Conclusions
A great open conference attended by people passionate enough to give up their Saturday to talk about continuous integration and testing.
My presentation with Paul King from Agile 2008 called “Agile Project Experiences: The Story of Three Little Pigs” is available on Slideshare.
Over the last few years, we have aggressively applied agile practices on a number of projects with success. These successes, however, have not been achieved without challenges and lessons learnt along the way. This experience report specifically highlights examples from three different projects of varying sizes in this period in the same organisation (three little pigs) where in all cases the pigs were well and truly committed.
Some of the key successes from the example projects will also be discussed.
The corresponding paper is available via the IEEE and is also available in full via the Agile Academy.
Breaking out from our normal format Craig, Tony and Renee talk about the recent flurry of tweets from the Scrum and Kanban communities.
You must be logged in to post a comment.