offshoringFor many years we have been indoctrinated to believe that ‘outsourcing’ and ‘offshoring’ are good for us:

  • It provides access to cheaper and equally qualified resources;
  • It reduces the cost of delivery thus resulting in lower total cost of ownership and better financial bottom line for the company;
  • It is easier to ramp up and ramp down;
  • It increases human resourced flexibility;
  • It allow a company to focus on its core business processes while shifting non-core business functionality to external companies;
  • It allows a company to tap into a vast international knowledge base;
  • It allows a company to gain access to the type of resources it could not get access to internally or locally;
  • It allows the company to mitigate the risk of its development or operational activities to an external agent;

What the chief architects of this approach failed to mention is that what they meant in ‘GOOD’ is not necessarily good for the company’s shareholders, not necessarily good for the employees, not necessarily good for the national economy but rather GOOD to a collection of stakeholders who’s bonuses and KPI’s are linked to the perceived savings these outsourcing and offshoring arrangements are meant to deliver.

Many large Australian corporations have outsourced large chunks of their IT assets to offshore companies. This resulted in an interesting phenomenon where a substantial number of offshore resources have actually relocated to Australia and, in the process, made a large number of local IT resources either completely unemployable or employable but at a substantially reduced rates.

The system of bringing offshore resources to work onshore if fraught with unexplained anomalies:

  1. Bringing overseas resources (on a temporary work visa) to take on local work is traditionally done in cases where there is shortage in locally available qualified resources;
  2. Usually this type of work will be for a prescribed short period of time to allow the local market to ‘produce’ the resources locally.

In the case of the Australian IT market it would be fair to say that while the decision to outsource was initially based on the desire to benefit from the points outlined above, it resulted in bringing offshore resource to onshore, thus resulting in a much bigger impact on the local market than what one would expect as a result of an outsourcing / offshoring agreement.

It is debatable whether outsourcing / offshoring actually results in the benefits outlined above. My experience does not allow me to make a verdict on this matter one way or another. And in any case, validating the benefits of outsourcing require a level of financial scrutiny that most companies will not make available publicly.

There is a policy issue that does require addressing. The official publication outlining the Temporary Work Visa in Australia stipulates the following:

The Temporary Work (Skilled) visa (subclass 457) allows skilled workers to come to Aust​ralia and work for an approved business for up to four years.

You must be sponsored by an approved business. A business can sponsor someone for this visa if they cannot find an Australian citizen or permanent resident to do the skilled work.

In the case of the IT industry in Australia it is hard to see how any business could justify the sponsoring of offshore resources to come and work in Australia based on the scarcity of local IT resources. Not only is this a nonsensical proposition it is a complete fabrication and an outright lie.

I am far from propagating conspiracy theories but the fact that federal and state governments are sitting idle and refrain from supporting the local workforce being directly impacted by the on-shoring drive is puzzling, to say the least.

So, if the on-shoring arrangement is approved, despite the fact that it blatantly breaks the rules established to control its use, it can only be because someone is benefiting from it. Clearly it is not the local workforce. It is hard also to see what benefit the Government can derive from it as, quite clearly, it contributes negatively to the local employment levels. So, presumably, the only beneficiaries from this arrangements are the industries and corporations that use it extensively.

So here’s the question to the Australian government. Does the increased dividend to certain shareholders in certain industries make it worthwhile to the national economy as a result of the constant squeezing of the local IT employment market?

Has the time not come to re-evaluate our lenient position regarding the issuing of temporary work visas in professions where there is clearly no shortage of local, qualified and experienced, workforce?

Think about it!



Having been ‘doing’ both Waterfall and Agile for quite some time now I feel fairly qualified to point out the idiosyncrasies in both approaches. None of these approaches is completely wrong, and equally, none of these approaches is completely right. It all depends on the circumstances, the organizational maturity, attitude, culture and inclination.

So, while I have had my fair share of frustrations with pure command-and-control organizations, my beef today is with Agile advocates that are exhibiting less than agile attitude when attempting to bring Agile into large command-and-control environments.

The scenario I’m referring to is as follows:

An organization with long and established ‘Waterfall’ methodology and way of working is convinced to give Agile a go. The Agile practice is getting momentum in certain quarters of the organization and the Agile portfolio is steadily growing. While it is growing in absolute numbers, in relative terms it is still but a small percentage of the overall development effort managed throughout the organization. Furthermore, crucial support services, like Release Management, Production Support, Infrastructure deployment, Enterprise Architecture, Enterprise Testing, and others are not yet fully integrated into the “Agile way of working” and are still operating with what would, traditionally, be referred to as Waterfall.

The reality in such circumstances is that while the software development aspect of the project/program can utilize Agile methods, the project in its entirety is still bound to interface with non Agile delivery teams, operating with a different cadence, different milestones, and different operational requirements.

For Agile professionals, such an environment is an ongoing challenge. It requires them to accept that being adaptive also means being able to operate within a Waterfall set of constraints. Integrating Agile into a Waterfall, command-and-control organization is not a nuisance, it is not a hindrance, it is not an anomaly, it is just the way things are.

Clearly, “operating” Agile in a fully ‘Agile-committed’ organization is relatively straight forward but many organisations are not yet adapted to allow for Agile practices to flow through the organisation structure, and in such cases, being insistent of doing ‘pure’ agile is not just childish but also unproductive at all levels. Attempting to force Agility down an organization is not being able to accept the fact that agile does not operate in an organizational vacuum. As an agile professional you need to remember that it is not the ideology that is important but rather the ability of the organization to reap the benefits of its technology investments.

Think about it!


In case you’re in Melbourne early September and happen to attend the Australian PMI Conference don’t forget to look me up. I will be presenting a session on “Transform yourself from traditional to Agile project manager”.

Here’s my submitted abstract:

For many ‘traditional’ project managers the encounter with agile and agility is a confrontational one. While many project managers have been trained in the art of project management based on a set of governance principles grounded in command-and-control related management techniques; managing projects in the 21st Century is developing in an environment in which agility, collaboration, exploration and adaptation are the key. This session will highlight the key issues facing project managers wishing to engage in this transition, explore the key dimensions – behavioural, conceptual and psychological – associated with this transformational change and provide a road map and a range of helpful tips for a successful incorporation of agile principles into any mode of project management, irrespective of the environment in which it will be executed.

I am hoping that by the end of the session the participants will:
1. Understand the conceptual differences between traditional project management methodologies and agile management principles
2. Be equipped with a set of tips for the incorporation of Lean and Agile principles, values and techniques in your project management activities – irrespective of the type of project management methodology you use for your projects.
3. Have a better understanding of Agile project management terminology.

Let me know if you’re going to attend and please come and introduce yourself.

I come across many people that call themselves ‘coaches’.

I come across ‘coaches’ that certainly ‘talk the talk’ but have no real experience to back that up.

And here’s my dilemma:

Should I take such coaches seriously?

Can one become a coach by knowing the domain (as opposed to ‘doing’ in the domain)?

Am I just too damn closed minded?

Think about it!

29. July 2014 · 9 comments · Categories: Agile


Like many things in life, Retrospective – as a concept – can have many layers of abstraction.

At the superficial level it can be used to identify symptoms and find ways dealing with them.

At a deeper level it can be used to highlight symptoms and attempt a rudimentary root-cause-analysis and possible experiments to address them.

At a fundamental level it can be used to highlight symptoms, explore their causes and explore the attitudes and motivations that need changing in order to better address such occurrences in the future.

If I understand this correctly, deeper retrospection and reflection require the investment of higher levels of cognitive effort. This investment, though, is likely to result in longer term benefits (compared with lower levels of retrospections).

While I can ‘see’ the benefits individuals can gain from exercising higher levels of retrospection, as they can gain better insights into themselves, their attitudes and their behaviours; I am not clear on the benefits to the organization. Are there clear, tangible, measurable benefits that would make the extra investment – in coaching and guiding teams to achieve this level – justifiable? I am still looking for the evidence.

Think about it.

25. July 2014 · Write a comment · Categories: Agile

The four weeks or so that have now passes since the Agile 2014 Conference in Melbourne have given me the opportunity to reflect on the conference and consider some of the presentations and messages I have been exposed to.

While the theme of the conference was Embracing Disruption, and while a number of the key note presentations were about Business Disruption, there was little in terms of providing hands-on, practical, implementable clues or ideas for ‘how to elicit disruption’. It is widely accepted that Agile is a vehicle for disruption. While this was certainly true in the earlier days, when Agile had to make its case and increase its market penetration, this is no longer (at least not so explicitly) the case. The level of disruption ascribed to Agile in the earlier days is no longer sufficient to refer to Agile as a disruptive force. We now need new ideas as what used to be disruptive yesterday is today’s norm.

