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!




Tuesday, 26 August 2014

Bring Purpose and Value Back to Project Reviews

In the past 30 years I’ve attended hundreds upon hundreds of project status reviews in various capacities - sometimes as the project manager (‘victim’), more often as a general stakeholder (‘muzzled bystander’) and on a few occasions as a review lead (‘master inquisitor’). I can’t honestly remember a single instance where the review has actually proved directly useful to anyone involved. I’d go as far as to suggest that the best project status reviews were the ones that got cancelled, thereby freeing up time to do something useful instead.

But, before going any further, let’s just clarify what I mean by a project status review. I’m talking about the regular management reviews which usually take place at the month end, after the (usually equally useless) project status report has been sent out. These reviews, scheduled months in advance, generally consist of a bunch of managers and stakeholders who ask lightweight questions about the project status. Often these are the same issues that have been addressed in the project status report but which they haven’t got around to reading yet, and usually they are the same questions they asked the previous month. In the worst scenarios, the project manager must endure a series of review boards in which increasingly senior managers ask the same questions expecting some miraculous transformation of project status during the course of the review period. Some hope!

Project managers adopt different strategies to deal with the project status review. Some come armed with spreadsheets and projections and try and bluff their way through with numbers. Others overwhelm the audience by pointing fingers and blaming the suppliers, the customer, the government and anyone else in the hope of shifting attention away from themselves. Yet others simply talk, and talk, and talk in a brazen attempt to use up the allocated review time without actually revealing anything at all.

And generally the members of the review board nod and mutter and occasionally proffer words of encouragement or caution or huff and puff about the situation, but rarely take any action. It’s all part of the game. And it’s all a waste of time and energy.

Don’t think that I’m advocating that all reviews are a waste of time - only the ones that take place because “that’s what managers do”, “that’s what the process dictates”, or for whatever other forgotten or misunderstood reason. If scheduled reviews are the established norm then review leaders and participants should at least be encouraged to ask useful and more demanding questions.

This is especially true with improvement or change programmes where project costs and schedules may appear to be on-target in terms of creating deliverables, but the real hard work - actually embedding the change and winning over hearts and minds may be a million miles off the mark. For these types of projects the review leader should consider not only including the improvement programme manager but also representatives from the target organisation who are most affected by the change. Questions and discussions should be formulated around the human impacts of the change, not purely the technical and physical aspects of the project.

I’ve worked with several organisations where the focus of reviews was always on the tangible aspects of the project - the process descriptions and other work products. Projects that appeared healthy were in fact at risk because elements like the readiness of the organisation to embrace the change, how communications were being received, and expected levels of resistance to change were never being probed.

Here are a few of the more challenging questions that a review leader could be asking of their project managers to get a better steer on the reality of a project status rather than relying on a verbal rehash of the status report.
  • What has become clear since last we met? And less obvious?
  • What is the area that, if you made an improvement, would give you and others the greatest return on time, effort, and dollars invested? 
  • What is currently impossible to do that, if it were possible, would change everything? 
  • What are you trying to make happen in the next month, two months and three months? 
  • What's the most important decision you're facing? What's keeping you from making it? How can I help?
  • What topic are you hoping I won't bring up? 
  • What area under your responsibility are you most satisfied with? Least satisfied with? 
  • What part of your responsibilities are you avoiding right now? 
  • What one thing that I can do as your manager would most help this project?
Think about you the last review you participated in, and ask yourself how useful it was, how much value it added, and how you could improve the experience and outcomes for yourself, the project under review and the other participants. And then do it!