I must admit, I turned up to the inaugural Agile Australia conference with no idea what to expect, but a good range of Australian speakers (including myself!), keynote speakers and a healthy number of attendees, the conference exceeded my expectations.

There were a number of sessions I would have liked to attend that clashed with those I attended, such as Shane Hastie on Agile Transitions (presentation and video) and Julian Boot and Marina Chiovetti and their talk Show Me The Money Honey.

The sessions I attended on day 1 were as follows:

Panel – The Journey Towards The Agile Enterprise

This was the kickoff panel featuring Beverley Head (BH) (Journalist), Nigel Dalton (ND) (Lonely Planet), John Sullivan (JS) (Sensis) and Katy Rowett (KR) (Suncorp). My key takeaway was the acknowledgment that you need the right people (“the bus”) and the retaliation that the journey continues.

• BH – agile is “in your face computing”
• journey not for the faint hearted

Why did you begin on a journey to the agile enterprise?

• ND – major event of waterfall failure, so much so the owners sold the company, could actually sell them on “anything but waterfall”
• KR – Suncorp started with one mans vision as part of synergy savings of merger of Suncorp and Promina, needed to do something different in IT to meet the timelines
• JS – changes taking to long to get into the market place

Productivity?

• KR – has not been an easy road to success, still a way to go, social change in the way people are being asked to collaborate and work, productivity initially took a dip as they learnt a new way of working
• JS – agile breaks the barriers, but the types of people you want to do this with are not the people that you started the journey with (essentially you are starting the  journey with the  wrong people on the bus), last time on a panel he controversially said “sack their arses”  but nicely that means  “move them to a different bus”, its all about moving people from punch in and punch out to giving people a career
• ND – thank god for big banks and Sensis who took the people who were failing at Lonely Planet!, some people are not great at working in this environment

Business embracement?

• JS – whole company has to go for the journey, from the person who organises desks to the people who put the walls up, didn’t follow the agile books and got IT into the business (not relying on people coming to them), need to understand the business
• KR – relationship is crucial, luckily the relationship was already there as it allowed to take first step with blind faith, worked less well where this was not there, ramming agile word down their throat, need business to steer solution and IT will bring intellect to the table, when business see something they can make sense of they are along for the journey, prioritisation and politics an issue for a large organisation
• ND – prediction – in two years time the theme of conference will be product management in an agile way, had huge failure with seagull product managers

Skunkworks approach to agile?

• KR – not in Suncorp, was the way before Jeff Smith came along and then he tipped the boat over, Jeff Smith is a visionary who surrounds himself with people who have passion and energy
• is agile a generational thing for the next age gap of CIO’s?
• JS – in two years time we will be talking about how to do data warehousing in agile, the tools support doing web-based front-end applications very well, need to support back end process and get the developers to signup to the principles and practices such as automated testing

Legacy?

• KR – agile is whole of system approach, Suncorp has lots of legacy, extends to mainframe, web and product support and maintenance

There were then some questions for the panel.

Introverts vs extroverts, we would like to bring as many people on the bus, how do you bring the introverts along?

• ND – as an introvert, have learnt one or two practices to move from introvert to a mile-high extrovert, introduced “the red button” to identify issues, agile is a massive opportunity to learn IT and networking skills and has flattened the team out so everybody gets their say, more respect than traditional teams
• KR – there is always something that motivates somebody or pushes their buttons, this is contagious in agile teams, in the Melbourne office you could originally hear a pin drop but now you can’t hear yourself talk

Jim Highsmith says you get the customer happier, faster?

• JS – under promise and over deliver, builds trust
• KR – business wanted a Lamborghini but as the system was being built they were happy with the Commodore, then really happy when they got the extra feature!

What do you do with skilled developers who do not want to fit the mould?

• JS – building a team, these people are disruptive to the team, you end up getting rid of them anyway, have to identify that while these people are brilliant they are counter-productive, spend way too much effort trying to harness it or find them something in the skunkworks
• ND – have tried to put them on a spike, but in the end you still wish you could have paired so other people know what is going on, agile is doing extraordinary things with ordinary people

Finally, the wrap up!

How long does it take?

• KR – joruney never stops, Suncorp has been doing it for 2 years, have a baseline of success and failures (which are deemed as successes), currently assessing where we are and how we can be better
• ND – two years with BBC ownership who are big on agile, as they have matured the have realised it is a learning, how you learn is the killer outcome of agile
• JS – three years, originally got up and running in 8 weeks after throwing a big bucket of money at it (rather than taking the journey), went from 12 people to 60 people in a 4 week window

What has it done for the business?

