Conferences

Agile Australia 2011 Day 1 Review

/ Craig Smith / Leave a comment

Agile Australia 2011Agile 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

Alistair Cockburn delivered this keynote, the slides are available here.

From Agile Australia 2011
  • agile software development is for wimps
  • 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

From Agile Australia 2011
  • 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
  • old business techniques have reached their use by date (Gary Hamel – Management 2.0)
  • 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
  • in 1968/69 NATO held a conference to address a perceived crisis in software engineering – sound familiar?
  • 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.

From Agile Australia 2011
  • 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.

From Agile Australia 2011
  • in the software world we deal with known unknowns
  • spikes are your friends, purely informational gathering
  • ckjm – tool for reporting complexity and coupling
  • 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.

From Agile Australia 2011
  • 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.

From Agile Australia 2011
  • a perfect team is one that can do anything, in control, do anything thrown at them
  • lots of teams act in an agile manner, the leader makes the difference
  • Robert Greenleaf – The Servant As Leader – others highest priority needs are being served first
  • 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.

From Agile Australia 2011
  • 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

Panel – Continuous Delivery

Evan Bottcher, Neal Ford and Martin Fowler from ThoughtWorks were on this panel.

From Agile Australia 2011
  • 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.

Also, I have to send congratulations to my colleague Adrian Smith from Ennova on his talk Agile for Startups which I hear was very well received (I have attended previous incarnations of this talk).

Agile Australia 2011 Pre-Conference Workshops Review

/ Craig Smith / Leave a comment

Agile Australia 2011Ahead of the Agile Australia 2011 conference this year in Sydney, I was lucky enough to both present and sit in on the pre-conference workshops.

From Agile Australia 2011

First Steps in Agile

On behalf of the Agile Academy, Tony Ponton and I presented First Steps in Agile to a small but enthusiastic class. The course covers introductory material around the values, principles, practices and agile approach.

Alistair Cockburn – Introduction to Advanced Agile Development

I had the pleasure of sitting in the back for Alistair Cockburn‘s workshop, with Tony Ponton and Martin Kearns. Whilst I had seen some of this content in Alistair’s Agile 2009 keynote, Tony and Martin had been lucky enough to sit in Alistair’s 3 day class earlier in the year.

From Agile Australia 2011

Alistair does not use slides but rather a one page laminated handout. My comment to Alistair at the end of the workshop was “Second time hearing it, learnt twice as much”, so here are my notes from this time around.

From Agile Australia 2011
  • advanced agile is not more tricks
  • efficiency is short term horizon versus effectiveness which is long term horizon
  • why is agile less efficient – agile people are looney because we keep changing everything over and over and over again (requirements, design, test) plus the skills needed to be around for the entire project
  • why is agile more efficient – we make things more tacit which means teams work faster (not writing things down)
  • shu, ha, ri (practices, theory, self awareness) – move up and down the scales
  • The Oath of Non-Allegiance – “I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.” – basically, I will not reject an idea just because of it’s heritage
  • shu – when people encounter a problem, they want a technique (shoe box)
  • ha – when you start collecting techniques
  • ri – when you start making things up, merging ideas together
  • there is often combat between the shu and the ri on projects
  • craft – skills in a medium and life long learning – many 10-15 year programmers don’t see themselves in a craft, your medium is your programming language and for project managers the medium is people
  • cooperative game – people issues matter, software development is the combination of invention, communication and decision making, agile has brought team collaboration the top level
  • right level of documentation – might be more if people are joining and leaving the team regularly but might be less if the team is stable and there is little movement
  • most efficient documentation is video taping two people at a whiteboard, faster than typing and easy to create – users to describe their problem, etc…
  • design = distributed cognition – need to get everybody to understand the theory of how the whole works and a theory of a solution and we need to find the answer between the two that everybody can understand
  • keep an open mind
  • each project should keep the next project in mind
  • a little out of balance is OK
  • the length of a programming episode is 1 hour – separate slices to demo within a sprint – (see the Carparccio exercise)
  • tip off for a bottleneck – “we don’t have time for…” or “spare capacity to develop…”
  • learn early in the project to learn and reduce risk, then develop for value once risks are down, then deliver early or delay for scope / quality
  • Zynga put in features that don’t work and count the clicks to determine whether to build it and other companies get users to pay a Paypal account and if they get enough money they will build the feature
  • every month / iteration / delivery – reflection of what we keep and what we try to do next month (two columns) – what we did wrong does not help me
  • the people who know how to do more, learn more
  • blitz planning as a different way to tackle estimation

Agile Australia 2011: The Speed to Cool – Valuing Testing & Quality in Agile Teams

/ Craig Smith / 5 Comments

Agile Australia 2011My presentation from Agile Australia 2011 called “The Speed to Cool – Valuing Testing & Quality in Agile Teams” is available on SlideShare.

Ensuring that the approach to testing and quality is understood and appropriately valued in an Agile world can be a struggle for many organisations, especially when resources are limited and our customers are expecting business value in a timely manner. In this session Craig Smith will define what quality means, share a number of tools for measuring it as well as discussing approaches to improving the skills, empowerment and role of testing in the organisation and share why testing is the coolest role on the team and why it is everyone’s responsibility.

Some of the comments on Twitter included:

@AgileAcademy: Good luck today with your presentation at 11.30am on The Speed to Cool: Valuing testing and quality in Agile teams @smithcdau #agileaus

@vivierose: Waiting for room to fill at @smithcdau was standing room only last year! #agileaus

@adrianlsmith: #agileaus @smithcdau Software is a crime – Testers are detectives

@vivierose: Testers think ‘Everything is guilty until proven innocent’ @smithcdau #agileaus

