Enterprise Software Delivery (Book Review & Summary)

Enterprise Software DeliveryI recently completed reading Enterprise Software Delivery by Alan W. Brown. I read and reviewed the book for InfoQ and the following is my brief review and key notes from the book.


This is a book that sums up any large organisation with a software delivery function. It certainly matches the experiences in my last company but also matches the many case studies I have heard from my colleagues over the years.

It starts by defining enterprise software delivery, noting it uses the word delivery and not development. This is on purpose as software development is only useful when in the hands of the end-user.

The key focus areas are:

  • software supply chain and factories – a large portion of the book points to understanding the entire delivery process and understanding how to deal with distributed teams (whether they be within the organisation or partnered or near or offshore)
  • collaboration – the importance of collaboration and the use of collaborative delivery environments (CDE) and collaborative application lifecycle management (CALM)
  • agile – the importance of agile and approaches to rolling out and scaling in the enterprise
  • quality – the importance of building quality in as well as quality of the team and its relationships
  • governance – measuring your delivery and managing your team and partnerships effectively
  • future – trends that are starting to effect enterprise software delivery including cloud, multisourcing, crowdsourcing and mobile

The Agile portion of the book had me either in agreement or in a couple of cases opposition. I could understand the viewpoint of the author — for example the use of software testing factories which I think removes a lot of the collaboration that is possible with Agile testing techniques and tooling. The author is the CTO for IBM Rational in Europe and as a result a lot of IBM thinking comes through in the ideas. Whilst this is not a bad thing, it is useful to remember that the IBM approach is not the only approach.

The book has lots of case study material (mostly revolving around the financial industry and Danske Bank as well as IBM itself). There are a number of figures and illustrations throughout that demonstrate the points that the author is trying to make (like examples of metrics, processes and plans) and and these alone make the book a valuable asset for those times when you are looking for an example to get started.

This is a book that all technical leaders (including developers, architects and CIOs) should read if they are involved in software delivery in a large organisation. This was a book that I admit I struggled with a little as I read it, which I think was because I had spent so much time in a large organisation that had a continuous focus on governance, sourcing and agile. But on reflection, there were lots of ideas and trigger points throughout the book that are calls to action. Of course, for those just venturing into this domain, it is a recommended read.

Overall, this was a worthwhile read and a book that I would summarise as being very good for lots of ideas rather than a playbook that you follow from beginning to end.


