Author: Craig Smith

Agile Academy Meetup: The journey of becoming Agile or even more Agile

/ Craig Smith / 1 Comment

MeetupAgile AcademyA few weeks ago, the Agile Academy held its February 2011 meetup, with three speakers and a panel discussion on agile adoption in different organisations. There was a good turnout to hear the 3 speakers:

Here are my notes from the short sessions.

Adrian Smith (Ennova)

Ennova is a startup in the engineering space:

  • start with an idea or a better way of doing something as well as good people and customers
  • get an idea, develop it as quickly as possible, give it to your customers and learn
  • use low-fi tools: story wall, Pivotal Tracker, user personas and scenarios, build prototypes but enforce rules such as “can’t give this to the customer” or “no tests”, offshore remote pairing with Skype and iChat, version control using GitHub, continuous integration using Hudson, testing using Cucumber and RSpec, one-click deployment in Hudson and EC2 test grid, communications with Campfire and Yammer for chat and retrospectives using Listhings
  • started with the culture in mind, set principles and hire the right people
  • whole business needs to be agile, focus on technical quality important

Nigel Waddington

Nigel relayed his experiences from setting up Agile at a large software organisation:

  • don’t believe case studies, every customer is different
  • it’s all about yoghurt! – cultural change is hard – need leadership involved plus bottom up engagement
  • leaders care about money – “show me the proof that waterfall works!”, they want predictability and reporting and to make money
  • ran pilots to show success – choose good duration, start small and grow and make sure it has executive buy-in, don’t choose pieces of work that are too easy
  • pilots are good to engage people – train, educate, seed teams – get them to push and make it happen
  • balance between fast and evaluation
  • eat your own dog food, “iterating towards agility” (Mike Cohn), use a virtual scrum team for transition
  • don’t mess with the Scrum basics in the beginning
  • remember you go to work to deliver software, not to do Scrum

Elio Patane (WorkCover Queensland)

WorkCover Queensland is a workers compensation insurance company:

  • weren’t delivering quickly enough resulted in reduced confidence from the business
  • wanted to be agile, but not capital “A” Agile – did not want to lose sight of goals
  • started with customers breaking down projects to deliver value
  • solution delivery framework – Idea -> Discussion -> Plan -> Build -> Implement
  • needed to improve communication around intent of project – created a “project picture” to give context
  • found out that they did not know enough about stories – started too early – more in planning phase
  • standups – walk the wall, back to front rather than the 3 questions as they missed the picture of progress
  • ATDD using Cucumber and Watir – testers break the build, just like developers
  • one floor, open plan environment
  • big release walls – give management a view
  • can now to deliver to Production every 3 weeks and high quality

Panel Discussions

The panel discussions covered some awesome questions from the audience. As I was lucky enough to be asked to moderate the panel, I did not get the opportunity to record any notes from this session.

Sydney Go Inaugural Meetup January 2011

/ Craig Smith / Leave a comment

Google GoI got along to the “Googleplex” when I was in Sydney the other week, and with Steve Dalton checked out the inaugural Go Meetup. I have spent very little time looking at Go, so was interested to get some background into what it is all about.

Andrew Gerrand gave (part) of a talk on Practical Go Programming (I say part because it turned out to be a discussion with the slides rather than the talk). The slides are available here, but the talk is available as a recording from OSDC 2010.

Steve Dalton also interviewed Andrew Gerrand on the Coding By Numbers podcast earlier in the day, which is well worth a listen.

CDS43: 2010 Review

/ Craig Smith / Leave a comment

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 5,200 times in 2010. That’s about 13 full 747s.

 

In 2010, there were 37 new posts, growing the total archive of this blog to 71 posts. There were 4 pictures uploaded, taking up a total of 406kb.

The busiest day of the year was September 2nd with 114 views. The most popular post that day was Agile 2010 Day 2 Review.

Where did they come from?

The top referring sites in 2010 were twitter.com, infoq.com, ow.ly, unimplemented.blogspot.com, and linkedin.com.

Some visitors came searching, mostly for aaftt, alec sharp, apple application development training, ubuntu set java_home, and aa-ftt.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Agile 2010 Day 2 Review August 2010
1 comment

2

Apple iPhone Management & Web Application Development Training July 2010
1 comment

3

Atlassian Summit 2010 Day 1 Wrapup June 2010
3 comments

4

AAFTT Workshop 2010 (Orlando) August 2010

5

Agile Australia 2010 Day 1 Review September 2010
3 comments and 1 Like on WordPress.com,

Agile Academy Meetup: A is for Agile, the start of something good!

/ Craig Smith / 1 Comment

MeetupAgile AcademyIt’s that time of year where you start to clear the decks for the next year, and, in amongst a bunch of files on my hard disk, I found my notes from the Agile Academy Meetup from April 2010 in Brisbane, which I thought had been long lost to binary heaven.

