Episode 116: The Heart of Modern Agile

The Agile Revolution Podcast

heartmodernagileCraig and Tony are sipping a sarsaparilla or two on a balcony in Brisbane and start trying to dissect the state and heart of modern agility:

View original post 92 more words

Agile 2016 Keynote: Modern Agile

InfoQAt the recent Agile 2016 conference in Atlanta, Joshua Kerievsky, CEO of Industrial Logic and author of ‘Refactoring to Patterns’ gave a thought provoking keynote around the idea of Modern Agile.

Modern Agile WheelSource: Agile 2016 Keynote: Modern Agile

Episode 109 – The Art of Agile Fluency with James Shore

The Agile Revolution Podcast

JamesShoreCraig and Tony at the Agile Australia conference sit down with James Shore, best known as for his work as author of “The Art of Agile Development” and co-creator of the Agile Fluency Model and talk about a wide range of Agile topics including:

View original post 218 more words

Jeff Patton on User Story Mapping and Product Management

JInfoQeff Patton talks about his book “User Story Mapping” and the background and approaches to the story mapping process as well as upcoming trends in relation to product management.

Jeff-PattonSource: Jeff Patton on User Story Mapping and Product Management

Episode 70: Hello Is This Thing On?

The Agile Revolution Podcast

IsThisThingOnCraig, Renee and Tony catch up again and discuss the wonderfully diverse world of Agile :

The Agile Revolution – 70  (65 minutes)

View original post

Episode 69: DevOps with Michael Nygard

The Agile Revolution Podcast

Michael NygardAt YOW 2013 in Sydney, Craig and Renee catch up with Michael Nygard and discuss the world of DevOps including:

  • Michael’s book “Release it!: Design and Deploy Production Ready Software
  • What DevOps really is
  • The values of DevOps and its relationship to the Agile Manifesto
  • Could DevOps have occurred without Agile?
  • How much of Release it is still holding well?
  • Anti-patterns in DevOps (eg. a separate DevOps group)
  • Cognitect and Closure
  • Development is production
  • Where does ITIL fit in with DevOps?
  • Why Problem Management may no longer be relevant
  • How good are we really in DevOps?

You can contact Michael on twitter at @mtnygard or at the Think Relevance Blog.

The Agile Revolution-69 (28 minutes)

View original post

Episode 58: Don’t Drink and Podcast!

The Agile Revolution Podcast

Beer CheersCraig and Renee are in Sydney and dangerously podcast after Renee’s one (1) drink and Craig’s two (2) drinks. Along the way they fumble over the following topics:

View original post 147 more words

Episode 49: Merry Manifesto Madness with Alistair Cockburn

The Agile Revolution Podcast

AlistairCockburnCraig and Renee lob around to Tony’ abode to interview his house guest, Alistair Cockburn. Alistair spends time:

  • denying a K Stew affair
  • answering what brings him to Australia
  • plugging his fantastic Advanced Agile Course
  • presenting his thoughts on where Agile is going
  • answering how the Agile Manifesto has shifted and whether the last line should be shifted earlier
  • talking about the simplicity principle
  • explaining the difficulty of Agile Organisational transformations
  • answering whether transformation that succeed better can be big-bang or have to evolve
  • discussing the sticky middle management layer where transformations become hard
  • ponderings on what is happening in the ICAgile space
  • generally taking the p*ss out of Renee, Tony and Craig

You can contact Alistair Cockburn for any work opportunities or Advanced Agile Training on totheralistair@gmail.com or totheralistair@aol.com.

You can contact Renee for any work opportunities or Agile 101 Training at renee@theagilerevolution.com.

Special thanks…

View original post 10 more words

Agile 2011 Day 1 Review

Agile 2011It was great enthusiasm that I set off to Salt Lake City last month for Agile 2011. In the lead up I was a reviewer on two stages (Testing & Quality Assurance and Working with Customers), plus I was lucky enough (and apparently the only submitter) to have all three of my original submissions accepted (although conference rules, for good reason, restrict speakers to two sessions). Whilst its a been a month since the conference (I took some time afterwards to spend time on both the east and west coast of the USA), I wanted to ensure that I posted my notes.

Here are the notes from the sessions that I attended on day one.

The Product Partnership: Using Structured Conversations to Deliver Value

Mary Gorman and Ellen Gottesdiener led this tutorial. They started by taking about requirements by collaboration and leading a discussion on things that hinder and help.

