A Dilemma Regarding Defect Tracking

In my previous post I harked back to the good old days when I wrote code for a living and used to pride myself that I could pretty much guarantee that there would be very few bugs in my production code. This was a good thing for the organisations I worked in because we really didn't have a process model for software development. Most people in those organisations had never heard of development models and the software groups tended to be structured around  functional roles - analysts and designers, who handed huge specs to programmers, who delivered completed systems to testers. There weren't even any real project managers - the role was shared between the lead analyst and a business/product manager.

So producing relatively defect free code was good because we didn't have defect tracking systems. We had lists of defects that came from the testing departments which programmers then had to track back to their own work and fix the issue long after it was initially created.

Since then defect tracking and management systems have proliferated and maintenance crews mop up the bugs long after they were created by someone else. Defect prioritisation meetings soak up stakeholders time and product release cycles stay the same regardless of the advances of technology and the power of new hardware and software tools.

No wonder that defect management is regarded by the lean community as waste, and why new techniques have been developed to better integrate the development functions and activities to find and fix defects as they are created rather than at the end of the development cycle.

As a software engineer, process person, and business improvement guy, I heartily approve of this and wish that more organisations could understand what a difference it could make to their release cycles and the overall quality of their products.

But as a user I find myself with a dilemma, primarily with big organisations who are responsible for product portfolios of millions of lines of code. I'm thinking in particular of the operating systems and hardware providers like Apple and Microsoft, where it's clearly impossible to test for every eventuality.

I'm reminded of the legend about Rolls-Royce when they built motor cars in the UK and owned the brand name for their cars. The story was that if your Rolls broke down you would have to ring a secret number and a service engineer would arrive on the scene with a spare car and take yours away, in a covered truck, to be repaired before returning it back to you. Rolls-Royces simply didn't break down and to prove it, you never saw one by the side of the road or being towed away.

Companies like Apple don't acknowledge bugs in their systems very often. If they do it's usually buried in the release of an update, and stated in very high level terms, like "fixes an issue with wireless networks and wake-up". I'm certain that Apple employs sophisticated defect tracking and management systems but as a user I don't know whether my specific problem is a known bug, a personal issue because of my system configuration, or a previously undiscovered problem. I can search the support forums and I can send feedback to Apple but these never get officially acknowledged, and many of the forums are populated by the blind leading the blind.

It would be so useful if Apple, like many smaller companies already do, could publicly provide a list of known issues, along with official work arounds where they exist. It would save us consumers hours of time trying to understand whether we can fix something or not. It would save hours of Genius Bar and Apple Support time and costs. And it would make Apple look better as their current system makes them look like they don't care.

As a developer I don't want defect lists. As a consumer I'm desperate to see them!

 

A Message to the New Breed of Software Developers

With the advent of the "App" and their associated distribution stores (Mac, iPhone, Android etc.)  the act of developing software has never been more popular or more accessible. The opportunity to create the next "Angry Birds" in your bedroom or living room and become an overnight millionaire is clearly very enticing to many individuals.

Before I became involved in Quality and Process Management, and long before I became a consultant I earned my living as a software engineer. I use the term advisedly - I wasn't just a programmer; I was a systems designer, architect, tester, requirements engineer, configuration manager and I learnt my trade over the course of many years from some great and passionate people.

I was driven by simplicity, elegance and efficiency in both design and code. But mostly I was driven by a desire to be a brilliant engineer with acute attention to detail, and a self motivated need to write as near perfect code as possible. It helped that in those days we were constrained by both hardware and software limitations. Compliers were command lines driven, terse and unforgiving, and IDEs were few on the ground. Memory and disk space was grossly expensive and processors were slow. A build that today might take a minute or two would take half a day, so silly mistakes were costly and time consuming. Most people, including myself coded away from the machine, only committing when we had desk checked everything to iron out as many problems as possible. All these things led to the disciplines of efficiency and care that we learnt back then.

Today, computer resources are plentiful and cheap. Software development tools are powerful and much easier to use. The constraints we suffered are resigned to our memories and computer museums. The only constraints that haven't changed are time and money which are clearly still in short supply in all commercial development shops.

But despite these advances in technology those quaint old values that I shared with my colleagues, my mentors and mentees, should still be forefront in every developer's mind. Cutting corners is not acceptable. Shipping products that fail is not acceptable. Thinking of your customer simply as a cash cow is not acceptable.

I use mobile devices for many activities during the course of the day - some critical for business and some which are critical for my relaxation. I expect these devices to work without having to reboot them during the course of the day (as I do with my laptop and desktop machines). Far too many apps crash my devices and memory management is often diabolical. New versions of software reintroduce old bugs suggesting that no proper version control is in place.

I think it's great that people have the ability, imagination, enthusiasm,  capacity and desire to create software and there are a number of apps I use regularly on both my iOS devices and Macs which are a pleasure and delight to use. These are often sourced from those one person outfits whose desire to create great software outweighs the desire to get rich quick. They also tend to be great at supporting problems and always willing to go the extra mile to help fix things when they occasionally go astray. These people understand that they have a responsibility to focus on the details and to get things as right as possible as often as possible.

So my message to all developers, commercial and freelance, whether part of a team or solo artists, is simple. Please reassess your values and your methods next time you start to work on a piece of code or a new design. The best processes in the world are worthless if you - as an individual developer - fail to actually give a toss about what you are responsible for, and fail to give true consideration to your customers and their basic needs and requirements.

Maybe Process Management Isn't Enough

