On Friday 29th November, I attended the annual Agile Tour in Sydney. Agile Tour is a non-profit conference run by Agile practitioners for those practitioners already involved in Agile delivery or for those who simply want to know more. The tour has taken place in Sydney just two other times with the day or concept of the day structured around actively participating and sharing in each other’s experiences. Most sessions are designed to be practical and interactive whilst sharing skills and experience in agile adoption, project delivery, agile teamwork and agile development practices. As quoted on the web site:
‘This conference is NOT about self-congratulation and happy ending fairy tales but rather the sharing of warts-and-all failures, hard-fought successes, and practical activities to help you address your real-world challenges.’
For more info on each of the sessions, go to: http://lanyrd.com/2013/agiletoursyd13/schedule/
The open space concept for me was absolute brilliance! Anyone in the room could pick up a blank card, write any topic or question on the card and that would denote the discussion theme/subject. They’d set up roughly 7 stations where these discussions could take place at the same time so at any point you felt you couldn’t contribute or you just felt like you weren’t gaining much out of the discussion you could easily hop around and join another one.
The other highlight was the range and breadth of people, which I got to meet. I got up close and personal with teams from Commonwealth Bank, CPA, SBS, SunCorp, some ex Thoughtworks managers and even some digital agencies as well.
I think overall the day was well though out, the sessions weren’t too long so as to lose the audience so the whole day was really well balanced.
Now I was determined not to write an essay so I apologise in advance but commend you for getting this far into my review. Below is a more detailed summary of each session I attended. It contains my own personal learnings as well details of books and resources that were recommended by the practitioners. Please note, the below notes are again my own personal views on topics covered and should be used as consideration points in your own practices.
Surfing impossible projects with Agile
This session was by far my favourite. The instructor who led the session was energised, sarcastic, knowledgable, insightful and engaging! The session started out by defining the different problem categories, those of which are and can be defined as:
- Simple – Easy to solve (Formulaic)
- Complex – Resists solving (Systematic – Assumes that the problem and solution can be mapped out
- Wicked – Resists defining. This is where every time you ask a question the problem seems to keep changing or the problem domain seems to grow. Wicked problems are when emotions can be involved. It is ambiguity that fuels wicked problems. There can be too many unknowns.
Complex problems can still be solved in a waterfall way however it can also be done better using Agile for its adaptable properties. What is the main reason why you ask? Well statistically requirements age at 2% a month. Agile looks at complex problems not to solve them but to achieve ‘better’.
An example of a wicked problem used in the session was that of a crying baby. You can burp the baby, you can feed the baby, you can give the baby a dummy but will it stop crying? Yes it may … but other times it may not. How do you know what the root cause of the problem is? … You don’t know as it changes every time, this is a wicked problem indeed! But if you take a look back at the different methods for making this baby stop crying … ask yourself, what have you just tried? You’ve tried several different options and you’ve gauged feedback. You’ve trialled … reviewed … gained feedback – sounding familiar? Yes it rings true to very much the agile methodology. You couldn’t do waterfall with a wicked problem.
“Wicked problems can’t be solved, they can only be made better or worse.”
Team building exercise that can be used in an agile team when working on Complex or Wicked problems:
- Ask the team members to write down their annoyances about a project on separate post it notes
- Separate a wall out into ‘In our control’ and ‘Out of our control’
- Ask the team members to place their post it notes on the relevant wall
The key to the above exercise is to set aside and not dwell on those issues that are out of your control. Being agile and adaptable means let’s worry about and deal with that situation when required. For now let’s focus on the milestone set ahead and any issues concerning achievement of it.
“We are born to do wicked … We are trained to do complex”.
- There’s this
- “Litte Bets: How Breaththrough Ideas Emerge from Small Discoveries” by Peter Sims – Book on agile –
Purpose and positivity – 2 factors for leadership development
This session in my opinion had perhaps too much content that they tried to squeeze into the one hour time slot. It was also a little difficult to follow as the topics the instructor covered were all quite conceptual however some key points I gathered:
- Leadership is shown through change – anyone can be a leader
- Factors of positivity – elements to practice within your own teams
- Collective leadership
- Information sharing
- Meaningful work (hierarchical goals)
How can the above be used in Agile? Run solution focused retrospectives. Use the CIGAR method:
C – What’s the Current situation?
I – What’s the Ideal
G – Are there any Gaps?
A – derive any Actions
R – Review
- Transformational Leadership – The 5 ‘I’ model
- Developing as a leader – The 4 factor model
- This presentation can be found on prezi.com under “Lachlan Heasman”
Battling Confirmation Bias
When brainstorming or facilitating problem identification with business and technical teams it’s important to encourage open dialogue and acknowledge different solutions. Use visuals where possible to keep everyone focused on the same topic or idea and it is essential to outline the sessions’ goals up front.
What happens when technical needs conflict with business needs you ask? Never draw to any conclusions right up front, delay making any decisions, get out all of the assumptions and then start to tear away the different layers by identifying what the trade offs and must haves are for both audiences. Arm yourself with the following:
When arguing points of view the court system can assist us with this – take the below for example:
- The “Defence” always plays on the jury’s emotions whereas the “Prosecutor” is always basing their arguments on facts.
Now the below diagram will be familiar to all of us – very agile in approach:
But before following the above the following outside circle must be known and trialed first:
Stay tuned for the next installment of my day at the annual Agile tour in Sydney. It was a great day and I cannot wait to share some more learnings later.