@adrianlsmith: #agileaus @smithcdau discusses increasing technical skills of testers http://t.co/WPhbDsV

@mrembach: seeing an excellent talk by @smithcdau at the qualityInn #agileaus

@vivierose: Everyone likes to be seen as valuing quality, just like they love kittens, but it’s the 1st thing to be dumped #agileaus @smithcdau

@stephlouisesays: #agileaus loving @smithcdau challenging how well we apply the manifesto to testing. Card wall stages look remarkably like a waterfall… Hmm

@adrianlsmith: #agileaus @smithcdau applies agile manifesto to testing practices – great analogies

@AgileRenee: @smithcdau use the quality assessment tool now avail on the @AgileAcademywebsite http://lockerz.com/s/111080989

@stephlouisesays: #agileaus acceptance test development = specification by example… Beats heavy documentation any day @smithcdau

@timechanter: Fabulous presentation by Craig smith on agile testing. Liking the specification by example stuff. #agileaus

@stephlouisesays: #agileaus awesome session by @smithcdau quality and testing – relevant content, interesting slides (love the pics!) and fab speaker #newfave

@SMRobson: #agileaus @craigsmith finally!! Well done!

@AgileAcademy: 150+ watching great talk by @smithcdau on Valuing testing & quality in Agile teams. Terrific energy & passion. #agileaus #yam

@AgileAcademy: A tester is like Robocop – part man/woman; part machine but all tester! @smithcdau #agileaus #testing #quality #yam

@AgileAcademy: Thanks for the mention about the Agile Quality Practices sheet on our website. @smithcdau agileacademy.com.au #agileaus #yam

@seat_paul: #agileaus very good talk by Craig smith. As he says testers can be very cool!!

@mrembach: @smithcdau great talk Craig. Lots of take-aways

@smamol: Really cool #agileauspresso – beautiful slides: The Speed to Cool – Valuing Testing in Agile Teams http://t.co/1m1jwBL #in

YOW! 2010 Australia Day 2 Review

/ Craig Smith / Leave a comment

YOW! 2010Day 2 of the YOW! Australia software development conference in Brisbane, the following are my notes from the sessions that I attended.

Keynote: Exploring NoSQL

Erik Meijer delivered this keynote, which essentially proved that relational databases and NoSQL are mathematical opposites. The slides are available here.

  • “NoSQL took away the relational model and gave nothing back” – Benjamin Black
  • SQL is complicated and not very efficient
  • principle of compositionality
  • SQL and NoSql are opposites mathematically

Leveraging Internet Technologies to Build a New Breed of Software Development Tools

Martin Nally from IBM delivered this talk on development tools and RDF, his slides are available here.

  • 78% of people cite delivery pressure as to why they don’t use ALM
  • vendors believe their tool is the centre of the universe – if that is the case you need to know the universe
  • AD/Cycle tried a central repository model in 1990 – did not work, but most vendors still trying to this
  • currently we try to use the integrated model
  • third option is to use the world wide web and linked data (Tim Berners Lee) – give everything an URI, use HTTP URI so people can look them up, provide useful information on lookup (RDF), include links to other URIs – this is just REST!
  • “tools are just a prison for data”
  • we still build tools like we built applications in the 50’s – need all the data
  • RDF – universal data representation for the web, SPARQL is the RDF query language – XML looks awful for RDF, Ntuples is much easier
  • open-services.net – community around linked data for tools
  • focus on the integration scenarios because you will never get two customers to agree on the specifics of a test tool
  • friends don’t let friends represent data in XML
  • URLs should last forever – use virtual names, don’t tie to machines and don’t put meaning into URLs because it will change

iPhone & Android: From Concept to Delivery

Nathan de Vries spoke about iPhone iOS development and Daniel Bradby spoke about Android development, the slides are available here.

  • Australia has had abnormal adoption of the iPhone
  • design is a very important part of the platform
  • Apple publishes Human Interface Guidelines
  • aesthetic integrity – don’t want design to get in the way, match aesthetics to the type of application
  • direct manipulation – feel like you are interacting with the objects on the screen
  • metaphor – mapping design back to real life
  • consistent – apple provides a base framework – navigation, view, tab bar controller
  • start raw with ideas on big bits of paper, constraints of device means you need to be very iterative
  • when designing screens remember the different screen resolutions between the iPhone 3GS (480 x 320), iPhone 4 (960 x 640) and iPad (1024 x 768)
  • use vectors when designing images so that they scale down nicely
  • use the simulator but do not under estimate the value of testing on the device
  • testing tools not built into the culture but are gaining prominence (GHUnit and Cedar)
  • suggest that you always develop with the latest SDK for the latest devices and patches
  • use iOS Beta Builder to test with up to 100 users on real devices
  • use analytics to get real usage of your applications, 80% of apps are use once and 95% are abandoned after one month
  • track reviews but don’t take them to heart
  • Android is developed by the Open Handset Alliance, which includes a large number of developers, telcos and manufacturers, of which Google is just one
  • Dalvik is the Java virtual machine that runs on Android handsets
  • The Android IDE is built on top of Eclipse

The Emergence of UX in an Agile World

Victor Rodrigues and Xerxes Battiwalla from Cochlear spoke about combining agile and UX, their slides are available here.

  • agile came from internal IT projects, but UX came from consumer commercial products
  • experience needs to be designed
  • many user experiences are broken
  • a great resource is 20 Things I Learned About Browsers and the Web
  • start with a backlog
  • with UX you need to look at the entire system
  • decided that UX and development went separate ways and proceeded in two different stream
  • incrementally develop in a series of internal drops
  • 3 stages of UX evolution – idea storming (consider all options and dismiss them), prototyping (let designers choose their tools) and user testing (ease of use, makes sense, sketchy UI)
  • develop the UI after interaction has been defined, so start by developing the plumbing
  • designers and developers should use their own tools but talk a common language (markup)
  • MVVM – model – view – view model

