Agile Australia 2011 Day 2 Review

Agile Australia 2011Day 2 at Agile Australia 2011 and another jam packed day. Here are my notes from the sessions I attended.

Keynote – Elevating the Agile Community of Thinkers 

Jean Tabaka presented this keynote, barefoot, and her slides are available here.

From Agile Australia 2011
  • A Community of Thinkers” – drafted by Liz Keogh, Jean Tabaka and Eric Willeke
  • need to apply energy to learning rather than frustration – need to subscribe to the art of the possible
  • it is no longer acceptable in the 21st century to administer in the business, we need to create and provide innovative communities
  • fearful that in the agile community that we are in conflict mode but rather we should seeking enquiry and insights and learning from each other, such as we do in an daily standup
  • to be the best we can be every day, we need to inspire insights from the entire team – the definition of a good daily standup
  • Patrick Lencioni’s “The Five Dysfunctions of a Team” also apply to community
  • “vulnerability can create great workplaces and innovation” (Dr. Brene Brown)
  • our greatest wisdom is every insight in the room and is only as good as the quietest voice in the room – we have to lower the bar
  • in a command and control environment we lose wisdom and lower their IQs
  • in global teams you need to invite their wisdom in anyway possible – secret to distributed teams
  • Kathy Sierra – magic for Creating Passionate Users
  • drop outs give up when they believe they suck
  • amateurs learn how to do it and then become complacent
  • experts – keep pushing themselves to find a better way
  • in agile need to believe past both the “this sucks” and the “kick ass” threshold
  • we need active participants in our communities, rather than passive participants
  • Linchpin (Seth Godin) – being a genius self, being part of community means hard work
  • Principles of Product Development Flow (Donald Reinertsen) – this and Linchpin are Jean’s most dog-eared books
  • empathy mapping (gogamestorm.com) – look at your community and what are they thinking, hearing, saying, doing, seeing
  • use a wall of appreciation as well as a wall of break up letters to improve community and move past blockers
  • writing love letters to agile – interesting…
  • to be a linchpin your message needs to be accessible (charm), need to create talent around your message and have perseverance
  • “Drive” (Dan Pink) – autonomy (able to bring your genius self to work), mastery and purpose (a big hairy goal) – you will be creative
  • need to design a life and not a plan – how can we grow and be emergent in what we do, plans stagnate and stagnation kills
  • “Preferred Futuring” (Lawrence Lippitt) – create concrete wishes on where we want to be, need to bring this more into our workplaces
  • need to move – tell -> sell -> test -> consult to co-creation
  • find your mentor, or become that person
  • think like a genius – creating models of what might be true
  • example of Rally using lino to organize an open space – awesome
  • Jean not wearing shoes in this keynote is going out of your comfort zone – onedaywithoutshoes.com

Panel – Software Engineering is a Dead Craft

I was honoured to be given the opportunity to moderate this panel, consisting of Martin Fowler, Kane Mar and Paul King. My opening comments were as follows:

Software Engineering is defined by the IEEE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.

This led me to then get a definitive definition of engineering, which is loosely defined by a number of the leading engineering councils worldwide as being the discipline of acquiring and applying scientific knowledge, mathematics and ingenuity to design and build solutions that safely improve the lives of people.

Software engineering as a term has been around since the early 1960s, and, as Rob Thomsett pointed out in his keynote yesterday, was popularized when NATO hosted a conference to address the problems of software development. In there report, they particularly point out that the phrase software engineering was deliberately chosen to be provocative. So for the last 50 years, practitioners everywhere have been debating software engineering, from the software crisis that made developing software into a career, through to Fred Brooks coining the No Silver Bullet argument that no individual technology would make a 10 fold improvement in productivity in 10 years, through object oriented programming and the rise of XP and agile.

So what is software engineering. Is it an engineering practice that is dead? Is it a craft or an art form? Or is it both dead and a craft?

Martin Fowler is the Chief Scientist at Thoughtworks, author of many books on software development and a signatory to the agile manifesto.

Kane Mar is the President of Scrumology, and has been a developer and coach in the software industry for 20 years.

Paul King is the Director of ASERT and has been developing, training and contributing to the software development field for nearly 20 years, and is an active contributor to a number of open source projects including, most notably, Groovy.

My questions started as follows:

Martin – when you do any Google search on software engineering, every second link seems to point back to your website and any number of articles you have written on this subject over a number of years. You indicated your position is that the engineering metaphor has done our profession damage…

Kane – you listed your point of view on the topic is that the paradigm has come and gone and that perhaps software should be viewed as an ecosystem…