From Agile2011

Things that hinder: access to the right people, thinking about the solution rather than what needs to be done, multitasking, people not listening, customer not clear of needs, backlog too big, stories too big, missing product owner

From Agile2011

Things that help: centralised repository, short backlog, story maps, clear business goals, UI mockups part of the story, clear priorities, crisp acceptance criteria

From Agile2011

To set the stage we need:

  • a sponsor, product owner / champion, customer, technology
  • a shared understanding of vision, much like an infinity loop we: discover –> prepare –> deliver
From Agile2011
From Agile2011

They then went on to speak about value:

  • conflicting voices for value – not just from the customer but technology value, we need to listen to all the voices
  • evaluate requirements – value, risk (such as technology risk, team risk, outsourcing risk) and dependencies (dependent on other teams or external vendors and requirements and dependencies where value violates the way we would like to build the system)
  • benefit – IRACIS (increase revenue, avoid cost, improve service) needs to be balanced with cost, time and delivery
  • table stakes – the things we must deliver to stay in business
  • differentiators – point of difference in the marketplace
  • up sell revenue potential
  • foundation for long term savings
  • provides revenue for future
  • frequency of use
  • automate labour intensive tasks
  • no viable manual workaround
  • reduces pain for end-users
From Agile2011

This led to a discussion about backlog:

  • we want to build the most valuable things first
  • two states – credible (it has some kind of value) or buildable (it has been prepared and is sliced, groomed or right size as well as understood well enough to estimate, test and document)
  • incorporate UX into preparation, collaborated workshops
  • slice for value – starts with a glean in someone’s eye, then it gets bigger because we have a bunch of options, so we need to fit based on value to contract the list
From Agile2011

And finally onto requirements:

  • product provides value to users – who will receive value from the product
  • what actions need to be performed – what are set options
  • what is the data (noun) and the type and state of data
  • what are the constraints – policies or controls that need to adhered to, business rules

The example for this tutorial was getting to the Agile 2011 conference. We first ask the question: what do we value.

From Agile2011
    • customer value – convenient parking, staying in conference hotel, cheap flights, etc…
    • business value – people stay at conference hotel, one stop shopping on the website to save aggravation for Agile Alliance as well as attendees
    • user roles – travel explorer – individual attendees (speakers, sponsors, volunteers, attendees) and corporate travel agencies for group travel
From Agile2011
    • actions – hotel information, distance to the venue from home, distance from other hotels
From Agile2011
    • data – link to hotel (official hotel plus local hotels), Salt Lake City information
From Agile2011
    • control options – the business rules, such as when you need register by, etc…
From Agile2011
So we start with the requirement:
I need to: register
User role
  Type options: member*, non-member, group, academic
  State options: active*, inactive
From Agile2011

Then the actions:

Action options
  learn
  pay
  confirm
  communicate
  cancel / transfer
From Agile2011

Then the data:

Data: Fee
  Type options: regular, early bird, super early bird
  State options: available, sold out
Data: Payment
  Type options: credit cards, payment order, check
  State options: paid, pending, not paid

We may also visualize this as a data model or a state diagram

From Agile2011

We then need to look at the business rules and prioritise them.

From Agile2011

Once this is complete we can now we slice for value and write a story. This needs to be the silver bullet / tracer bullet, then you can break down from there. At this point you can write the stories and throw the sheets away. This all leads to:

As a... I need... so I (value)

Requirements leads to examples which leads to tests. We can now link this to given when then:

 Given: pre-condition (state), fixed data
 When: action, business rules, input data
 Then: output data, post condition (state)

It is recommend that you come to these workshops with some pre-planning but be under the agreement that they are draft and often wrong. These could be release or iteration planning workshops.

Now the forgotten heroes, the non-functional requirements:

    • design and implementation constraints – the givens, the parts of your technical infrastructure that are dictated or restricted – worth pausing and discussing if there are any options
From Agile2011
    • interfaces – human, other systems and device interfaces such as messages (you could use a context diagram to illustrate this) – with the diagram you can start discussing the options / choices / possibilities
From Agile2011
    • quality attributes – things like speed, stability, uptime, security, scalability, usability, extensibility, etc…, need to be testable and SMART (specific, measurable, attainable, realistic, time-based) – eg. recover from user error in x clicks, x time