Management 2.0: Leadership Models for an Information Age

Richard Durnal from realestate.com.au delivered this session, the slides are available here.

  • ChangingMinds.org – leaders vs managers
  • How I Learned to Let My Workers Lead – Ralph Stayer from Johnsonville Sausage in the Harvard Business Review
  • PARC(T) model – from The Modern Firm by John Roberts – People, Architecture, Routines, Culture and Technology
  • code wars
  • point kaizen (optimize points in the process)
  • flow kaizen (optimize the entire flow)
  • theory of constraints – keep working on the one problem that is causing you the most pain
  • systems management.theory helps bridge the gap from agile
  • kaizen vs kaikaku – kaizen only gets you so far because you see a slide, sometimes you need to introduce massive change
  • you can inspire people but they need to bring their own motivation
  • transforming REA – great people, cross functional teams, visual controls, agile and lean concepts, engineering practices, DevOps and hearts and minds
  • build a compelling vision (where do we want to go and follow)
  • decentralize responsibility and let go of control (people aren’t grasping in the way we expected, developers don’t grasp the business, take time to go out on sales calls, barriers they think are there are not really there)
  • work on the culture and the system
  • build a great environment (productivity gain has been huge)
  • look for trouble makers and throw them into teams with no trouble (wisdom of the crowd)
  • take risks, learn and move on

Row Together, Row in the Right Direction, Row Faster: Improving alignment and throughput in software development

Jason Yip delivered this talk, the slides are available here.

  • the best programmers are 10 times  better than average which is 10 times  better than worse
  • set the best performers as the standard (not the second worst performer) , teams only as strong as weakest link
  • need explicit time for performance and practice
  • lower threshold for incidents, raise threshold for incident response (fix the problem)

Forty Years of Fun with Computers

Dan Ingalls took us on a 40 year journey of his life in computing including Smalltalk 76 and 80, SqueakVM and Lively Kernel.

YOW! 2010 Australia Day 1 Review

/ Craig Smith / 2 Comments

YOW! 2010The YOW! 2010 Australia software development conference was held in Melbourne and Brisbane a few weeks ago. With a huge thanks to my good friend Nicholas Muldoon from the GreenHopper team at Atlassian, I had the privilege of attending the Brisbane conference. The following are my notes and thoughts from day one of the conference.

 

Extreme Java Productivity: Enterprise Applications in Just Minutes

Ben Alex from VMWare SpringSource gave this presentation on Spring Roo. This talk was one of the a-ha moments for me, as I really have not spent much time looking at Roo until now, and I was quite impressed with where they have taken this product. The slides are available here.

  • wanted to build productivity tool for Java developers
  • development time only, runtime stack is Spring
  • code generator active and passive
  • goal was not needing to read the manual
  • use ‘hint‘ and tab to help you setup the project basics
  • ‘controller all‘ to get a web tier
  • Roo keeps a log and this can be replayed as a script
  • web tier is using Spring MVC – 35% of Java developers use Spring MVC, the rest still use Struts or a mix-and-match
  • can run Roo without an IDE, if you do you need to you can install the AspectJ plugin
  • minimal approach means Roo starts by creating a JAR and only creates a WAR when you need to create a web tier
  • easy to throw away Roo if no longer want it (can also re-add it if you wish)
  • ‘database reverse engineer‘ to incrementally keep up with the database changes
  • can deploy to Google App Engine with one command, same with VMWare

Rails in the Large: How We’re Building (One of) the Largest Rails Apps in the World (for an Enterprise)

Neal Ford is always entertaining and in this talk he shared some learning from a large Rails development project. His slides are available here.

Neal started the talk with a visualisation of the activity on the project Subversion repository using Codeswarm. This is really cool but hard to explain, so here is a similar video of the Eclipse codebase. Look for the explosions, which are essentially big commits for releases.

  • the pursuit – inception phase / iteration 0 – 2 to 6 weeks
  • ove.com – asked Thoughtworks to build in .NET or Rails because existing developers were Java!
  • started with 2 developer pairs and added 2 developer pairs every week until they had 11 developer pairs, 8 BA’s and 6 QA’s
  • found that they needed more BA’s to pairs because of the ability to move through code quicker in Rails, traditionally about has about 3 pairs to 1 BA in Java
  • demonstration trumps discussion, don’t convince on technology too early
  • 3:1 ratio of test code to production code, typical for Rails
  • when living on a submarine, have fun!
  • run 8,996 unit tests in 4 seconds using unit-record
  • rule: unit tests don’t hit the database, mock and stub everything (under 1 minute) – fight the battle to keep tests fast and invent stuff if you need to
  • functional tests on the other hand can’t use stubs, run 3,964 tests in 248 seconds (under 5 minutes)
  • DeepTest – realised that tests were only using one core, so parallelised the tests – want to hear fans running on the machine!
  • Distributed DeepTest – use underutilised BAM’s (Bad Ass Machines) to run tests across the network
  • key to agile software development is feedback loops
  • Selenium Grid, used for User Acceptance Testing, problem is Selenium is really slow – took 8 hours sequentially, on grid was just over 2 hours
  • use continuous integration for lots of things that need automation (CruiseControl.rb)
  • VMWare Fusion to run dedicated applications locally
  • use green / blue infrastructure for deployment, means you test on real hardware and you have a rollback in parallel
  • project Mingle on the wall so there is a common canonical view
  • cc_board – clear view of status without needing to scroll – information radiator
  • jukebox.rb – plays a song when the build breaks, play a theme song upon successful checkin
  • pairing stations – installed Adium, no email because it is poison to developer productivity, use machine names and add the pair names to the status, laptops for personal machines
  • setup internal Jabber chat rooms
  • used API’s to update Mingle status on successful checkin
  • software is more about communication than technology
  • 100% pair programming
  • have fun, work does not have to suck!
  • automate everything – do something that is painful more often that will force you to automate
  • 1 click command to deploy to any development
  • canonical pairing stations using radmind (Linux and OSX) to keep all the machines in sync, some overhead but better than keeping 11 machines up-to-date by hand
  • for messaging started with message.rb as it was good enough, then moved to Starling when they needed it and understood what it would be used for
  • use external tests to check that external services still work
  • performance – use custom hand tuned SQL to do things like forcing indexes
  • upgrading is hard, don’t put it off for too long
  • you can solve anything with rock, paper, scissors and when you get really good you should check out worldrps.com

