Sunday, 1 February 2015

Can Outsourcing Quality Really Be A Good Thing?

After twenty two years climbing corporate ladders I decided to go freelance back in 2006. On several occasions I have taken on a contract as a Project Quality Manager. Generally, this means working as a team member of one or more projects, helping the team, and mostly the project manager, to make sure they are following corporate standards, using good practice and generally steering them in the right direction to ensure that quality is built into the end product.

One of the contuining conversations I have with myself, is whether this kind of outsourcing is a "good thing". My accountant and bank manager would certainly say that it is. With my experience I can command a decent daily rate, and usually I'm protected from political shenanigans which means I can leave my work in the office when I leave the building. I enjoy working at the coal face, engaging with project teams, and even occasionally facilitating beneficial changes in the organisation. Above all, I always try and make a difference.

But my passion is about helping organisations improve, especially in areas which seem to have fallen out of favour as core functions within the business, like quality and process management. More and more businesses are outsourcing their quality and process activities, either to individuals like myself, or to larger outsourcing consultancies like Wipro, Accenture or Cognizant. And this causes me a great deal of concern. In fact I touched on this very dilemma back in 2011.

On numerous occasions I have sat in on Town Hall meetings where the senior management extol the importance of high quality and effective processes and in the next slide indicate that these functions are being outsourced. What sort of mixed message is that? They are basically saying "These are critically important to us but we're going to outsource them to the lowest bidder because cost savings trump everything else"!

When organisations make their quality and process specialists redundant it makes me feel that part of the organisational conscience is being ripped out. These people form a part of the glue that keeps many of the other parts of the business together. When I have been privileged enough to lead quality and improvement activities across the organisation, myself and the members of my team have been among the very few people who interacted with everyone in the business, pretty much on a daily basis. We also had strong connections with other related organisations, mainly other UK delivery centres, but with other global teams. We were uniquely positioned to help teams and individuals reach out to other people who had knowledge that could help our people.

Outsourcing these roles and functions may still ensure that core activities are performed. Contractors can undertake audits, assure compliance, identify and even lead improvement activities but as outsiders they will never be treated in the same way as genuine peers to the engineers and delivery team members. And the little bits of knowledge they accumulate, and the networks they build, will disappear out of the organisation at the end of the contract, leaving the next person to start building up those relationships all over again.

I've often commented that I believe there are two types of quality staff. There's the old style manager who hides behind dusty old standards and checklists, focusing on policing the business, and avoiding change. Then there are the proactive, modern quality leaders who drive change and improvements, strive to add value and work closely with people to help them meet and exceed their objectives. In some ways both of these are preferable to itinerant quality staff, like myself - who have probably been driven to ply their trade like modern day quality mercenaries because their traditional roles have been outsourced.

I've been very fortunate that I learnt my trade as a permanent employee, and managed to embrace all kinds of quality related disciplines on the job. I can double up as a project or programme manager, a process improvement lead, a communications manager or even an operations manager, and I can lead major business change initiatives. But some of the younger people I work with who are starting out on their first quality contracts will not be so fortunate. They won't be offered the same types of opportunities that I was, because those opportunities won't be available to externally contracted quality staff (no matter how good they are).

A dedicated, effective, value added quality service, culture and mindset takes a long time to build in an organisation. And like a reputation, it takes very little for it to be shattered beyond repair. So, if you are considering outsourcing your quality function, think again. Do you really want your reputation to go down the pan in order to save a few overhead costs?

Monday, 1 December 2014

Location, Location, Location...

I first read Peopleware by Tom De Marco and Timothy Lister not long after it was first published in 1987. I was still cutting code for a living, learning my trade (as I hope I continue to do so some 30 years later) and had little enthusiasm for going into management which appeared to do nothing except stifle my creativity.

The whole of the second section of the book is about The Office Environment. It made interesting reading to me when I first read it and it makes even more interesting reading now, largely because, in the twenty seven years since it was originally published, no-one who has anything to do with office or facilities management seems taken the blindest bit of notice of it.

Since reading Peopleware, I have worked in hundreds of offices, all over the world and in many different industries. With one or two exceptions, most office environments I have encountered have exhibit the same characteristics that De Marco and Lister described as being detrimental to productivity, especially amongst knowledge workers.

Whilst some organisations have taken steps to build collaborative workplaces and others have gone down the green and environmentally friendly spaces, many organisations continue to cram their knowledge workers into large open plan offices which are more like chicken batteries than areas to encourage the type of focus and concentration that is conducive to high productivity.