• ND – for R&D, who believes that the agile cult is the barrier to high speed innovation, his response is prove it
• KR – Suncorps new CEO Patrick Snowball said BT is our biggest asset and our goldmine
• JS – it’s bloody expensive!

Keynote – 12 Agile Adoption Failure Modes

Jean Tabaka (from Rally Software and author of Collaboration Explained) delivered the keynote, the slides are available here.

• roadblocks to agile success – think about growth, business wants results straight away, but we don’t pay attention on what it takes to do it, hence we get failure

Benefits you’ll derive:

• stop denial that waterfall is actually delivering
• put on reality goggles – this is the truth of it and agile will help us get there
• seek out insight pools, will allow more collaboration
• create your own reality – core value at Rally, can help individuals which then moves throughout the organisation
• all of these together deliver customer value

Checkbook commitment failures:

• CEO/CIO level, have a problem and agile will solve it
• unengaged – “just do it”
• looking for immediate results
• have not commited to organisational change that is required
• same metrics – everybody still reporting the same way up and down, continues the illusion that software development is deterministic

Culture that does not support change failures:

• everybody expected to follow a plan, how well are we doing on a plan we created a year ago?
• they enforce standard of work to ensure we get to the plan (governance = conformance), standard of work static, everybody works the same way
• success mode to ask each team what the best practices are rather than declaring them up front
• belief that more documentation will enforce standard of work – need to create knowledge creating companies, rather than declare standards across the organisation, tacit knowledge creates implict knowledge which in turn creates tacit knowledge
• PMO as enforcer in failure mode, should act as broker for knowledge

Ineffective use of retrospectives failure:

• what are we doing well, what’s not serving us as a team, what can we change to improve?
• if you want to fail, don’t do any at all
• retrospectives ignored, team gives lots of ideas but facilitator explains why none of them are correct
• no action on retrospectives

Ignore needed infrastructure failure:

• no sustainable or stable environment
• TANSTAAFL – There Ain’t No Such Thing As A Free Lunch – need to be able to have the money to invest into the infrastructure, leads to dangerous practices
• need to be desperate for tooling for testing, CI

Lack of full planning participation failure:

• act collaborative and want insights, but save money and get a few people to do it who are well meaning – means teams are not committed to tasks and estimates – how can we march to the plan?
• waiting for decisions – waste – if we do not have the  right people in room we cannot make decisions in an expedient amount of time, lean is about eliminating waste
• osmotic conversation – creates better commitments and better plans which means better insights – learn from all of the skillsets about how we can measure ourselves against the plan
• commitment – have run planning sessions with 100 people, a 2 day event, people thanked at the end for being involved

Unavailable product owner failure:

• not available when trying to go faster
• too many product owners
• agile asks a lot of product owners – usually they are too busy to do the communicating, will suggest that agile is too hard to get engaged in
• need them engaged to agree on priorities
• when they are engaged they are commiting with the team, want product owner at standup asking where are we with the commitment and how can I help?

Bad scrum masters failure:

• want somebody facilitative, not dictatorial playing the scrum master, does not need to be a master of the domain but a master of the process
• do not have role of command and control – hard for existing project managers
• command and control lowers morale and lowers IQ – when kids ask you what you did at work today, tell them you lowered peoples IQ’s!
• serve and facilitate rather than command and control – need to be Superman and help you raise your IQ
• need someone who serves and facilitates and removes impediments – cleans up mess, is committed to help team meet their commitments

Not having an onsite envangelist failure:

• if distributed, need one in each location, otherwise team do not believe anybody cares about them, this leads to remote roadkill (on your own and if you get run over by a truck that is your problem)
• can’t reap the benefits if you leave them on their own
• need to advise, motivate, protect and serve – bring in their insights rather than pushing insights on them, help them be successful

Team lacking authority failure:

• don’t empower team and leave them to deal with the red tape (difference between Toyota in Japan to the USA, western culture less successful at empowering teams)
• TED Talks – Birth of the Computer, Motivations
• motivation – understand how teams work, takes work to be a high peforming team (first form the team, invite conflict into the team, converge insights, then you hopefully get a norming team who just get things done)
• empowered team amplify learnings – individuals to organisation and back again
• inspect and adapt to get better at delivering – high performing can speed up and continue to deliver

Testing not pulled forward failure:

• do not invest in infrastructure, do not believe necessary, do not have the appetite (do testing in subsequent iterations or do one iteration for planning, one for code and one for testing)
• need to look at capacity utilisation, agile optimises the process, some people think it looks like wasted utilisation but what we do is create more defects when we are pushed to 100% capacity
• piled up technical debt if coders coding at 100% capacity in an iteration, slows down ability to deliver
• need to stop the line, don’t emphasise 100% capacity but emphasise quality (when you find a defect stop), Toyota showed this at a GM plant, fired everybody then hired them back by changing the measurement of success from number of cars to the defect level, first day made 2 cars! but ended up doubling the output of the plan

Managers yearly expectations failure:

• eliminate performance appraisals – get in the way, evaluate teams working together, do not reward individual heroics
• teams evaluate each other, called 360’s at Rally
• how did you bring level of skillet of this team up? – reward team contribution

Reverting to form failure:

• change is hard, but at least we understand waterfall!
• Kathy Sierra created a chart showing the suck threshold through to the kicking ass threshold

The wrap up:

• call to action – pick one of these, hold a self retrospective in 30 days
• when do you give up? – if teams not getting there after 6 months, Mike Cohn will just say “you can’t do agile so just give up” – after 6 months look at failure modes and run a retrospective, need to be prepared for a 2 year journey up the organisation to scale and mature
• ensure balance of tech lead and scrum master – hired to be the brightest guy on the team, need to decide that you want to get smarter by increasing the IQ of the room, move from how smart I am vs look how smart team the is – see Good To Great (Level 5 leader takes ego and turns it to look how good team is)

7 Habits Of Highly Effective Agile Developers

Steve Hayes presented this talk, the slides are available here. My key takeaway was the idea of the emotional bank account (and the build story!).

• hard to build effective teams from ineffective individuals
• individuals always know the answers to why projects are going wrong, but don’t always speak up
• developing effective individuals required for agile success
• showed Dan Pink at TED – use of financial incentives – mismatch between what science knows and what business does, Atlassian Fedex days to Google 20% time to CultureRX ROWE (Results Only Working Environment)

• management may not be natural but leadership is – need to engender trust and faith
• talk based on Stephen Covey – 7 Habits of Highly Effective People
• be proactive – take responsibility for own life, don’t lay blame, many organisations use reactive language (eg. I have to do this), proactive people trying to increase circle of influence
• begin with the end in mind – need vision on what you are trying to achieve before you can achieve it, create your own mission statement (personally and organisationally), does my mission statement match my teams mission statement (am I in the right place?)
• put first things first – urgent and important, most underused word in professional life is no (what would you like me to not do?), delegate (go’fer delegation and stewardship delegation), self management and self supervision is hard but agile demands it to work effectively
• emotional bank account – make deposits and withdrawals, too many withdrawals and you will go into overdraft, understand the individual, meet commitments, make apologies for withdrawals, etc..
• if you aim for win/win, you need to be prepared to walk away if you cannot win
• seek first to understand, then to be understood – Indian talking stick (don’t give up the stick until you feel you have been understood, understood if people can repeat your position and you can answer yes), use your opposition as input to your position or as an option you have not considered
• sharpening the saw – need time to recover production capability

Finally, Steve told the story about standing on the desk and shouting at the developers at Lonely Planet about the red build light, which was a great story and repeated throughout the conference. The only reason he could do this was because he had the build credit in the account first.

People Driven Agile Transformation

John Sullivan from Sensis delivered this talk, the slides are available here. My key takeaway was the acknowledgement of the importance of people and technology in a successful agile rollout.

• started in May 2006, hand picked a new team and formed a company (Majitek), then rolled out across 80-150 people across Sensis
• have developers that are really good architects that can cut code
• agile manifesto – it’s all about people not about the methodology, the agile luminaries would have definitely prioritised the list
• assess thresholds – organisational change – will always be thwarted, companies focussed on a threat will not have the appetite as you need people to learn new things, tried to introduce pair programming at a bank but the union thwarted it because everybody needed a corner desk, etc…, currently at Sensis have a big battle about where to put story cards (because board members walk passed and thought they looked unslightly)
• assess thresholds – people change – too many people in IT punch in and punch out, can change people but it takes time that most companies can’t stomach, might need to move people out, want to challenge people to do better tomorrow, most people don’t want to learn something new because it makes them anxious
• assess threholds – technology change – change the architecture to get people interested (eg. introduced Ruby On Rails to give an option to hire interesting and good people)
• movements need committed people – need to get people on the bus, where are you today and where do you need to go and why, ask people to write down what they would like to be as an industry luminary, need to make people understand why we need to do this, once you have buy in you need to action very quickly and slam people with actions
• technology – most agile teams favour XP practices (they are common sense), use the threshold to decide what tools to use (Ruby on Rails is all hype, get professionals to pair, throttle back on some of the cutting edge technologies that consultancies try to sell you on), simplified architecture (rule that all applications had to go onto an application server – why??)
• lease the process before you own it – get the right team of experts in to establish experts, learn from them and get them out as soon as possible
• build relationships – IT people like screens, go to the business, don’t make them come to you, talk to them in their language
• can trust an agile advocate as much as you can trust a real estate salesman – need to learn from failures, build trust, IT willing to sell success but mask failure, Dr. Jeckyll and Mr Hyde (front up whether good or bad), take the how out of estimates, just write down what outcome you want to achieve and how much it will cost, agile can be overstated (does not make risks disappear but it highlights them and lets you fix them), you could do an agile and waterfall project in the same time (you will just get the features you want to Production sooner), physically more expensive to do agile but the outcome is better
• don’t care about process, need the right people to do the right job
• agile does not sit well with people who want to coast – Sensis is competing with Google!, it is not a job it’s a career, most organisations are setup incorrectly
• want master craftsman, inspire people to do better every day
• worked out ways of influencing change, could not change everything so worked out ways to work around the roadblocks
• don’t use term agile anymore, originally was a fascinator, now it is all about self improve