Integrated Tests Are A Scam

J. B. Rainsberger led this excellent talk on integrated tests. His blog posts (and the summary on InfoQ) on this subject go into a lot more detail. Finally his slides were impressive as they were drawn in real-time using an iPad.

  • slow – delays feedback which means more mistakes and more integrated tests
  • brittle
  • misleading
  • viral
  • corresponding collaboration and contract tests
  • the client always owns the interface
  • basic correctness – each layer talks to the next layer correctly

Testing Your Javascript

Corey Haines delivered this talk, which I blindly hoped would give an answer to the age-old question on how to deal with JavaScript (there was no sliver bullet though). His slides are available here.

  • has a bad name because it is just a scripting language
  • hard to test, no good tools
  • pain in testing means your design has problems – good design means it’s testable
  • tools – Jasmine, QUnit, JsUnit, JSpec, should.is
  • BDD – not tool specific, concept specific, feature level tests driving example level isolation tests
  • 4 rules of simple design (Kent Beck) – tests pass (you need to be able to verify it works), no duplication (knowledge has only one representation), reveals intent (name your objects / variables well) and small
  • SOLID principles – next level above the four rules for good design
  • design guidelines – stratified design (layer cake design), find canonical representation of your data and get away from the DOM and wrap these with builders and behaviors

Domain Modeling with Processes – Adventures of an “object head” in Erlang land

Kresten Krab Thorup delivered this talk which walked through the challenges of developing Erjang (Erlang on the JVM). His slides are available here.

  • Java designed in the client server age – coordination happened in the database
  • Erlang is a perfect domain specific language for event driven programming
  • patterns to ensure system is reliable
  • build reliable systems in the presence of errors – isolation + concurrency
  • emulator + BIF (built in functions) + OTP framework
  • Kilim – coroutines and asynchronous processing for Java

Release It! Design and Deploy Production-Ready Software

Michael Nygard delivered this talk which detailed some of the content from his book Release It!

  • author of Release It! plus 3 other books including Beautiful Architecture, 97 Things Every Software Architecture Should Know and the Java Developers Reference
  • failure is everywhere and it costs a lot
  • five nines equates to 25 seconds downtime per month – planned and scheduled – impossible!
  • average availability is 88% (3.6 days) for JEE applications
  • since 2004, most security attacks are now at the application level not the operating system level
  • QA tests functional requirements, non-functional testing is timely and costly, we don’t test for longevity of under production load
  • observed availability and stability over time
  • increased interest in DevOps – dev2ops and devopscafe are excellent resources

Keynote: 50 in 50

Richard P. Gabriel and Guy Steele delivered this keynote that covered 50 language lessons in 5o words or less. Some of the highlights for me were Piet (a language that looks like abstract art, and changes in colour affect the program flow) and Shakespeare -(a language where the code resembles a Shakespeare play – they showed a great video of how this would look which was well done). I also relived programming of languages from my past and present including COBOL, JCL, BASIC, Python Ant and Java.

A copy of the keynote delivered at JAOO in 2008 is available online if you would like to watch or relive it.

Agile Australia 2010: Building an A-Team – I Love It When A Team Comes Together

/ Craig Smith / 1 Comment

Agile Australia 2010My presentation from Agile Australia 2010 called “Building an A-Team – I Love It When A Team Comes Together” is available on SlideShare.

High performing teams are something that all organisations aspire to, but how exactly do you turn a team from good to great? There is much discussion in the community about management versus leadership, working in a factory versus embracing a tribe and how to motivate a new generation of employees. In this presentation we will look at these topics and determine what makes a high performing team, how Agile techniques can help, what tools and techniques you can use to create this environment and how you can measure performance.

Some of the comments on Twitter included:

@benarnott: Get back to the basics, remember why we are here, we are here to deliver quality software – @smithcdau #agileaus

@benarnott: #agileaus Some of the best company’s have thrown out performance reviews – @smithcdau Sign me up!

@benarnott:#agileaus @smithcdau is talking about Fedex days, Google days and Hackathons… I like to call them “Scratch an itch day”

@benarnott:#agileaus Leaders aren’t just PMs and Mangers, they are anyone with the skills and the passion like @renemaslen on BQI – @smithcdau

@benarnott:#agileaus I don’t want to be good, I want to be awesome! – @smithcdau

@benarnott:#agileaus in the overflowing room with @smithcdau talking the A-Team

@nickmuldoon: @smithcdau talking about the A team right now. Standing room only. #agileaus awesome!

@janevlahos: @smithdcau software development pays better than gardening #agileaus