From Agile2011

You can do this at the big view (business process, features, MMF, scenarios), pre-view (user stories, user story maps where you lay out stories left to right, scenarios) or the now view (buildable, scenarios). The granularity will change.

From Agile2011

Plans in an array matrix – the anchor is the action dimension

From Agile2011

Need to have a structured conversation to communicate effectively. Face to face is the most effective and get a shared understanding of the highest value.

Overall, this was an enjoyable session. I really liked the templates for mapping out the requirements (despite the fact that these were essentially just aids for the workshop) as they helped focus the conversation and gave our group something to focus on. Mary and Ellen are currently writing a book based around this content, so I look forward to seeing that in the future.

Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership

Christopher Avery (creator of the Leadership Gift and author of The Early Admissions Game: Joining the Elite, which apparently is 10 years old and still in print) led this extremely packed session, the essence is contained in this publication available here (as well as here).

From Agile2011

We started the workshop by competing in a spaghetti challenge (based on the Marshmallow Challenge) which consisted of the materials of just 10 pieces of spaghetti and a  line of tape. The team I was working with constructed a tower of 35 inches, which ended up being the second tallest in the room.

From Agile2011

There is a pattern in our mind that kicks in every time something goes wrong – creates angst and anxiety – responsibility process – a descriptive model:

  • QUIT – the pressure of responsibility and obligation can lead us to quit, an avoidance move, a lack of completion, active disengagement
  • RESPONSIBILITY – call yourself on obligation so you start looking for solutions – start saying “I get to go to this stupid meeting”, means you have a choice – we were taught that doing stuff we have to do makes us responsible
  • OBLIGATION – I have to go to his stupid meeting have to but don’t want to – leads to resentment
  • SHAME – how could I do this, how could I be so stupid – laying blame on self – premise is the problem, you can’t learn
  • JUSTIFY – it was raining, I dropped my keys – story makes it just – “that’s just the way it is around here…”
  • LAY BLAME – who took my keys? – not a solving position of mind
  • DENIAL

3 keys – descriptive model

  • INTENTION – wanting to get something done, get to RESPONSIBILITY around every problem in your life
  • AWARENESS – be aware of which level you are in
  • CONFRONT – ability to face, taking yourself to the edge of your comfort zone, comfort zone = current capability, confront = expanding capability – every person you know was once a stranger

Example coping mechanisms are: learn to live with it, it worked on my machine, they just don’t get it, it’s the vendors fault, it’s too hard, you’ve been here long enough to know that’s not going to happen, murphys law, we did exactly what they asked for, …

We then did a “Be With” exercise, which was essentially sitting knee to knee with the person next to you, in complete silence,  for 30 seconds, to feel the others anxiety. Ultimately, it’s not the other person that makes you feel bad, it is yourself.

Confront is the angst of confronting yourself. If you want to change something you need to poke it, and observe the change.

Accountability Responsibility:

  • accountability is the number one tool of management – it’s the way we manage commitments between two parties – its outside of us because it is us and someone else
  • responsibility is about how we respond – internal to us, and different for all of us
  • what people are signed up for is greater than what they are responsible for
  • what people are responsible for is greater than what they are accountable for <– We want to be here
  • they are both equal

Where’s the bottleneck?

  • what if you had to reproduce the code, if you had the same team and resources?
  • what percentage would be more efficient the second time?
  • modal is 70%. You would be better because you have solved the problem before. Learning takes time. Essence of agility is to learn and take feedback.

There is lots of feedback in agile practices such as retrospectives, showcases, standups, etc… If you are not going to do anything about it, stop investing in the feedback loop. The fastest way to learn is to take ownership.

Fastest way to elevate responsibility in a group is demonstrate it yourself. If you are saying people around you are not displaying responsibility, then you are just laying blame.

Exercise coaching responsibility. The responsibility process only works when it is self applied! You need to teach it so others can self apply it. Counter not being good enough yet to teach this yet:

  1. Give yourself forgiveness, forgive yourself for being human
  2. Teach this with a light tone. Make yourself the brunt of all the jokes that are below the line
  3. Don’t go into agreement (“but I do have to go into that stupid meeting”) – don’t confuse the facts with the mental position – take time, breathe, count 10 seconds and answer – validates they raised a good question and allows you to respond – ask if you can push back on them a little bit, and ask them to identify where they are on the chart
  4. Make sure you support – need to forgive yourself, let go and move onto a better future

