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.

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!

 

 

 

 

 

 

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!

Unifying Technical Project Management with Management of Change

One of the things that successful leaders of improvement initiatives understand is that at least 80% of the effort is about managing change. It is often something that their sponsors and supervisors also understand.

So, when you pick up a book about process improvement, you’ll generally find extensive information about understanding the psychology of change, managing resistance, winning hearts and minds and communication, and all the other ‘soft’ skills that will help you succeed. You probably won’t find a huge amount of information about writing a process. (If you think about any of the CMMI reference books there are very few pages about creating a process, although to be fair you won’t find many pages about managing change either, so maybe that’s a bad example!).

In PRINCE2 a project is “a temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case”. According to PRINCE2, projects are the means by which we introduce change into an organisation. But, pick up a book on PRINCE2 project management and you’ll hardly ever find anything about managing change, other than standard scope and change request management. What you’ll usually find are all the specific technical details about project planning, monitoring and control.

If you are creating a new product or even introducing a new off-the-shelf solution within an organisation there is a significant element of change. People will probably have to adapt their way of working. They will need to understand how the new solution integrates with existing systems and processes. They will have to understand the new expectations being forced on them through the change.

Yet, in my experience, this element of the work is rarely considered as anything other than an afterthought, and technical project managers who lead these projects are often lacking the skills required to successfully implement the change. They may deliver the product, sometimes within budget and time constraints, sometimes not, but they don’t deliver an integrated and working solution to the original problem.

The result is that staff now need to spend a considerable amount of their time trying to adapt to the change without the necessary understanding, guidance, processes and tools or even the context for why the change has occurred in the first place.

When organisations begin to understand that technical project management alone cannot meet the requirements of delivering a working solution to a problem, and learn that the end users who are closest to the work are the ultimate stakeholders, projects will continue to fail to deliver against the expectations initially set for them.

Businesses need to follow the patterns set up by change practitioners whereby technical project management skills and management of change skills are interwoven throughout the project management process, and not simply bolted on when it is already too late, or worse, ignored completely.