Agile Australia 2010 Day 2 Review

/ Craig Smith / Leave a comment

Agile Australia 2010Day 2 at Agile Australia 2010 and another full day of sessions and hallway discussions.

Keynote: Martin Fowler

Martin Fowler gave a “suite” of keynote presentations, including a great impersonation of “Uncle Bob” Martin! He wrote about his trip on his blog.

  • agile manifesto has been way more successful than they thought when they wrote it
  • semantic diffusion – the message of agile has changed from the original thoughts, but that is the price of success
  • The New Methodology
  • agile is about adaptive planning and people first
  • predictive planning requires stable requirements – very rarely happens as requirements change
  • “a late change in requirements is a competitive advantage” – Mary Poppendieck
  • plan should be a current understanding of where things are
  • adaptive planning needs evolutionary design – the technical side is important
  • Frederick Winslow Taylor – father of planning in factories, invented scientific management, invented to control factory workers who were considered lazy and stupid
  • if integrating hurts, do it more often
  • every developer should commit to the mainline at least once a day – avoid the big scary merge
  • Continuous Integration article and Continuous Integration book by Paul Duvall
  • continuous delivery
  • commit tests need to run in less than 10 minutes – need to stub out databases, look out for slow connections
  • acceptance tests are more end to end but they run much slower, you don’t want to wait at commit time
  • all environments should be automatically configured, binaries should be stored in an artefact repository
  • commit > acceptance > performance > deploy
  • deploying to production should not really be treated any different to other environments – sometimes you may need to have a manual deploy step – this should be a business decision because software should always be production ready
  • Continuous Delivery book by Jez Humble and continuousdelivery.com
  • notion of tradeable quality – trading quality for speed / cost – makes sense when buying a car but software is different
  • external quality and internal quality – internal quality is invisible to customers, customers can choose external quality because they can see it
  • design stamina hypothesis – can trade design for speed but only up to a certain point – this hits you in weeks not months
  • technical debt term speaks to non technical people – paying off the debt and reduce the interest costs
  • technical debt cards at least help you have the conversation
  • inevitable that you will look at your code in future and think you should have done it better – this is still technical debt

You Can Take Your Agile Maturity Assessment And…

I was asked to be the MC for this session and had the privilege of introducing Marina Chiovetti and Jason Yip from ThoughtWorks. Their slides are available here.

  • easy to get started in agile – invest in training, coaches and experienced practitioners – but after a year or two, how do you know if you are investing in the right thing
  • looking for what’s really happening – what projects are hiding behaviors that we want to fix
  • you can look agile and game the results – what are you looking for, practices are not everything
  • create a culture for problem solving and learning – why don’t we have maturity assessments for these things?
  • poster child project so people can look at it and see it really works
  • successful project, everybody is happy, Prozac is cheaper, are you actually delivering?
  • data is important but more important to understand the facts – verify the numbers reflect reality
  • spider charts – depends on who is assessing, self assessment is only against what you know, so new teams score themselves high because they only know what they know, experienced assessors also look differently so you will get different results
  • disconnect between doing agile and getting to profit – what are we using agile to get better at?
  • tick boxes versus understanding the situation – will only change for the assessment or don’t understand why they are doing the change so the change won’t stick
  • uncover the behaviours you don’t want to see, even if the teams are successful
  • different teams need different measures of success – measure the drivers of success which will be different for each team
  • different assessors will yield different results
  • agile maturity used like a stick – use across organization, not to manage
  • describe your true north (lean) – provide direction so you can determine your next step
  • what does the organization value in measures
  • make work visible – window into the process
  • celebrate failure
  • enterprise 2.0 bullseye

Monster Builds

I also had the privilege of introducing Chris Mountford from Atlassian, his slides are available here:

  • manager was developer – mxd
  • long builds cause low velocity – context switching, task entanglement, build breakage confusion
  • tame monster builds through optimization – measure so you know what to fix, look at network and disk access, use repositories like maven, co-locate servers, then measure again
  • matrix culling – remove things you don’t want to support – browsers, operating systems, databases, dropped user editions, ancient application servers, old versions of Java – Atlassian dropped build from 60 to 18 hours
  • power to wait ratio – unit to functional tests – be selectively continuous
  • parallelise your tests – Amdahl’s Law – benefit of running more processes in parallel
  • false negatives are expensive – run builds against known good versions of the system to check to see if the infrastructure is broken

Building Quality Into The Lifecycle – All The Way Through

Sharon Robson delivered this presentation, her slides are available here:

Agile Australia 2010

  • agile makes it real, now, here
  • nobody knows what testing is, it’s hard to define
  • in agile you are all testers you just don’t know it yet
  • ISO 9126 defines software quality – her favourite standard
  • cannot define done until you can define what is good
  • need to define the what if questions up front, and we also need the answers – what are the things the product should not do
  • a good metric for government departments – “will it make the newspaper” or even worse “will it make the front page”
  • technical debt – “don’t apply for the mortgage”
  • testing is a growth industry – the amount of regression grows every iteration
  • testing is about information, risk and making sure it is good
  • testing is pervasive – we should be testing everything all the time – process, people, tools, requirements
  • everyone in an agile team is a tester and knows what is right and wrong – just need to empower them
  • test all your development artefacts – look at everything with your tester eyes on
  • agile testing techniques are no different to traditional testing techniques
  • story cards are not relevant as artefacts – tests should tell you what the system does
  • we live in a world of regression, it is the responsibility of the entire team
  • automation is a must have – don’t automate everything but you need technology to allow you to cover a lot of ground very quickly

Open Space

I sat in for a while on the open space topic of testing in agile, which was led by Rene Maslen. Some good conversation and discussion in this group.

