Tony and Craig are at YOW! Conference in Brisbane and chat to Jessica Kerr, software developer, consultant and symmathecist (look it up or listen to the podcast) and apart from our first live podcast sneeze they talk about:
Geoff Wilson and Amanda Stockwell from 352 Inc talk about the advantages of Agile in a digital agency, approaches to user experience and the redevelopment of planningpoker.com.
The second keynote was supposed to be Mark “Bomber” Thompson from the Essendon Football Club but he was an unexplained no show. After an impromptu thankyou speech from me and breaking the conference for an early break, James Hird arrived to substitute and did an impromptu talk. As a result of the scheduling changes, I unfortunately did not get to see much of either session.
failed, needed twice as many people after implementation
ran net promoter scores internally, -40!
attempted Agile customer management – planning meetings took 3 hours, attendance dropped, SAP team became prioritisers
NPS dropped to about -35
changed team structure and in-sourced, positive NPS
got agile working – 4 week sprint, 40 minunte presentation, stakeholders turn up because if you are not there you don’t get prioritised
developed a prioritisation matrix – business value versus effort, colour coded cards for skillset, sets order for prioritisation
pre work is required for the meeting – know how many points of effort for every available person
prioritisation board – built the backlog as part of the session
no spreadsheets!
The Trouble With Time Machine
I was MC for this session delivered by Matthew Hodgson from Zen Ex Machina. He gets extra marks for working Doctor Who and bow tie references into the talk. His slides are available here.
time machine pattern – work an iteration or more ahead of the development team
UX is primarily about design, we are in two different worlds
embed the time machine pattern within Scrum
personas – focus on the pragmatic face of our users (David Hussman) – synthesise what we understand at the moment
added to GWT… Given I am a role AND I VALUE, When… Then…
grooming is the forgotten ceremony
involved the users in planning poker – got clear perspective in the context of their environment]
demo became a cognitive walk through
Emerging Paradigms in Software Testing
I was MC for this session for Kristan Vingrys from ThoughtWorks. I have known Kristan for a number of years, and I resonate very closely with his views on testing and testers. His slides are available here.
ATDD is a good way to break down the barriers between developers and testers
need to change focus to preventing defects rather than finding defects – measure yourself that more defects is bad
fast feedback – embrace continuous integration, automation and the test pyramid
involve everyone – crowd source your problems, tests are an asset, version control your test cases
change focus from how I prevent this going into production onto how I get this into production
build pipeline- stage build to run different tests in different stages in the pipeline
tester needs to inform the team of quality, not be responsible for quality
target testing to things that are changing, not just scatter gun
it’s about the principles, not the practices
test code is code – treat it like any other code
it’s important to know what you are not covering, more than what we are covering (Model Based Testing)
Design Eye For A Dev Guy
I was MC for this session delivered by Julian Boot from Majitek. This was one of the highlight sessions that I attended at the conference and as I remarked when thanking Julian, it reaffirmed how much I don’t know about good design. His slides are available here.
you gotta love it, you gotta be able to do it and it needs to deliver a bag load of cash
people now expect a fit and finish, design is now expected
people over process, not everyone is a good designer so let people play to their strengths as weaknesses get in the way of excellence – need to understand it though
design is related to visual processing – what we see is what we design, design can be taught
highlight individual items – contrast, colour, shape, white space, underlining
focus on data over labels – make the data bigger, keep your headings close to your data so you don’t get lost
hierarchy of actions, but use them properly
colour – use a designer, but if not use 3 colours in one shade and two others (using three grey is the best pro tip and two others)
let design be your brand, don’t overuse the brand
Agile Executive: The Naked Truth!
I was MC for this session led by Kelly Waters from ThoughtWorks and author of the All About Agile blog. I unfortunately did not get to see much of this presentation, the slides for which are available here.
I was MC for this session delivered by Tony Young from Integrated Research. This session was designated as “Expert” but there is nothing in this that I could see that made it that level. His slides are available here.
teams find it hard to focus at 7-8 people and they saw parallel development, sweet spot was 5+/- 1
changed because competitors moving faster and customers questioned our quality
used agile guidelines, not rules – had must dos and bendys
product team deliver using Scrum and give to a QA team that uses Kanban !
the peer pressure to try is key
use Lego board for backlog to see resource impacts
Other Stuff
One of my colleagues who presented a talk on day 2 was Colin McCririck (who is the Executive Manager of a team I coached for some time) and he spoke on Leadership Secrets for Agile Adoption).
As a precursor to the Agile Australia 2012 conference to be held in Melbourne, a product afternoon was held at the Hilton on the Park in Melbourne in November and had a good variety of Australian speakers. The success of the event means a similar event is being schedule for Sydney in February 2012. Here are my notes from the event:
Look What Happened When We Let Customers into the Product Development Loop at Lonely Planet!
need to avoid the next bench design problem – only ask the person on the next bench about quality, do not go to the wider world
for Lonely Planet, realisation was a competitor in the market who produced a colour guide, no sales the month they launched
went to customers 4 times in the process, took publishing from 2 years to 9 months, visualise the project
Rob Adams talks about getting the developers to do some of the initial marketing calls
Marketing is from Venus, IT is from Mars – and the Customer Doesn’t Care
Daniel Oertli from REA Group led this discussion that he hastily renamed to “5 Kick Ass Principles for Customer-led Development”, his slides are available here.
effect of marketing has changed over the last 5-10 years, we no longer control the marketing channel, need customer admiration
be a peeping Tom. Regularly – there is only one customer, the people who pay for products, none of this internal customer bull####, hard to put your business on the road regularly to talk to customers
5 on Friday – Silverback on Mac, 5 internal employees for 15 minutes and ask them to do specific tasks with your product (eg. show me how to change the default colour scheme), continue to do this every Friday as parts of the product are developed
don’t ask for the solution – to get creative you need to figure it out internally, great people create great things
day and half every quarter – hack day – off tools, schedule around it, put ideas on intranet and vote, teams form around the idea self-forming, winning team gets a cash prize and gets sponsored product into production
2 week inception process – use business canvas mapping to lay out the business drivers
democratize design – hard to get excited about something if you have not been part of the design, get everybody to draw
ready, fire, aim – Agile gives us opportunity to change things in motion but most organisations still execute iteratively what is planned up front, Agile gives you a bullet frequently, be very clear about your minimal marketable features, be ruthless about what you send to your Agile teams, you have a lot of go’s at this
teams win – good people outperform any processes, keep teams very small (6-8 people), have a mix of business fundamental understanding, lead designer and lead technologist and there for skills not core decision making, trust is essential
dealing with resistance – hardest change of all was getting business on the journey, need to get culture sorted and get teams focussed
more of what people do is outside of their hierarchy, biggest impact is dynamic thinking by thinking of type of things we will do rather than what we will do
public companies need a plan to show to shareholders, challenge is to make it more dynamic after that
engage people in their career progression – still report to a lead, but 90% of the time they live with their cross functional team – more about stretching their knowledge in their domain so have practice meetings
SEEK’s Approach to Product Innovation
Doug Blue from SEEK presented this session, his slides are available here.
put customers before profits – no display advertising on the front pages, founder would prefer to have a dollar tomorrow rather than a dollar today
build for the long term – customer core needs, competitive advantage, long term trends and shareholder value, in GFC let customers negotiate out of long term contracts
strive for a rock solid core and out innovate the competition – focussed on number of ads and size of audience, now need to focus on the product
focus – do a few things very well, carried this over to the iPhone app as well, but run business on the things that are do-able
people engagement – never compromise on engagement
data driven decisions – if we build or change something, we measure it
test and learn – put it out in market and do course correction
balancing customer needs – 3 different customers with different needs (job seeker, employer, recruiters) – came up with an invisible salary to balance the needs
on bigger initiatives, need to do your homework
A Start-up Approach to Product Delivery in a Corporate Environment
XP Explained lacked an explanation on how to communicate effectively with customers to understand what they wanted to achieve
base costs on optimum team sizes that can manage constant delivery of a number of system concerns
have no process, when problems occur, take those problems away
don’t use iterations, they constrain the customer, need to be able pick up any card and get it into Production
ideas wall – backlog for where the business is going, anyone can post ideas on it
don’t talk about what the product we are delivering should do, talk about what the business should do
challenge everything – stand ups are almost useless in large organisations – only say things what people in the circle need to know about, because they work together, so they should know
most people in large organisations are disempowered – how do I know I am doing the right thing? Just do it, everyone is the business
need to help everyone understand the market – understand what the impact of features are
whole of company showcases every Friday
need multi disciplined teams that understand the market they are striving for
Panel: Why is Customer-led Product Development so Hard?
Keith Dodds from ThoughtWorks led this panel with all of the above speakers. Some of the key learnings were:
if you have leaders that are customer focussed, everything else will follow
most organisations try to make the workforce effective and efficient by putting structures around them, need to retain a functionalised structure and stay away from specialisation
companies are introverted because traditionally they have not had access to customers
it’s hard to keep up with all of the tools out there – there is lots technology to seek out what the customers are viewing
most products are designed to be obsolete within 1-2 years, especially those that are consumer focussed
companies are not set up to evolve things, they are setup to build, the world has changed where everything is outdated the minute you deploy
grass roots movements are usually the most enduring
most companies lack the balls to shut things down when they need to
frugal innovation – constraints help you channel great ideas, would be interesting to apply some artificial constraints to hack days
what doesn’t work are artificial constraints and the team know it
next C level job will be the chief designer – targeting the customer
Agile helps to get a customer led product out, because the person who wants the product can talk to the person who builds the product
report on value delivered to the business rather than velocity
the pool of talent is not that big, how do you keep people motivated – sense of purpose, sense of meaning (problems that have currency in the real world), ability to react and shape, ability to be heard, about making a difference
where do great Product Managers come from, how do we develop and train these people
Agile Australia 2011 was held for its third year last week at the Hilton in Sydney. Once again I was honoured to be offered an opportunity to present, be an MC for speaker sessions on both days, moderate a panel discussion and run the end of conference retrospective. The conference attracted 675 attendees and the buzz over the two days indicated to me that the conference was a huge success.
For the second year, it was a great pleasure to be one of the conference advisors. As the conference was brought forward to June, there was only six months to prepare between conferences and lots of suggestions and improvements to implement from previous years. A lot of review, debate and discussion went into putting the program together and ensuing there was a good mix of speakers, variety of topics and sessions for different levels of expertise. More effort was also put into shepherding speakers. A huge thank you needs to go to Rachel Slattery and Zhien-U Teoh from Slattery IT for their commitment to the conference as well as my fellow conference advisors Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Nigel Dalton.
The following are my notes from the sessions I attended on the first day.
Keynote: On Beyond Agile – The New Face of Software Engineering
cooperative game – invention, communication and decision making
projects are in a position, look for strategies to move our position, no fixed formula for winning the game (competitors and the economy are some of the enemies), only three moves to invent, communicate and decide
communication – whiteboard discussion provides stickiness over time (can just point back to conversation) as well as proximity
need about 3 minutes of video to enhance the distributed conversation, becomes archived documentation to remember user point of view or architect design decisions
craft – a lot has changed, software development changes every 5-10 years and you need to keep up
people learn skills in 3 stages – shu, ha and ri
work in progress is decisions that have been made but have not been shipped and delivered
like lean we we want multiple deliveries per day – continuous integration has evolved to continuous delivery
in decision making, look for the bottlenecks, the person with the full inbox is the person limiting the work in progress of the whole organisation
knowledge acquisition – real moment of learning often happens at the end when the surprise factor occurs when we deliver work, suggest that at the beginning of a project deliver a knowledge curve ahead of the cost curve (a number of small experiments)
agile says deliver highest level of business value first but projects tend to always deal with the risks first – learn about your business risk (should we build it), social risk (do we have the right people), technical risk (API’s, performance, architecture), cost/schedule risk (gain knowledge about the solidity of the estimates) – you need to decide whether to deliver business values or knock off some of these risks
need to identify the tail to determine whether we deliver business value early or add more features later (Apple are good at this, for example shipping an iPad without 3G initially)
self awareness – the team is self aware when the team can talk about the team and where they are
Keynote – Is Business Ready for Agile
Rob Thomsett delivered this keynote, his slides are available here. He advised that he was going to run his talk in two sprints and check the heart beat halfway
agile is a church of all people – the newbies through to the true believers and a few drooling old people
agile is not new – been going for 40 years
is business ready for agile? – yes and no – every company in the world is ready for agile, they just don’t know it – how do we develop agile into a broader organisational paradigm
we work on a set of models that were developed when the world was relatively stable
the average window of stability for an organisation is about 3 months, change is normal and everything changes
100% of C-level executives believe that project management is too bureaucratic, projects take too long, business cases are poorly developed, transparency is adequate, they expect to be ambushed, steering committees are a waste of time, reports are not accurate
software is not engineering, wrong paradigm, it is a craft
the closest to what we do is not making buildings but making movies
summary: we took the wrong model, flogged it to death so let’s throw it out
agile is a cultural and disruptive journey – first question to ask is are you up for the cultural challenge, for every company that says no there is one that says yes
business approach needs to pass the simple and transparent test – most powerful test to clean up broken processes
go back to work and annoy people by asking people if we can make it simpler
cultural values are openness, honesty, courage, trust and money
the people at the top are the easiest folks to get on board with agile
most people link budgeting to estimating – agile demands we move money around more quickly
sponsors must get dirty – they must be part of the process because they own it
PMO should exist for resourcing, not reporting
Panel – The Changing Role of the CIO
Beverley Head moderated this panel with Jeff Smith from Suncorp, Steve Coles from Allianz, Daniel Oertli from REA Group and John Sullivan from Jetstar.
key is to turn decision making over to employees and leaders need to become coaches and create a great environment
The Corner Office by Adam Bryant gives advice for success – passionate curiosity, battle hardened confidence, team smarts, simplicity, fearlessness
role is to understand where the company is going and deliver things for them to succeed
relax the old techniques like governance that gave a veneer of confidence
need to understand and remove the barriers by becoming an active listener
fundamentals like attract and retain the best have not changed
learn the business in which you operate and realise the definition of leadership has changed (don’t be afraid to higher smarter people than you)
need clarity of purpose, avoid constraint of thought and don’t filter based on your experience
resistance at the frozen layer – middle managers are typically the blockers so need to change the communication structure (for example, using Yammer for communication to give everyone an equal voice)
distributed teams always need a local decision point like an iteration manager
leaders need to eliminate information handlers
offshoring value proposition – you need to decide if your assets are a strategic advantage, do not offshore things that are volatile or if the project is too big to handle yourself (which essentially means you can’t explain it to someone else), offshoring is good because it keeps us on our toes to be competitive and continuously improve
need to look at outsourcing from a productivity point of view and not just a cost point of view (we are not buying pencils)
life long learning for developers – people have to follow their own course, inject talent and different thinking, look back each year and think about what you added to your bag of tricks
most people are capable of learning new skills, that’s the beauty of human beings
what does quality mean – quality is something that is fit for purpose and testable and maintainable, quality is everything
pushing agile into the business – need to agree on one way of working, once you are successful people want to jump on the bandwagon
Agile Architecture & Design
I had the privilege to introduce Neal Ford for this presentation, and his slides are available here. As I had seen many parts of this presentation previously, I did not take many notes as they can be found across other posts on this blog.
don’t pay for technical debt that you may never justify
Key Metrics for an Agile Organisation
It was my pleasure to introduce Craig Langenfeld from Rally Software to deliver this presentation (originally scheduled to be presented by Mark Ortega). The slides are available here.
cumulative flow – look at the top of the line to see what is the scope and how has it changed (total features), then ask if the team limits their work in progress by looking at the time between the boundary of in progress swim lanes, finally look at the lead times and how long it will take to deliver a feature
work in progress limits allow the team to move through work more effectively
lead and cycle time report – allows you to see where your bottlenecks are
stop focussing on the workers and focus on the work product – so rather than lines of code look at the the value delivered
productivity – understand your teams velocity, throughout mapping stories that were completed and carried over
earned value – useful to measure how much value we are delivering (the difference in agile is we are actually delivering the value)
predictability – answering the question of when we will be done – throughput chart can show you if a team is getting more predictable over time, burn up is used to show predictability of meeting scope, release burndown to show meeting a date and demonstrate additional scope being added
use cumulative flow to track the cone of uncertainty
quality – defect trends and counts, most code altered, number of changes, etc…
net promoter score for tracking customer satisfaction and if it is increasing
get customers to vote on what aspects of the product they like and don’t like
for cloud computing track the features that are actually used
Leading by Serving
Simon Bristow delivered this presentation, his slides are available here.
bridge the gap – gaps when making a decision which is the unknowns, bridges the gap to the future by seeing the unseeable
one action at a time
forcing a decision on someone will engender resistance, some you must persuade – need to listen to connect at the grass roots level
withdraw and acceptance – step back from the team to allow them to look after themselves and accept that the team know best as they are the subject matter experts and will get the job done
facilitate community – need to build
lead using art not science – if you turn to science in agile you will turn to process
Soldering Irons, Consumer Devices and Hardware Manufacturing in the world of Agile Software
Dean Netherton and Neil Brydon for DiUS delivered this talk which was one of the highlights of the conference for me. The slides are available here.
DiUS working on a fire danger smart meter and technology for charging electric cars
how do you demonstrate value when haven’t built the device?
had to work around the vendor for the smart meter because they had a traditional process for building the device – aligned project plans around hardware drops and had to simulate the hardware in many cases
used wireframes to drive design but had to spend longer on design to ensure it was right – for example, can’t add a bigger battery later
first drop was an off the shelf component board to kick start the software
second drop was a bare board that was the basic board without the LCD
third drop was the plastics without the screen as the component had not arrived so replaced with paper
challenge on how to articulate stories – had to break stories own technically
used Cucumber to test as there was an embedded USB port on the board – helped embedded engineers assist the Ruby engineers understand how the device worked
did continuous integration by plugging a device into the build server, had an issue about flashing the device when the code changes
hardware engineers slightly change the design with each revision which had affects on software design as well as having hardware for continuous integration
built own hardware prototypes and used local suppliers to cut down lead times (China cheaper but added 6-7 weeks to the lead time)
used mocking to show users the idea ahead of hardware being available
planned for multiple hardware revisions to allow for late decisions
these days you can send a 3D model to a design house and they can pop out a prototype, design exercise ensures that screws line up, etc
no excuses for automated testing, in the past it was not embraced in hardware, can test the integration layer without the need for hardware
no benefit in running tests for the hardware design as you only get a handful of drops
use automated test to ensure buttons and light work, good when you get new hardware and good for checking faults on the production line
had to learn about the hardware stack early on which challenged whether value was being added
firmware development not integrated onto the story wall
technical tasks are OK but really understand what done is
luckily the stakeholders were quite technical
Putting It All Together – Agile Transformation and Development Tooling
Philip Chan from IBM delivered this presentation, his slides are available here. I failed to see a lot of agile in this talk personally.
established teams – communication difficult across timezones but tools make it easy, different tools used in different teams,
IBM agile process – 2 week iterations, 2 day inter sprint break every 4 weeks, develop for first 6 days followed by 2.5 days for bug fixing, do acceptance testing for first 6 days and 2.5 days of exploratory testing, showcase on day 9
test management very waterfall for audit purposes
using automated tests and continuous integration to assist global team optimise processes
continuous integration – everyone in the team integrates with the mainline at least once a day
continuous delivery is taking the same approach as continuous integration and apply it to the last mile – decision to deploy should be business only with no technical barriers
continuous deployment is continually delivering on a regular basis – continuous delivery enables this if you want it
rare to find a company that is pulling in the same direction, so you need to automate in pockets and add manual checkpoints and then you can look for ways to automate them
risks – need to bring pain forward, which was the tenet of XP, not doing it is much more risky, there is pain and effort to setup, you need to look for a leverage point in your production systems to justify
if you do something rarely you don’t get practice, by doing it more often you improve which actually results in a process that is more auditable and gives you more confidence
is a good approach to shorten feedback loops, also allows you to give confidence to the business on delivery timelines
packaged software makes continuous delivery hard, important to look at the automation of the configuration as well as automated tests, looking for fast feedback to give confidence in delivery
need to push software vendors to make things more deliverable (this was a rant by Martin Fowler, that I tend to agree with)
make database changes with the same fundamentals – break them down into small changes and combine schema changes with the data migration and string them together into a package, tools have got more specific like dbdeploy and Liquibase support this and Ruby on Rails just supports this out of the box
DBA’s are the final frontier because they like to fiddle with scripts, need to bring them in or deal with smaller changes
testers tied to manual processing – need to separate the low and high value testing work, fear that they will be replaced by a small shell script, will make their job vastly easier, need to get buy in by demonstration
difficulty is always the human element – testers are moved from the backend to the front end of the process, specification by example at the front now, need to look at incentives and make them common between developers and testers
key is a business decision of when to delay so you can deal with business change, training, etc…
people are now used to the fact that websites or apps on their phones are continuously changing
gives the option to deploy to different types of users when they need it
Go was built with continuous delivery in mind, version control systems are critical because everything needs to be in there, automated testing tools are also critical, continuous integration servers can help if they have an extra build pipelines
Puppet and Chef both allow you to script your environments
need to place people in teams who believe things are possible
Other Stuff
At the end of a very long day, it was good to network with attendees at the ThoughtWorks open office.
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.
Tony and Craig are at YOW! Conference in Brisbane and chat to Jessica Kerr, software developer, consultant and symmathecist (look it up or listen to the podcast) and apart from our first live podcast sneeze they talk about:
Craig Smith 
You must be logged in to post a comment.