In fact, things have got progressively worse as more and more work is farmed out to low cost centres in other parts of the world and the volume of conference calls increases (in both number and noise level!). One office in London that I worked in (thankfully only once a month) was more like a school refectory than a software development hub. Space was at such a premium that workers were denied even the basic privacy proffered by a cubicle. Some 500 people shared that space, and there were three floors with exactly the same layout.

The whole nature of globalisation brings into question whether large corporations will ever be able to become genuinely lean or agile as close collaboration becomes increasingly difficult. Some of my work increasingly sees me isolated from the people I would normally expect to be closest to. On some contracts I have never met my colleagues face to face, and will probably never do so. As “shared services”, like quality, process management and even project management become outsourced, the nature of the relationships of people within projects become more complicated, less personable and more remote (literally and figuratively), and I struggle to understand how this can benefit anyone except the bean counters. 

As an introvert, who generally dislikes the notion and reality of conducting business over a telephone, I sometimes wonder how much longer I’ll be able to last in this new world, which relies far more on the ability to make yourself heard and understood over the airwaves, than the old social mechanisms of building nurturing relationships with real people, who more often than not have become genuine friends as time goes by.

Homeworking does help relieve some of the inherent problems imposed by noisy, impersonal, factory farm offices. My home environment is considerably quieter, and it’s much easier to link up with colleagues via video, which at least gives a semblance of dealing with other humans, not just disembodied voices. I have the ability to spread out, I don’t need to worry about clean desk policies, I don’t mind having meetings in the middle of the night to be able to connect with colleagues across three continents (well I don’t mind as much, as long as I’m free to organise my days around this).
But ultimately, I have real doubts about the future of businesses that continue to think of their knowledge workers as items in a warehouse, stacked high and precariously and with no real sense of connection to their neighbours.

Farmers have long known that the better they look after their livestock, the better the end product. Those same farmers also understand that although it may cost more to reach the goal, people will always pay for a premium product if they feel that they are getting value for their money. Cutting costs without continuing to provide a healthy environment for workers to thrive in is completely counter-productive, and ultimately these organisations will pay the price for their lack of understanding.  Maybe if all managers, CEOs and CFO read books like Peopleware, they might actually begin to appreciate what a lot of their employees have understood for many years!

Tuesday, 25 November 2014

The Illusion of Agile - Are You Truly Agile?

Do you work in a truly agile organisation or is it just your department, or maybe only your immediate project that is displaying agile tendencies? If you answer with either of the latter two options then you are probably nowhere near as agile as you think you are and you are almost certainly nowhere near as agile as you would like to be or have the potential to be.

I first got involved with agile development back in the mid/late 1990s. Those were the days before the Agile Manifesto (2001) and I don’t even remember using the word agile back then (except in a non-IT context).  Back then we called it Rapid Application Development, and my exposure to this type of development was through the Dynamic Systems Development Method (DSDM). But for the purposes of this post I'll use the term agile for convenience.
At that time the organisation I was working for was at something of a crossroads. Our application portfolio for credit management systems had been unassailable in market leadership term in both functionality and quality. But competitors were beginning to snap at our heels, and the user interface was starting to look jaded, and execution performance and speeds were lagging. And even more importantly the overall architecture of the portfolio was creaking so badly that many more changes would be likely to cause fractures and breaks.
Microsoft was in the final throws of releasing the first 64-bit version of Windows and object and component engineering methods had now stabilised to such an extent that they could realistically be used in a commercial environment. After some careful consideration we decided to redesign and rewrite the entire portfolio to align to the 64-bit platform, and take full advantage of OO and CBD techniques. We also made the decision to move to a rapid application development environment.

I had been put on point to define the method and processes for the new development and was then tasked to act as the project manager for an initial pilot. I was helped considerably by an external consultant who was a leading expert in this field and who was working for our tool supplier at the time. We adapted DSDM and integrated the OO and CBD into an overall development framework and took a small group of senior developers with us on the journey. We also made sure that we had the support and backing of our key business managers, and the whole team was trained appropriately according to their roles.