Panel: Paying Down Technical Debt

It was great to be asked to be on a technical panel, especially with the likes of Martin Kearns, Adam Boas and Andy Marks with Marina Chiovetti looking after the moderation. Probably most nerving was seeing Martin Fowler sitting in the front row!

Marina initially set the scene for technical debt. Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:  “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt?

We then kicked into a number of questions:

  1. What does technical debt look like?  How would I know if I saw it?
  2. What are some of the common causes of technical debt on teams you’re working with?
  3. How do you prioritise technical debt against new feature development?  How do you construct a roadmap for paying back technical debt?
  4. What is the cost of tech debt?  How can we monetise it?
  5. I’ve heard of one team that had a technical debt backlog that was prioritised beside the product backlog.  The CEO set a target that the tech debt backlog couldn’t grow beyond 10% of the size of the product backlog, and as soon as it got bigger than 10% the team had to start focusing on paying down the tech debt.
    So, how do you monitor technical debt and manage it so that it doesn’t spiral out of control?  Can you give us some examples or techniques you’ve used?
  6. Technical debt sounds pretty, well, techie.  How can we expect business/product owners to understand its impacts?  And how can business owners align their objectives to managing tech debt?

Distributed Agile Projects

After the close of the conference, I had a nice long chat with Siva Dorairaj from Victoria University of Wellington about his PhD research into Distributed Agile Projects. I look forward to seeing the outputs from his research.

Agile Australia 2010 Day 1 Review

/ Craig Smith / 5 Comments

Agile Australia 2010Agile Australia 2010 was held for its second year earlier this month at the Crown Conference Centre in Melbourne.

Once again I was honoured to be offered an opportunity to present, but I also had the pleasure of being a conference organiser, an MC for speaker sessions on both days, the opportunity to be part of panel discussion as well as running a workshop with Phil Abernathy on the day prior to the conference for those new to agile. The conference attracted 450 attendees from 140 different companies.

One of the difficulties of assisting in the organisation of a conference like this (and I had a similar experience co-producing a stage at Agile 2010) is narrowing down the large number of proposals into a program that will meet the expectations of the intended audience. There was much discussion and debate throughout the process, but I think we ended up with a well-rounded program that covered a wide range of topics, experiences and session types. I owe a huge thankyou to Rachel Slattery from Slattery IT for giving me the opportunity to have a greater involvement this year and the ability to work with the other organisers Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Zaz Teoh.

My notes and summaries are below:

Pre-Conference Workshop: First Steps In Agile

I ran a pre-conference workshop for agile beginners with Phil Abernathy entitled First Steps in Agile, which was based on some of the introductory material that is available in the courses offered by the Agile Academy.

In 3 and a half hours we ran through the fundamentals of agile, and had them creating focusing questions, success sliders and story cards before getting them to play with Lego to deliver an agile project.

Executive Breakfast: Accelerating Agility for Executives and Managers

Jim Highsmith delivered this breakfast seminar to special guests and conference speakers.

  • there is no more normal
  • efficiency vs responsiveness – which one is your model – Walmart vs Google
  • business agility – a key resource is David Sull – The Upside of Turbulence
  • if agility is a key bus driver, create a Chief Agility Officer
  • there are a number of executive levers
  • quality matters, Michael Mah from QSM is a good agile data source
  • adaptive quality – can you deliver good quality code in the future, key job for executives is to champion a technical debt reduction strategy
  • do less – reduce work in progress, requires a lot of discipline
  • eliminate marginal value – Standish have found that 64% of features are rarely or never used
  • motivate – autonomy (self organizing teams), mastery (getting better at what we do), purpose (working on value)
  • doing agile vs being agile – difference between half assed and half done, executives that not only support agile but understand what it means and be part of it
  • “Be the change you wish to be in the world” – Gandhi
  • agile leaders – it’s OK to be wrong but not OK to be uncertain, need to balance between up-front and just-in-time
  • focus on value not the constraints, what is the capacity to release
  • agile 101 – need to start with the rules based prescription, but you can’t get stuck there – move from prescriptive agility to adaptive / adult agility
  • salesforce.com – 60,000 tests, all one code base trunk
  • all agile models are flawed because the world is a complex place – you need a hybrid approach
  • quality is the key to future value
  • “It’s kind of fun to do the impossible” – Walt Disney
  • Martin Fowler said accumulation of technical debt comes in weeks not months, observed over time that it slows you down

Keynote: Beyond Scope, Schedule and Cost – Optimizing Value

Jim Highsmith delivered this keynote, the slides are available here.

  • there is no more normal, it is all change – important to adapt to that change rather than following a plan
  • 95% removal of defects on a project is where benefits accrue – good companies in the US average 75% so we have a way to go
  • focus on speed and you will get low quality and low speed, focus on quality and you will get speed
  • a doubling of staff traditionally quadruples defects, so need to focus on quality
  • error feedback – errors put into system when fixing other errors
  • create opportunities by doing less – scope is a terrible measure of progress
  • do most valuable first and choose the right cut off point, most value for least cost
  • value engineering – estimate in both cost and value – calculate cost from the bottom up and value from the top down
  • say to product owners – “if you don’t have time to estimate value, we don’t have time to estimate cost”
  • process maturity models only look at the process and not the value
  • parking lot diagram (FDD) to show what is valuable – only goes green when it is deployable – done done
  • value and priority are different – sometimes you may need to mitigate risk or deal with dependencies
  • may want to prioritise technical debt stories different to customer stories
  • every iteration is the product releasable, focus on releasability and does it meet the vision
  • agile triangle – value (releasable), quality (reliable, adaptable), constraints (cost schedule scope)
  • being responsive – product, adaptive people, agile process, architect with a vision
  • strategic questions – can we release today, value-cost ratio, product quality, within acceptable constraints
  • getting funding – business cases still very traditional, need to look at funding models and change them over time, find ways to capitalise expenses or deliver early to get the attention of the CFO – ask CFO what appeals to them about agile