Taking responsibility is owning your power and ability to create, choose and attract.

Responsibility is the design space. What do we want from this? Be clear with what you want and be clear about the consequences. Responsibility gives you power but also potential consequences.

There is a difference between choosing something and avoiding something.

As a coach you get to intervene in situations, so you need to act from a position of responsibility and check where you are coming from (move through the model as quick as you can). Ask yourself if your message is clear and does not sound like blame.

Advice is seldom effective so stop giving advice. You are transferring responsibility from them to you. If it doesn’t work they perceive it as being your fault. Instead:

  1. Resist giving advice. Tell me what you have tried, tell me what you haven’t tried
  2. If you must give advice, give three alternatives so they have to choose, putting responsibility on them. “If I were in your shoes I might consider a…, b…, c… What do you think about those?” One coaching company advises 10 alternatives, so you really think about the responsibility.

Finally, play the “Catch Sinner” game to learn the process:

  • make a score card
  • choose a word for today
  • make 2 columns – “get off of it” and “it got out”
  • throughout the day, everytime you catch yourself in a position of “blame” mark your chart
  • 10 points for the left and 1 point for the right column
  • build tremendous awareness for each word at least for one day

There are a bunch of resources at Christopher’s website, in particular he encouraged us to get a copy of the teaching poster and empowered us to teach the process to our peers.

Overall, I really enjoyed this session, as I had heard good reports from this session when it was help in 2009, and this year it was listed as one of the most popular sessions. The responsibility process is something I would really like to work on personally.

The Agile Manifesto 10th Anniversary Reunion: The Big Park Bench

This was one of the highlights of the conference where 15 of the 17 original authors of the Agile Manifesto got together on a big park bench to discuss the writing of the manifesto.

From Agile2011

There were heaps for great stories but here are some of the snippets I took away:

  • started with XP Immersion
  • at the XP Leadership meeting, rejected idea of creating a group
  • Bob Martin and Martin Fowler sketched out an idea for the Lightweight Methods conference
  • Jim Highsmith noted that there us nothing about it that he would change and would not get back together with these people to do it!
  • Ward Cunningham would change the colour balance of the background image
  • Brian Marick noted that individuals and interactions can often be a beat up for people who appreciate tools
  • Jim Highsmith commented when asked about the next 10 years that agilists don’t predict!
  • they never expected that something written in a couple of afternoons would be this big
  • Brian Marick recalled that the stated objective of the meeting was a manifesto and it seemed miraculous that they left with a good framework . Bob Martin was just surprised that he has been to one meeting that worked!
  • Martin Fowler did not want to call it agile, he wanted a wackier name
  • Agile Manifesto nailed it as a baseline – they might have added “we really mean it” or “we are not kidding”!
  • when you gel with a team you get what can be summed up in 3 words: high quality work
  • great teams change people lives. “The manifesto changed our lives, and probably yours too”
  • many people who may have survived under waterfall may not survive much longer under agile, as it is flushing out bad practices
  • other potential names for agile were: adaptive, hummingbird, lean (used already), PPP, a bunch of acronyms, did not want a word they would have to wear pink tights and a tutu to explain!
  • Agile was a coincidence – people following lean in the 1990’s were saying agile is the future, which was good because agile has a meaning in the business world
  • the most argued item on the manifesto – iteration timeframe, executes terminology
  • the principles were harder to arrive at
  • biggest disappointment – everyone wants to be agile but too few people want to do it (when they wrote it they really meant it), the scrumbut
  • biggest success – uses outside of software (for example Pragmatic Programmer publishing), wanted teams to be able work freely in a way they wanted to work
  • need a revolution in middle management and need a similar framework for agility
  • Agile is not the “not-waterfall” – it’s about teams and delivering software
  • Agile stands as a beacon of hope, for it to disappear would mean the evil empire has won
  • in software, we still need to ask how do we do a better job?
  • an Agile process of inspect and adapt is what makes lean companies great
  • Jim Highsmith particularly called out Jeff Smith, the CEO of Suncorp Business Services as being someone who got promoted from CIO to CEO through the success of Agile
  • consider lean inside the same heritage as agile
From Agile2011
From Agile2011
From Agile2011

A reunion site has been setup in conjunction with this event.

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 1 of the conference.

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.