Taking The Leap Of Faith

Mike Allen from Racing and Wagering Western Australia (RWWA) gave this talk, slides are available here. My key takeaway was the sotry about how their investment in agile allowed them to replace 15 year old legacy totaliser machines in 5 iterations.

• RWWA – mainframe shop – hard to get developers, licencing costs high, time to market too long
• educate on agile – had to dispell myths – no design (do it all the time, more than waterfall, every iteration), no planning (plan everyday)
• establish a tempo – 3-6 month releases, have showcase at the end of release
• plan at the right level – has a Gantt chart, can tell you that on 15 March next year that developer “James” will be doing development, which is all you need to know!
• hire the right people – biggest secret to agile success, need open people, want to be challenged, not possessive or obsessive about code, cap the hours at 40 hours per week, have external activities, most people at RWWA contractors, agile is infectious
• create the right environment – spent $175K and ripped the existing building infrastructure apart, smaller desks, greater density, lots of wall space (hide nothing, transparent about everything)
• start producing software – start to see functionality grow week by week the way the customer wants
• Mike’s Balls – variant of a burn down chart – demonstrate scope vs progression, different colours for different teams, can see where progess is being made
• don’t fight everyone – big organisations sometimes want to use tools that cost lots of money
• deliver high quality software – quality should be immutable, zero defects (means for the time we spend testing the system we will fix those bugs), replaced 15 year software at TAB in 10 weeks (5 iterations), RWAA have been good at giving the customer and empowering them to make decisions
• produce good documentation – produce right at the end, a DVD player comes with technical guide and technical specifications, written at the end, long running documentation should be produced at the end, tossing the requirements out after the project is done is still a battle
• have some fun too – a good agile project should be about fun

Some questions at the end:

• scope, how much will it cost? – captured a card for each functional area (too high to estimate), then broke down to smaller cards and got development estimates in developer days, then add up and apply a sophisticated formula (multiple by 2 to allow for testing and BA resources!)

Better Software Faster

Michael Milewski from Realestate.com.au delivered this talk, the slides are available here. My key takeaway was the change of technology to attract quality people.

• originally a LAMP stack with Perl
• requirements hell – high cyclomatic complexity, tool 9 months to choose a colour picker!
• top down approval for agile rollout plus bottom up readiness
• pair programming – did coding dojo (tight time frame 6 minutes per pair at 1 station), learn new skills
• Perl to Ruby and vi to IDE – Ruby has more buzz which attracts better people and energizes people
• BDD – Business Analysts and Test Analysts own the stories in this way, CI (confident it works), BA’s understand the behaviour
• iterative development – transparency when running a showcase
• track progress – with pen and paper, can walk up and see what is going on
• retrospectives – small issues are visible, clears the air
• project delivered, happy business, strategic success to core website
• failures – one big release (not small releases), when iterations have failed (hard to celebrate, but have to realise you have failed fast), still trying to determine how to deal with product management (still fall back to waterfall practices)

Atlassian VIP Tour

I skipped the last two sessions to take the opportunity to tour the Atlassian offices with Nick Muldoon and JC Huet. The work environment was incredibly impressive and it was great to talk to some of the developers of Jira directly and its future along with GreenHopper sounds exciting.  Oh yeah, they’re hiring as well!

ThoughtWorks Open Office

Most of the conference headed on over to the ThoughtWorks Sydney office for drinks and conversation. Plus myself, Rene Maslen, Tammy White and James Couzens won the agile trivia competition!