Keynote: Delivering Business Value with Agile

Jeff Smith from Suncorp delivered this keynote. I was pumped because he mentioned my name at least twice!

  • agile – fundamental change in how work gets done
  • good is not good enough, great is not good enough, only being the best is good enough
  • change has always been there, but it is quite disruptive right now
  • need to change people from thinking that we can’t do things – what can we do?
  • don’t need to change your strategy all the time – you need to adapt it to get value but keep your values consistent
  • attract, develop and retain good people is the role of good leaders – job is not to motivate, nurture their passions
  • shift your thinking – we don’t know best, look at your partners and competitors
  • course correction over perfection – it’s OK to make mistakes
  • simplify the way people work together to simplify output
  • trust and respect the key values – trust takes character (integrity and intent) and competence (capability and results)
  • fear of failure is actually masking the fear of criticism
  • a great culture – people love what they do, love who they work for (people leave leaders not companies), love who you work with
  • collaboration – contribution, good instruction and feedback
  • best thing about Yammer is that it is a flat communication structure – increases productivity and removes cascading messages
  • strive for level-less leadership – wisdom of the crowd, removes the communication waterfall
  • need coaching, like sports teams, to get better
  • constraint is a leaders ability to communicate and direct change, not the business ability to absorb it
  • Suncorp is twice as productive as they were a year ago – measure performance by the number of productive business changes into production
  • inspire people to flourish personally as well as professionally
  • need to break down hierarchies, constraint of thought is caused by management
  • remove fear about changes by involving people in the process

Old Tricks for New Dogs and New Tricks for Old Dogs

I was asked to to be MC for this session, and had the privilege of introducing Shane Hastie from Software Education. His slides are available here and you can also download his Project Toolkit Matrix.

  • dudes law – value = why / how (David Hussman)
  • context – sociology (trust, safe to fail, communication), organization, geography
  • babies and bathwater – focus on which one it is, what is of value and what can go down the drain
  • all the old tricks still have value
  • new tricks – value stream mapping, story mapping, user stories (fundamental agile but may not be the right tool), BDD, pragmatic usability (everybody’s responsibility), paper prototypes (don’t craft a long term artifact, craft for conversations)
  • agile constants – TDD (every project should do it), refactoring, continuous integration, automated testing, pair programming, sustainable pace, retrospectives – these are just the givens
  • introduced a matrix on how to select the right tools (see link above), and encouraged feedback

It’s the Culture Stupid

I also had the privilege of introducing Rob Thomsett, who’s talk was one of the highlights of the conference for me, his slides are available here.

  • modern management which dates back to late 19th century, has reached the limits of improvement
  • companies make cultural change because they are hurting or need to – explains hotbed of agile in Europe
  • most high level executives believe projects take too long to deliver, project management techniques are bureaucratic
  • watermelon projects – “green on the outside, red on the inside”
  • don’t under estimate cultural change when you go agile – will make you feel naked
  • welcome to agile, welcome to a battle – the war has been raging for 40 years
  • outsourcing as payback (referenced in Radical Project Management) – issues is there is no payback
  • culture is about values – it’s about what you believe in, it’s sucked into you through life
  • standing over somebody and asking for an estimate is an ambush – then play guess the number, price is right, doubling and halving game
  • Estimation Games – most downloaded article on the website, but is has made no difference
  • Fubini’s Law – every agile person should read it

Continuous Deployment

Kane Mar presented this session, his slides are below:

  • all started with continuous integration – the best paper is the original whitepaper by Martin Fowler
  • continuous deployment is continuous integration on steroids
  • who’s doing it – kaChing, Pirum, imvu, WordPress, Flickr, wiredreach
  • continuous deployment gives you quick feedback from customers, avoid waste (reduce cycle time)
  • easier in some environments such as web, but it is possible everywhere
  • requires investment in infrastructure and testing
  • adoption – get continuous integration, stop the (commit) line, simple deployment, realtime alerts, test!
  • avoid allowing broken tests, unrealistic expectations

Lightning Talks

There were a number of scheduled lightning talks, followed by some ad-hoc talks which I unfortunately missed (including one from my colleague Rene Maslen). From the couple of talks I saw:

Big A vs Small a (Tania Broome)

  • little a is about delivery, philosophy, set of principles
  • big a is about empowering teams and giving them the tools to get there, it’s a statement of commitment to change
  • shi, ha, ri – practice the rules, question them then transcend the rules because it is who you are
  • big a agile is shu, risk that we stop here

Agile at Home (Ben Arnott)

Ben is another one of my colleagues, and he presented a great talk about how he uses agile at home with his family.

Building an A-Team: I Love It When A Team Comes Together

The session I presented got an awesome turnout (standing room only and people sitting at the front around the stage)! The slides are available in a separate post as well as here.

I wish somebody had got a photo!


Other Stuff

I spent a great deal of time during sessions and breaks talking to many different people about a range of many different things. In particular, I spent the majority of the last session having an awesome chat about agile testing with Veenu Bharara from Atlassian.

ThoughtWorks hosted an open house in their Melbourne office after the last session which again was an opportunity to speak with far too many interesting people to mention.

Agile 2010: I’m The Business & Agile Was My Idea

/ Craig Smith / 2 Comments
I'm speaking @ Agile 2010