There were two presentations, out of the one’s I’ve attended, that I believe fit the bill. One was the talk titled “Holacracy at Zappos – how do you manage to deliver value when ‘anything goes’?” by Geoff Apps, Director of Engineering at Zappos; and the other titled “Making sense of complexity by designing dynamic environments: The Lens” by Daryl Chan and Martin Kearns.

The idea behind Holacracy is ground breaking. Whether one takes this concept as a positive or negative approach to organizational structure (and associated roles and responsibilities), most will agree that this is a disruptive idea. It takes the idea of ‘self-managed teams’ one step forward and turns if from a small scale, agile development team approach to an enterprise wide adoption.

The Lens concept is about taking the adaptive nature of Agile and turning it into an enterprise level tool. It takes the Kanban Wall concept one (giant) step forward by incorporating into a visual wall the data and information where all employees (at ALL levels) can obtain and share insights regarding the overall scope of the organization’s operations.

To keep Agile relevant, to keep Agile vibrant, we need to focus on this level of discourse where Agile practitioners are encouraged to remain disruptive well beyond the known boundaries originally created for this disruption.

Think about it.

Just finished reading David and Goliath: Underdogs, Misfits, and the Art of Battling Giants (note: affiliated link) by Malcolm Gladwell.

The key premise of the book is that things are not what they seem to be. More specifically, using a number of real life examples, it demonstrates how situations they seem to be advantageous are really (in some circumstances) an indication of disadvantage and similarly, situations where the odds seem to be stacked against the main character result in a favorite outcome.

The book also questions the notion that bigger challenges require a stronger response (such as the natural tendency to apply more and stronger policing in situations where there is an apparent increase in crime) and introduces the notion of the U Curve, suggesting that doing more of something results in positive results, but only up to a point. Doing more of that thing after that point could result in negative consequences. The concept is easy to understand and to apply. For example, communicating with project stakeholders can result in tangible benefits as stakeholders are comfortable that the project is adequately managed. More communication could also be beneficial, but up to a point. If you swamp them with too much or too frequent information you will likely lose their good will and their attention. Just an example.

Think about it!


18. July 2014 · 4 comments · Categories: Agile

The Agile story, at some levels is a rosy one. A Manifesto that stipulates a set of values, a collection of principles that underpins these values and teams of people of different skills working together in collaboration and harmony to deliver value in the most efficient and lean way.

Behind the scenes however, organizational politics, power games and internal manoeuvring have the motive and the opportunity to use some of these values and principles in a manner not intended for originally.

Take for example the following principle:

We welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage.

On the surface, and taking this statement at face value, this is a deceleration aimed at celebrating the flexibility and adaptability of agile teams to the ever-present changing requirements. Being able to change direction and support the business in a changing landscape is one of the areas where Agile and Lean provide better value for money. This, however, assumes that people are playing it fair and this, I suspect, is a big assumption to make. If there is anything we’ve learned from behavioural economics is the fact that what you see is not necessarily what you get. Put differently, people’s behaviour is seldom rational and even when it is, one person’s rationale will not be the same as the next person, even when they shout the same slogans.

The agile principle of adapting to changing requirements can therefore be used as a pretext for pretentious commitment to a certain scope with a hidden agenda to water down that scope citing ‘being agile’ (i.e. being adaptive to changing circumstances) as the reason for that subsequent (and pre-meditated) change. This is a level of gaming the system that is often hidden from the team members and is played by competing sponsors and stakeholders. Not wanting to be seen to be lacking in support to a certain idea they provide a lip service with no intention to seeing this going through to a completion.

So what does it really mean:

At the practical level it doesn’t mean much. Sponsors and stakeholders have always had the capacity to disturb (or enhance – depending on your view point) project direction. Agile, nevertheless, provide such behaviours with a ‘get out of jail’ card. It provides a level of legitimacy that now turns such attitude into a perceived win, a perceived ‘good behaviour’. Lack of commitment could be seen by the wider community as a sign of intense agility and adaptability – clearly not in the spirit of the agile intent.

Think about it!

%d bloggers like this: