The environment at the place I’m currently working is structured to impede development. This can be divided into certain types:
(1) Quality of tools.
The workstations that the developers have are poorly specified for user interface development tasks. The machines are underpowered, resulting in frequent, long timeouts.
The machines cannot be easily upgraded as it is their CPUs that are too long in the tooth. A cost needs to be defined for upgrading machines and when there is the finance available this should be budgeted for. Unfortunately, the company are not big on setting budgets.
It is also difficult to obtain the necessary licences for software.
(2) Control of environment.
The lack of Local Admin rights on the developers’ machines significantly slows the uptake of new technology and the crippled web access severely limits access to information.
The workstation is the developer’s tool of the trade. Restricting the developers’ access to their toolboxes is preventing them from working well. Policies that have been made to prevent abuse of the company’s assets should be enforced through instructions and disciplinary action against offenders; there is no need to treat everyone as if they can’t be trusted to use a computer.
I cannot understate how important this issue is. A software engineer is an expert computer user and there’s no excuse for treating them as anything else.
(3) Specification of projects.
The current projects have no specifications. This means no realistic estimates can be made of when a project will be completed and how much effort will be required. A lot of effort is wasted as the work is developed ad hoc and often requires rework.
Requirements change is to be expected. Indeed, where it provides for a system better aligned with users needs they are to be welcomed. Management, however, must understand and accept the extra costs involved in rework or extra work.
(4) Distrust of developers.
There have been failings from the developers that have resulted, in the past, in misuse of company assets and timewasting. More recently there have been delays in project completion.
To help alleviate this mistrust the developers would like management to be regularly updated on progress. Attention will be drawn to project burndowns and management will be provided with regular demonstrations of the applications.
A company handbook would be useful to state the company’s policies.
Update (Jan 2010)
In the last six months I have made some small progress in clearing these impediments.
(1) The machines have been replaced, the last one today. A lack of planning, however, meant that upgrading a developer’s box, because he’d raised the performance of the old machine as an impediment multiple times, forced the old machine onto a new hire who then had to wait more than two months for his own upgrade.
We currently have developers working on different platforms, unfortunately, with a mix of Windows 7 and XP, and using different IDEs, VisualStudio 2008 and 2010, depending on what works for their environment. There is still no budget set for the purchase of licences.
(2) We have LocalAdmin rights on the boxes now. This has cut some tasks, like upgrading to a new machine, from one week to one day. To get this took raising the issue in almost every meeting with management for the last six months. Developers can now try out new tools and select the most appropriate tools for the job.
(3) Scrum has been implemented as the project management framework and, after a poor uptake, some training was arranged. Requirements are created as User Stories and estimates are made on the basis of Story Points and Velocity. It’s been made clear to management that any other estimates are inaccurate and the team will not be held to them.
(4) Inviting stakeholders to the Sprint Reviews has helped to partially dispel the distrust of the developers.
Management still look down on the developers, fail to understand their motivations and are incautious in revealing their attitudes towards them. Various attempts have been made by management to create some dialogue but most have been abandoned or have failed to appear after their initial announcement. As such, developers are unlikely to approach management when leadership it required.