To cut a potentially long story short, we were not Agile. Although we successfully reduced the lead time for our pilot project from several months to three weeks, we then had something of a set-back. I had to take a couple of critical weeks off work after an accident.  During these two weeks, ourinitial timebox, the lead developer moved the goalposts by deciding to trash all the code libraries and components we had purchased and rewrite them in-house from scratch. On my return, the project was in meltdown - not a single line of code had been written to meet the business requirements, and the estimated time to complete the library code was now twice as long as we had scheduled for the entire project. It was immediately clear that I was going to be the fall guy for this cock-up so I fell on my sword and quit before I could be axed (I already felt like I'd been stabbed in the back!).

[As an aside, I put my hand up to being part of the problem as well as part of the solution. This was the first large change project I'd had responsibility for, and I knew little (nothing?) about proper process management or management of change (and nor did any of my managers and leaders!). Clearly not everyone was on board, perhaps the reasons for the change were not suitably articulated or communicated, and perhaps some people felt left out of the process, despite trying to make it as inclusive as possible. I felt abandonned and pretty hard done by at the time - but the lessons I learned were invaluable, and it turned out to be the start of a whole new direction for my career!]

At the start of the last paragraph I stated we were not Agile. We had an illusion of agility. We had an agile method and some agile tools. We most clearly did not have a shared vision of what agile meant to us, and we absolutely did not have a shared agile mindset. In hindsight I am fairly certain that the pilot would have failed even if we'd stuck to the original plan and used the bought in code and components. People had embraced the idea of doing things faster, but they didn't recognise that by doing things faster, certain other behaviours had to be left behind. For developers it was writing home grown code for everything (and being in complete control), for managers it was the comfort of status meetings and status reports and dictating the work to be done(and being in complete control), and for business owners it was the ability to be removed from the day to day development work (and having to take responsibility and accountability for making decisions on the spot).

With the power of hindsight I'm sure that sooner or later the pilot project would have got caught up in corporate bureacracy - like mandatory training, overtime bans, re-organisations, office moves and the like, because it was only a small group of people who were going agile. And there's the rub. No matter how agile you are, or even your team may be - there are likely to be a whole bunch of people who are still caught up in the bad old ways of command and control, and they will almost certainly put a spanner in your agile world. There might even be some people within your team who don't really get it, and you'll have to find ways to deal with them - but that's a matter for another post.

So, next time you ask yourself whether you are truly agile, think very carefully. Agile is different things to different people, but it is not a method or a set of tools or even a group of people who are trained in agile concepts and methods. Agile is about doing things differently, and the only way you can do things differently and succeed is by having everyone on board and on the same page. If there is a single group that impacts on your work who isn't bought into what you are trying to achieve then I don't believe that you can even begin to consider yourself truly agile.

Friday, 24 October 2014

Change Debt - No Second Chances

In the past few years ‘Technical debt’ has become a fairly hot topic. Using the description from Wikipedia, ‘Technical debt’ is a metaphor referring to the eventual consequences of poor system design, architecture or development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.'

When I was cutting code, way back in the mid 1980’s we had the problem, there just wasn’t really a name for it. And back then, we had a different way of dealing with it. I was writing programme during one of the most volatile periods of platform change – from mainframe to PC, from MS-DOS to Windows, and from stand-alone to client-server architectures. And each time the platform changed, we did a fairly significant amount of re-architecting, re-design, refactoring and rewrites.
The modern day business drivers of time to market and reduced cycle times were less important then, especially in the niche markets that I was working in. Speed of execution, features and reliability were our main drivers. In the last job where I did still write code I was tasked with improving quality and maintainability and our efforts went a  long way to protecting us from technical debt.

I haven’t written commercial code for nearly 20 years now. But having been involved in dozens of organisational change programmes, I believe they share a similar problem to ‘Technical Debt’. For want of a better expression, I’ll refer to it as ‘Change Debt’ – which we can define as the cost of failing to adequately plan a change or making hasty or ill-considered decisions when implementing change within and across an organisation.
The key difference between Technical Debt and Change Debt is that Technical Debt creeps up on you over time and ultimately engulfs you if you do nothing about it, wheras Change Debt is more like owing money to a loan shark and will probably cause you considerable harm almost immediately.
The real problem with Change Debt is that it is often irreversible. Once you've made the critical (bad) decision (or not made it) you are largely stuck with the consequences - and not only for the lifetime of your current initiative, but potentially for future initiatives.
So, when you are planning your next change programme, take a few extra moments to think carefully about what you are doing, what and whom you are going to impact, and consider the consequences of your decisions and actions from different perspectives.
You may not get a second chance!