Here are my key notes from the book:

  • agile “steering” leadership style – frequent course corrections based on testing, measurement, and trends in defects and cost-of-change
  • economic pressures have focused attention in enterprise software delivery organisations on cost-cutting activities, severely stretching existing delivery practices
  • CRASH Report – examined 288 deployed enterprise applications from 75 organizations (with more than 108 million lines of code) and found structural errors that on average would require an investment of more than $1 million per application to fix
  • must learn how to balance the relationship between necessary investments in enterprise software delivery and the business value these investments bring to the organisation
  • inefficiencies and misunderstandings are a major source of errors, frustration, and waste. Clear approaches to communication and coordination greatly improve the team’s performance
  • early and continuous attention to quality is essential
  • adoption of an industrialised approach places the focus on cost efficiency, reuse, and standardisation in enterprise software delivery
  • best-in-class product and services companies are those that have built a strong competency in enterprise software delivery—approaching this as a core business process. Their attention is placed on enabling innovation, lowering costs, and managing change
  • Application assembly optimization (AAO) – consist of centres of competency, technology assembly centres, collaboration and measurements and lean processes – uses work packets to deliver work (self-contained unit of work, the receiver designs, plans, and executes the work requested and measured in real-time)
  • software testing factories – particularly effective in organisations that are more complex, with numerous departments, vendors, and locations – cost-efficient and effective testing on-demand, standardised business-driven test processes, centralises test equipment, common approach to metrics and measures, centralisation of test service requests
  • important insights for an industrialised view of enterprise software delivery – new ideas needed around monitoring progress and managing status, focus measurement on broader SLA’s across vendors, transparency across the chain is critical,  choose different partners for specialist tasks and to reduce risk and increase flexibility and competition
  • an extreme version of multisourcing is the use of crowd sourcing for component delivery
  • collaboration is king – trends –  globalisation, outsourcing, faster time to market, agile, end user demands
  • organisational arrangements for collaboration – internal partnerships (many companies operate software development as a separate legal entity), supplier partnerships (strategic alignment between both parties), outsourced partnerships (formal SLA between parties)
  • global approach – reduce labour costs, skills in short demand, gain access to emerging markets
  • points of friction – “energy is lost in their execution which could otherwise be directed to more creative activities that contribute directly to the completion of the project’s mission”
  • time starvation – “typically never enough time to complete everything on an individual’s to-do list”
  • collaborative application life-cycle management (CALM) focuses on the synchronization of the entire team and the hand offs that occur across domains
  • balance delivery capabilities – time to market, productivity, process maturity and quality
  • the approach to agility – “an iterative and incremental approach performed in a highly collaborative and self-organizing manner with just the right amount of ceremony to frequently produce high quality software”
  • investment should be placed in techniques that support and encourage software to evolve – critical phase comes after first release
  • evolutionary view  – distinction between these two activities is blurred to the point that development and maintenance are just two aspects of the same need to create and deliver the system
  • agility possible when: high-bandwidth communication and coordination, decisions based on real-time information, continuous measurement and transparency into individual, team, and project progress
  • impacts on the scaling of agile – geographical distribution, compliance requirements, technical complexity, team size, enterprise discipline, organisation distribution, organisational complexity, domain complexity
  • “My experience with several large enterprise software delivery organizations suggests that agile approaches can be successful in almost every kind of development team and in almost all organizations”
  • Agile observations: 1) roles most challenged by agile approaches are Executive Managers, Product Managers, and Project Managers; 2) plan at multiple levels and adopt a “measure and steer” approach; 3) don’t use agile methods for everything, match to optimize success; 4) adapt and harden the agile process as the project gets closer to delivery
  • National Institute of Standards and Technology (NIST) – 80% of development costs are spent on identifying and correcting defects
  • almost two thirds of errors are a result of requirements and design problems, misunderstandings, and omissions, while more than 80% of error discovery occurs in acceptance testing or once the software is placed into production
  • improving quality – automating repetitive tasks, discovering more defects earlier in the life cycle, closer alignment between roles, lowering risk
  • “the quality of the enterprise software is a direct reflection of the organization’s activities, practices, skills, and morale”
  • “the evolution of the role of the software testing factory is toward a utility view of testing as a service that can be readily acquired on a pay-per-usage model or a results-based scheme” – performance and load testing, security testing, compliance testing
  • important aspects of governance – establishing chains of responsibility, authority, and communication and establishing measurement, policies, standards, and control mechanisms to enable people to carry out their roles and responsibilities
  • challenge lies in knowing which metrics are more meaningful in a specific context and how to use those metrics to change the way an organization performs it tasks – one cannot control what one cannot measure
  • a well-chosen set of metrics clarifies the goals of the organization
  • measure what you can, what you value, what drives behaviour and what optimises results
  • decisions that may be considered optimal in one area of the business (e.g., software testing) may introduce challenges in other areas (e.g., deployment management).
  • Walker Royce – analogy between enterprise software delivery and movie making – early stages of the process involve significant “scrap and rework” as part of the creative process and later in the process there must be a great deal of focus on reducing rework to eliminate inefficiencies
  • Royce’s ten management principles for agile software delivery
  • through-life capability management (TLCM) – evolutionary acquisition – each increment provides useful and supportable operational capabilities that can be developed, produced, deployed, and sustained. Major enhancements and preplanned product improvements are managed as separate increments.
  • supply chain operations reference model (SCOR) – ensure that the supply chain is operating as efficiently as possible and generating the highest level of customer satisfaction at the lowest cost
  • lean is a philosophy that seeks to eliminate waste in all aspects of a company’s production activities: human relations, vendor relations, technology, and the management of materials and inventory
  • Bell’s Law – a new platform emerges about every ten years to offer improved functionality in new areas, accompanied by lower prices for existing capabilities compared to those of the incumbent platform
  • cloud-based services are usually viewed as operational expenses because they are “leased” for the time they are needed – the switch from capital to operational expense can be very attractive from an accounting perspective
  • “you ship your organization”—the way you organize individuals and teams will undoubtedly have significant impact on the structure and effectiveness of the system delivered

Agile Australia 2009 Day 1 Review

Agile Australia '09I 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


  • 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


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

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 TalksBirth 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:

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

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