Paul – your viewpoint is listed as probably a little more conservative and that continuous learning is important…

The time flew by and I did not get to take anywhere near the number of questions I would have liked from the audience. The highlight was a question from the audience from Phil Abernathy who asked the panel if perhaps we should term what comes out of a number of projects as “crapmanship”.

Agile and Enterprise Architecture are not Mutually Exclusive

I had the pleasure of introducing Rebecca Parsons from ThoughtWorks, her slides (in all their Comic Sans MS glory) are available here.

From Agile Australia 2011
  • architects need to depress their ego and pair on critical stories and calm their concerns
  • some architects believe their job is to stifle any innovation in the development team, but they a disappointed that the team is not innovating
  • the IDE of enterprise architects has been PowerPoint for years
  • developers must code in a box, architects must worry about a bigger box
  • it is hard for enterprise architects to talk to every developer, so documents from high are standing operating procedure, unfortunately they get ignored because the context is hidden
  • use stories for technical requirements – architect communicates his requirements via a technical story and the development team responds with this is what it is going to take – ensures that the value is articulated
  • need architects to articulate their requirements based on acceptance tests
  • harvest components and talk in the community – ask who was the last person to integrate with this component and talk to them
  • development team should be focussed on delivery of their project, agile is the engine and architects need to use this engine

The Speed to Cool: Valuing Testing and Quality in Agile Teams

The session I presented got a good turnout, and plenty of questions afterwards as well as some follow-up emails.  The slides are available in a separate post as well as here.

From Agile Australia 2011

Rolling Out ‘Agile principles’ in a Global Organisation – A Continuous Journey

I introduced Sascha Ragtschaa from Computershare, his slides are available here.

From Agile Australia 2011

A Rogue’s Take on the 4 ‘C’s: Culture Change Costs Currency

I had the pleasure of both introducing and being a live prop (the dragon representing the (large) organisation) in this presentation by my good friend and colleague Renee Troughton from Suncorp. Her slides are available here.

From Agile Australia 2011
From Agile Australia 2011

Keynote – Software development in the 21st Century

Martin Fowler delivered his now famous 3 short keynotes.

From Agile Australia 2011

Non-Determinism and Testing

  • non-determinism – intermittent fails, we don’t know if something is going to succeed or fail – also called a useless test
  • non-deterministic tests infect the whole system – need to quarantine these tests to stop them bringing down the while suite – often caused by interference between tests
  • you can track dependencies or you can use isolation (preferred method)
  • tests should clean up after themselves and leave the world the way they found it but other tests rely on this happening (and hard to track failures when they occur) or start all tests with a clean slate (but it can take a long time)
  • asynchrony – can use a bare sleep but you never know how long to sleep for, could use a polling loop or a callback
  • remote services – don’t talk to them as part of the test, use a test double

Value of Software Design

  • this was a repeat session from last year where Martin did his famous Uncle Bob Martin rant. A highlight for me was in his example he used Nigel Dalton as good code example and me as a bad code example.

Agile Manifesto: 10 years later

  • we know the approach works and we need to use it more and find the boundaries
  • XP was the dominant strain at the time – has appeal of its values and principles as well as its practices like test driven development, etc…
  • many of the original people are unhappy – the core ideas have not moved as fast as the hype (semantic diffusion) and the rollout process is very long running
  • if you say you don’t care about agile you are saying you are happy with flipping the principles back again
  • do not treat stories as one-way traffic, the value is in conversation
  • as software developers we need to ask ourselves if we are making the world a better place
  • mundane work and the little things often make the world a better place

Conference Retrospective

I led a conference retrospective after the post-conference drinks. For those who stuck around, we had a good discussion on what was good and what we could do better next year.

What Was Great

From Agile Australia 2011
From Agile Australia 2011

How Can We Improve

From Agile Australia 2011
From Agile Australia 2011

New Ideas

From Agile Australia 2011
From Agile Australia 2011

Other Stuff

There have been some other wrap-up and retrospectives written about the conference including:

Also, a couple of mentions for some of my other friends and colleagues who presented on day 2 but due to my other commitments I could not attend their sessions.

Jonathan Coleman, Steve Jenkins and Phil Abernathy all did lightning talks which were all well received.

Nicholas Muldoon from Atlassian delivered a talk called “Be The Change You Seek”, his slides are available here.

Paul King (who I have presented with many times previously) delivered a workshop called “Leveraging Emerging Technologies in Agile Teams”, his slides are available here.

Agile Australia 2011 Day 1 Review

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).