Being a consultant I get to see many different types of companies, there are those that already use Agile practices and want to know if there is any way to improve on their existing process? Then there are the companies that have heard about these “New Fangled” ways of producing software and want to know how to get started.
Finally there are those that know something is wrong as they are losing money, delivering late and poor quality applications. The managers at this third type of company decide it is time for a consultant, and more often than not stick a pin in the phone book (or Google), and somebody like myself gets a call.
One thing that links these final types of company together is they invariably have a “Headless Chicken Button”. This device is normally situated under one or several of the managers desks, right where it will get hit by a knee jerk reaction to a piece of news about a project.
In most cases this button is also integrated into the email system and will open up a new message addressed to all members of the development team with a template of a message that goes something along the lines of “It has been brought to my attention that XYZ has happened. We need to arrange an urgent meeting to discuss how we can put processes in place to make sure XYZ never happens again.”
More often than not this “Urgent Meeting” never actually happens, and eventually developers just ignore these messages. If the meeting does happen then invariably the only thing that gets decided is that Management would like more metrics to better manage what is happening within the project, more ToDo lists or tasks need to be generated and tracked so management can see what is “really” going on. All this is really doing is producing a Princess and the Pea situation. Fingers are waved at developers and they are told to work better and produce bug-free code.
Once the meeting is concluded the developers will start generating the agreed on metrics, adding tasks, emailing summaries etc. to Managers that now that they feel they have done their “managing” don’t actually take note of or even read. No processes that actually help the team to produce better software have been put in place, or even discussed. All that has actually happened is the team now actually has more friction in their workflow and less time to actually work on the project. Within a month or so the developers realise that the managers aren’t reading or take note of the new information they are providing and things peter out and end up back the way they used to be.
Is any of this sounding familiar?
Let me give you an example of this in action:
I was consulting for a firm that consisted of as many managers as it did developers, which was the first sign of trouble. However, in the course of the first few weeks that I was there, there were three separate instances of the “Headless Chicken Button” being pressed.
The first was when a developer was away from the office and a bug was raised against a new release of a website that he had been working on individually. His manager felt he didn’t know what the exact status of the project was, so was worried that the project may slip if this was a major issue, which is a fair and valid point. The manager, however, didn’t like the issue tracking system that was being used so wouldn’t/couldn’t attempt to see what effect, if any, this bug would have, or even what the status of the project was. The changes to the processes that ensued consisted of the developers having to copy and paste their tasks from the issue tracking system into tasks in Outlook to make it easier for the managers to see what was going on.
The second incident was roughly along the same lines, this time though the meeting never happened. Despite this, an email was sent to all developers which now required that as well as keeping the lists in Outlook synchronized with the tasks in the issue tracking system, a meeting would be held every Monday where each developer had to print out a copy of their tasks from Outlook to then tell the manager what they were.
The final “Chicken” incident resulted in the developers, in addition to the Outlook tasks, and the meeting to read out the tasks, now having to copy the tasks into an email after every meeting and email them to the manager they had just met with, who could already view the exact same tasks in their Outlook.
This is maybe an extreme example, but it happens to a greater or lesser degree in a lot of the companies I see.
There are issues with both the management team and the development team, and they are normally along the following lines:
The management team are not really software people, some may have just fallen into the position because other people have left and they are the longest serving employees left, they may be good managers, but not good software development managers. Other managers are also salesmen/women, which I have found to be a bad combination when they are directly in charge of a group of developers.
Basically the management don’t really understand the process of producing software. The company has always made money before, they can’t see a reason to change the way they manage. As the only thing visible to them is the standard of the applications are dropping with the build-up of bad code they conclude it must be something to do with the developers just not doing a good enough job.
On the developers side, there is a combination of bad communication with management, coupled with some “Hero” programmers who think they can do it all themselves. You will also generally find at least one disgruntled employee who is of the opinion that the management team are fools and nothing they ever suggest is worth listening to.
The fundamental issue with the company in the example though was the lack of communication. At some point everyone had started to give up on actually trying to make things work, and everyone just started emailing each other instead of actually talking. Emails can be interpreted wrongly, especially when the type of news that is being conveyed in them is generally bad. You know something is up when people are emailing colleagues in the cubicle next to them to ask if an issue has been resolved. Some things do need to be in writing for an audit trail, but generally those type of conversations are with customers not internally. If you want an audit trail of a conversation with somebody within your own team, then I would say there are some trust issues involved.
Management had become so used to emailing developers that they were basically managing the company via emails. Because the managers used email for everything, the developers were forced into the same boat, every question and answer was required to be in email. The few times that a developer would actually speak to a manager the conversation would invariably end with “Can you put that in an email to me?” If you are going to have to put the question in an email anyway why bother getting up and speaking to the person in the first place? Another problem with email is that the more you email, the more email you get back to then have to reply to!
Once we got everybody to start talking to each other, coupled with a few improvements in the processes; better issue tracking that the management could use and integrated with Outlook, a build server etc. the atmosphere within each team improved immensely. The development team also had to learn at what level to pitch their technical conversations with their managers so that they could actually grasp the details and be able to make an intelligent decision.
Developers actually began to enjoy coding again, and managers were happy to be able to track the projects and see how they were coming along. It made them feel like they were making a difference, even if they weren’t actually doing much. They also became much less reliant on email as a medium for tracking a project. With the decrease in email the developers also felt they weren’t being micro-managed as much, they felt they had a bit more freedom to go about their jobs without the fear of getting a meeting called to discuss what a manager perceived to be something that they were doing wrong.
As a result, the Outlook tasks and the emails after meetings weren’t required to be kept by the developers as the managers could see via the integration with the new issue tracking package in their own tasks what was outstanding. The meetings turned into much shorter affairs that consisted of discussing only the issues that were holding up tasks.
The final result was that the quality of the code that was being produced increased and the company was able to set realistic targets for releases that the developers could actually meet with all required functionality and testing.
It was only after everyone realised they needed to communicate though that the “Headless Chicken Buttons” were removed from the desks!