At this meetup, Phil Abernathy presented an introductory agile session entitled “A is for Agile, the start of something good!” He had some good some refreshing points, and some of my notes from the session are here:

  • why change – better, faster, cheaper – key driver, but customers have always wanted this even before the Global Financial Crisis
  • RAD – “the good old days”
  • agile is evolutionary – developed over time from RAD, XP, Scrum, etc…
  • pendulum swing from waterfall to agile is a bad approach
  • agile is made up of values and principles plus technology, social and management practices
  • values and principles are not enough, so the only way to implement these are practices – social, technology and management
  • being accountable is a key value, but gets harder as agile teams work closely together, so you also need courage, respect & honesty as well
  • wisdom of the crowd is always better than the best person in the group
  • simplicity is the most difficult principle to implement – humans always want more detail
  • self organization does not mean no leadership – it means even more leadership
  • if you get kickoff of your project wrong, it will always go wrong (regardless of waterfall or agile)
  • agile successful in non-software development projects – biggest demand in Suncorp is from the business
  • benefits linked to outcomes which are linked to features which are then linked to stories
  • agile is different to RAD because we don’t prototype, we build… iteratively
  • in agile we don’t write documentation until we have shared understanding, but there is a discipline to the amount and the need to refactor
  • issues with agile adoption are usually on the IT side of the fence, once the business have seen it they will be the biggest supporters

Phil then answered some questions from the audience:

  • PRINCE2 now has a large agile component to it – is no different because agile sits on top of it – agile has rigour and will work with any project management method
  • governance – heartbeat of the steering commitee must be the same heartbeat as that of the project
  • selling agile – you need troaching – training and coaching together, it’s a change management journey
  • don’t expect a successful agile project to sell agile in the organisation, you will get resistance – need to manage transition from pilot to scaling, need buy-in to the pilot to avoid this
  • where do you put agile artefacts when you don’t have walls – mobile whiteboards, walls, a company in San Francisco just got seed funding for agile walls
  • do not recommend using a tool over tangible materials

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 Academy Meetup: A Business Value Focused Model for Story Identification

/ Craig Smith / 1 Comment

MeetupAgile AcademyShane Hastie presented at the September 2010 Agile Academy Meetup in Brisbane on the topic of user stories. Here are my notes:

Agile Academy Meetup Shane Hastie

  • use models to break complex problems down to manageable chunks
  • Standish Group – number of canceled projects has increased with agile and number of wasted money projects have decreased – trend seems to be that agile is driving the cancellation of bad projects
  • business value is not delivered until it is in production and being used by the users
  • nobody ever does a business realisation review – 9 months after the project ask did we deliver what we said we would deliver
  • turn the story card around to emphasise value – so that… I want…
  • users is a bad term – implies they are addicted to something – they are customers of our service, victims of our software
  • think about who is your customer, what are their real needs – pin a picture up of them up on the wall to remind you to ask what they would think
  • events happen – business events (random but we need to be able to respond them when they arise), temporal events (happen due to the passage of time such as end of month, annual backup, daily backup, quarterly review) and conditional events (happen because something else happened)
  • suggest adding when to epics to track events as a… when… I want… when… so that
  • elementary business process – done by one person (or small team) in one place at one time – this is the level we should usually look for our epics
  • look for CRUD – a business process that is supposed to happen
  • latch onto nouns in customer conversations – a trigger that something is done
  • look at the management levels – we are good at the immediate needs of the workforce, but what about the needs of supervisory management, middle management and top management
  • think about the impact of data from external sources – what if the GST percentage changed tomorrow (it is in New Zealand!)
  • the model for epics – As a.. When… I Want… Using… So That
  • add the CRUD to the using statements to confirm the process
  • next level down look into Jeff Patton’s story mapping process
  • the smell of stories – PERFUM (Performance, Efficiency, Functionality, Usability, Maintainability) – in some cases if you don’t look after these, a refactor will mean rewrite the system
  • value is in the delivery of a complete epic
  • epic model helps you figure out how big the project is without going to a low level of detail
  • epic model is based on early work by Ed Yourdon and works on any project, including waterfall

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

ANZTB SIGIST Brisbane: Agile Testing & How We Need To Change

/ Craig Smith / Leave a comment

ANZTBA couple of weeks ago I had the opportunity to present at the ANZTB SIGIST Brisbane September meeting with my colleague Rene Maslen. Our talk was “Agile Testing and How We Need To Change” and the slides are available on Slideshare.

Some of my other colleagues also presented on the night including Ben Sullivan and Brent Acworth who spoke on BDD and some work they are doing on an open source framework for JBehave and Craig Aspinall who spoke on Automated Black Blob Testing.

Alister Scott had some nice words to say on my presentation on his blog and was also nice enough to take some pictures, which I have embedded below:

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.