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

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

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

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
  • 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

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
  • – 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

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.