I’m speaking @ Agile 2010

My presentation from Agile 2010 called “I’m The Business & Agile Was My Idea” is available on Slideshare.

Agile is often traditionally associated as being exclusively applicable to the field of software development. However, non-software development projects can take ownership and use agile values, principles and practices to great effect. In this session, I will offer some approaches, techniques and examples for introducing agile into parts of the organisation that traditionally may not have considered it such as central services like finance, HR, marketing, traditional business areas as well as other areas of IT like infrastructure and provide some real-life examples along the way.

Agile 2010 Day 5 Review

/ Craig Smith / 1 Comment

The final day of Agile 2010 was all about keynotes. Before they kicked off, the Agile 2011 committee was announced (to be held in Salt Lake City), as were the Gordon Pask winners (it was awesome to see Elisabeth Hendrickson take the award along with Liz Keogh). They also thanked the organisers and sponsors (it was a first for me to have my picture up on the big screen for this reason!)

IMG_6071

Here are my notes:

Keynote: Product Centric – A hot new trend for IT organizations

Dave West from Forrester Research delivered this keynote.

IMG_6073

  • difference between a methodologist and a terrorist is you can reason with a terrorist
  • success of any process is a movement – passion and energy
  • IT departments are acting like product companies – it’s insane
  • pragmatism is important – one size does not fit all
  • software is a key catalyst to innovation – was cost and quality but now innovation, speed and agility are top of CIO minds
  • software is getting more complex – space shuttle has 2 million lines of code whilst the new S class Mercedes is 20 million lines of code – for new cars, software is 10-15% of the R&D cost
  • projects still fail, agile is seeing 70% success however
  • disconnect between software and the business – we usually try to bridge the gap with a PMO
  • mess of many – we tend to automate business processes and end up with a mess between the business and software processes – we spend a lot of time testing because we don’t know the impacts or understand them, not because we changed a lot
  • Agile is the predominant methodology (35%) although the second most popular was no methodology at all (30%), iterative 21% and waterfall 13%
  • CSM means you have just gone to your first disco but that doesn’t mean you can dance
  • we build better software when we know WE have to maintain it
  • organisations moving to product-centric operating model
  • people – learn more about the business, better developers are 10-20% more productive than average developers as they deliver real business value
  • organisation – measure as a team (need to eat, argue and drink together), aligned to a business process
  • process – release and software process is usually separate because the infrastructure is constrained and allows development to deliver, designers being dropped into a team force you to think in a different way
  • need clear business traction – need to work with the business to solve problems – deliver a product that creates business value
  • measure by business value, be incentivised by business results, learn about the business not just technology
  • separation between IT and the business gets in the way of speedy cadence
  • much simpler world – simplify the budget process, cut the red tape to get projects started
  • IT to business is too complicated – make it simpler, simple value chains and exploit it the simplest way you can
  • learnt when they built RUP they made it too complicated

Keynote: Stuck in Ha

Ron Jeffries and Chet Hendrickson delivered this keynote. I found it fun, but I wonder if people who were not familiar with Ron and Chet’s style would have walked away a little confused…

IMG_6076

  • shu, ha, ri – you are doing it wrong
  • scrum is so simple if you actually did it it would have to work – but it is not enough
  • we spend a lot of time trying to change the process, we need to change the situation
  • we tell first timers to inspect and adapt – unfortunately it can take long time if you are just picking practices
  • context is just the decisions that were made before you
  • agile skills project – map of things you need to know to do agile well
  • Alistair Cockburn is also mapping knowledge
  • need to explore the whole map
  • Scrum is a doorway to agile, it is an entry point not a destination
  • idea from conference – there is lots of ideas out there, and we need to look at every darn one of them
  • doing it better is not harder, it is easier — do it better!

Keynote: ADAPTing to Agile for Continued Success

Mike Cohn delivered this keynote, the slides are available here.

IMG_6078

  • agile is the second wave of OO – many of the luminaries came from here
  • the number of lines of code in Ford vehicles has jumped from 2.5 million lines of code in 2005 to 10 million lines of code in 2010
  • claim that agile is 5-10% faster – very few teams have achieved this, this is not the norm
  • agile is a standard set of things – people started with waterfall-but, it’s not about strict adherence, continual
  • process of inspect and adapt and become the best we can be
  • doing Agile is easy – getting better results but it is not easy
  • agile is not something you become, it is something you become more of
  • need to raise the bar on each other
  • don’t need to be perfect, just need to be 1% better than your competition – Google is not the perfect search engine, if they were we would just hit I’m feeling lucky

ADAPT

  • awareness that there is room for improvement
  • desire to change
  • ability to work in an agile manner
  • promote early successes to build momentum and get others to follow
  • transfer the impact of agile throughout the organization so that it sticks
  • awareness, desire and ability is what we need to look at when others frustrated, communicate the problem, use metrics (maybe metric per employee), expose the new people and experiences, start with a few practices
  • desire – create a sense of urgency, communicate a better way, take a test drive and build momentum, overcome waterfallacies
  • ability – coaching and training, hold others accountable, just get started don’t wait
  • promote – agile safari at Google to go and see a team doing it right, to see agile in the wild
  • transfer – break out of organisational gravity otherwise you will get sucked back to status quo (plus daily standups)
  • need to iterate towards agility – use an enterprise transition community in conjunction with improvement communities (formed around the passion of a small number of people)
  • create an improvement backlog – create communities and tackle improvements
  • return next year more agile than you are today!
  • let’s make it software development and not agile software development

The Happiest Place On Earth

And with the conference wrapped up at lunch time, I used the rest of the day to visit Disney Hollywood Studios and Magic Kingdom!