Recently I noted several large businesses announcing proudly they had adopted Agile development techniques – for example Suncorp, NBN Co, Allianz, Jemena.
There is a pattern to the adoption of a new methodology within an organisation. I have lived through the adoption of a number of new methodologies over the years at various companies, for example: Six Sigma, Total Quality Management, Lean, Capability Maturity Model, and Balanced Scorecard (to name a few).
Like many corporates adopting a new idea I suspect that these four companies are in the honeymoon phase. They are still getting managers used to the ideas, training staff in the new processes. And the critical things for success will be:
- consistency of management support,
- consistency of practice, and
- consistency of internal reward systems.
Without these three kinds of consistency the adoption of the new methodology is a real challenge. Most importantly the internal reward systems – not just remuneration, but also promotion and recognition – need to be recalibrated to support and endorse the new methodology.
To effectively support Agile development (or Agile adoption in any other part of the business) it is necessary to change some of the cherished management tools and practices that date from the days of Taylorism.
Agile means doing something that seems counter-intuitive. It means accepting the uncertainty which is inherent in so many business activities. It also means working with that uncertainty to create change and build value based on the social nature of business and the creative process. It also means that we shift away from long-term highly-structured and well-documented plans and towards smaller chunks of work. Thus certainty is achieved in small focus deliverables and there is an ability to quickly adapt to new business needs and requirements.
At about the same time I saw the news about these four companies I also discovered a wonderful summary of the challenges we often face in adopting agile in an enterprise context in the form of the Manifesto for Half-Arsed Agile Software Development. This sums up the situation facing organisations that want to adopt Agile practices successfully.
Quite a few years ago I uninstalled Norton AntiVirus in complete disgust as it slowed my PC down to the point where it was almost as bad as having an actual virus.
But recently, while chatting to some of guys from Symantec, they assured me that they had seen the error of their ways & that their new product, Norton 360, had a nice light footprint. Perhaps I even snorted in disbelief – but even so, they sent me a copy to test.
I installed Norton 360 on 12 July and have had it running since. I do not even notice it is there unless it pops up to give a warning. I’ve even been moved to tweet about how much this amazes me (especially given the crappy-ness of the old version a few years ago). At first the warnings popped up a lot, but once the settings were re-tuned all was well.
Strangely enough, it seems that the folks at Norton have actually done what they claim. It has a light footprint, is easy to use and it runs as well as or slightly better than my previous security product (Nod32).
Behind the scenes is all the detailed tracking information about intrusion attempts and updates that a pro would want. But all the complexity is nicely abstracted and hidden from the average user. A few other neat features also included in addition to security are:
- identity protection
- PC scan
From the average user’s perspective these other features of Norton 360 can make managing a PC a much easier job. The bad news for the family geek is that I can see that the task of setting all of this up will probably still fall upon their shoulders.
I’m still exploring the capabilities of the identity protection & will post about that later. Just about to run my first backup and will let you know if it beats Carbonite (my incumbent provider).
Up until now I’ve been using Nod32 as it had a lighter footprint that most of the other anti-virus products around. But based on this experience to date Norton 360 is well and truly back on the list, especially for non-geek users.
This amusing cartoon by Geek and Poke captures one of the important reasons why so much of our planned software reuse fails. Thus projects often fail to achieve the economy of scale benefits from the business case.
Within companies there is often little trust between departments and an unwillingness to rely upon things that other people have built.
The real question is how can we overcome this problem so as to achieve the benefits of shared resources and reuse?
The first step in resolving the problem for any organisation is recognition that this kind of problem exists. The next step is to bring the issue out into the open.
Often there are war stories within the business that explain how or why the lack of trust has evolved. It is important to uncover these reasons. Once things are out in the open they can be managed.
My rule of thumb for problems with technology projects is that about 70% of the problems are in our heads (us being all the people involved in the project), while the other 30% of problems are logistical (e.g. stuff takes longer to do than planned; or stuff gets delivered late).
Very rarely are the problems actually about the technology in and of itself. More often the problems that appear to be technical result from hidden issues with people that remain un-addressed, or architectural problems that lead to the selection of inappropriate hardware or software.
By Carruthers via Aide-mémoire