For the past five or six years I've been evangelising about moving from a Process Improvement culture to one of Process Management. I've written about it in these blogs, I've spoken about it at conferences, and I've tried to encourage and promote the adoption of the concepts and principles in the workplace. I generally find my arguments are well accepted:

• Process Improvement activities tend to be short term, project based endeavours which peak in the run up to an appraisal or audit and then fizzle out
• Improvement teams spend much of their time recreating processes in their own image rather than building on existing processes to actually improve them
• Process improvement activities are often top down and more aligned to compliance than aimed at the generation of added business value
• We think in terms of Quality Management which encompasses planning and control, assurance, compliance and improvement, but only talk about process improvement

So when I talk about Process Management I'm thinking about a truly operational activity which is a defined and managed function that works holistically across the business and is aimed at generating improved business performance at all levels.

But I'm now having my doubts about whether this goes far enough, and reading a post earlier this week has encouraged me to write this entry. Chris Taylor published an article on BPM For Real entitled "Has process lost its meaning?"

Now I don't necessarily agree with Chris' views in this particular instance (although I totally agree about that fact that management speak and jargon has completed clouded our use of vocabulary and have written about that before!) he said enough to make me step back and think about my experiences over the past few years.

• Some organisations simply did not have effective processes in place which was preventing them from achieving the levels of performance they could have expected from their people
• Many organisations wasted their "improvement dollars" fixing perceived issues rather than genuine failures, often because they believed their process experts rather than listening to the process users
• Too many managers simply didn't understand what they were really doing and initiated improvement activities aimed at doing the wrong things better
• Lots of teams were involved in Continuous Tinkering rather than focused improvements
• Business value was not being realised because it wasn't even part of the dialogue for consideration
• Arbitrary quality targets were set and improvement activities were channelled into meeting these
• Reactive quality compliance had higher management priority than proactive prevention of future quality issues

Some of these are genuine process issues which could be addressed by more rigorous process management. But fixing some of these problems requires more than new or improved processes. They need better understanding of business and management realities than many managers have. They need better trained and educated managers. They need process experts who have a better understanding of core business activities and values and who operate in the real world of the people who execute the processes (commonly called workers!).

My biggest problem is that I don't have a convenient label for what this discipline really is. It could be Performance Management, but that's already been hijacked by HR in the guise of personnel reviews. In the old days, it could have come under the moniker of Quality Management, but that's been hijacked by Testing and the compliance police.

Maybe I should just invent a word - Proformance perhaps. It's got a big red line under it as I'm writing this, so it doesn't appear to exist yet. Yes, I like that...

Business Proformance Management - the act of ensuring the right things are being done properly across an organisation, with the aim of improving business value and outcomes for all stakeholders including the people doing the work.

I shall reflect on this further and let you know how I get on. I'd welcome your thoughts on Proformance Management.

.

Acting Under Pressure - Free Thinking or Conditioning

I've been having some pretty restless nights since I came back from Switzerland and last night was no exception. I woke up at 04:45 clutching at some snippets of a rather bizarre dream, but sadly wasn't conscious enough to jot them down. The gist of it was that I was in a war zone with some close friends from both work and personal life and I was questioning some of the decisions that were being taken, both tactical and strategic.

In those immediate moments after waking I realised that I had been thinking about was the difference between doing the right things and doing things right (regardless of whether they were the right things to do). As I rubbed the sleep out of my eyes, my mind started darting around all over the place. I started thinking about Verification and Validation process areas in CMMI (as you do!); I thought about jobs I had left because I had had tried to do what I thought was the right thing whilst all around me people were doing what they'd always done and still failing; and I thought about all the projects I've been involved in which might have succeeded if leaders had focused on doing the right things rather than doing the wrong things righter. It's sad to say that far too many of us have worked in organisations and projects that have resembled war zones and how much of our office language reflects conflict, with our war rooms, death marches, and battle plans.

Finally I started wondering how much of our behaviour changes when we're under pressure and we start to behave according to our genetic ancestry (fight and flight) or our social or workplace conditioning (command and control in most cases). I even wondered whether there is a genetic disposition that make some people behave like leaders and others act like sheep, particularly when the going gets tough.

Many of you will have seen coverage of the terrible events in Italy this week involving the cruse ship Costa Concordia. We'd all like to think that if we ever found ourselves in such a situation that we'd behave with dignity and calmness and make sure that we did the right thing in that context. The tragedy is that when we're faced with the reality of such a disaster, very few people live up to their ideals. It's much easier to do what you're told (rightly or wrongly) and to follow the majority. To do something that goes against the grain, to think differently, to take a different course of action that might go against all common sense is much harder.

But in an organisational context or a project context the pressures that we are up against are not life threatening. We not only have the opportunity to think or react differently to everyone else - we have an obligation to do so. And managers and leaders have an equal obligation to listen and make decisions accordingly based on analysis of what is being said and not against received wisdom or ingrained ideals of what is right.

Projects and organisations fail most often because they allow themselves to be persuaded by convention without thinking about the real consequences. Far too many decisions drive the types of behaviour which lead to people focusing on doing the wrong things, and trying to get better at doing them rather than simply doing the right thing because it's different.

UPDATE : Just before I went to post this entry I discovered someone else thinking similar thoughts today as I saw this on my Twitter feed...

flowchainsenseiAlways, always the toughest decision I have to make as a coach; whether to behave as management expects OR to coach teams effectively.

I fully empathise with this dilemma. In the end my heart usually rules my head and after towing the line for a while I'll edge towards trying to do what's right. Sometimes I'll end up paying the price, but at least my conscience is clear, and there are always some folk around who thank me for trying!
.