Agile development workshop: Lessons learned
Week one roundup
Reg Reader Workshop Reader research conducted via the Reg Technology Panel over the last few years has consistently indicated the importance of application development to organisations large and small. Contrary to some of the things we hear, the need for software design, build and maintenance capability has not been killed by packaged applications, and certainly not by some of the latest ideas such as software as a service (SaaS) and cloud computing.
But it is true to say that things have been evolving steadily within the application development domain itself. The proliferation of scripting languages, rapid development frameworks, collaborative open source projects etc, coupled with the emergence of the ‘perpetual beta’ concept we have seen become commonplace in the online service provider world, has shaken everything up and directly challenged some of the traditional ways of doing things.
Against this background, it was interesting to get feedback from Reg readers in the latest workshop on some of the fundamental practicalities of managing software development in various different scenarios. Having worked through the insights coming out of your comments and poll responses, there are three main messages that come across strongly:
Lesson 1: Effective management is key to everything
While discussions of how to enable effective software development can quickly turn to tools and techniques (more of that below), it is very telling that two of the top three ranked criteria identified by Reg readers for creating the perfect development environment were management-related. Of the 670 readers participating in our poll, over 80 per cent gave “Respect, realistic expectations and understanding from management” and “Strong leadership of dept/team” an importance rating of 4 or 5 on a scale of 1 to 5. This was regardless of whether respondents were developers, team leaders or managers, or whether they worked in larger or smaller development shops. Over 60 per cent went on to highlight “Protection of developers from external pressures” as a key requirement of those managing the development function.
Easier said than done, perhaps, but when such requirements figure twice as prominently “Top of the table remuneration”, you can almost feel the pain of developers’ lives, and productivity, being negatively affected by management issues. We can infer from this that one of the key imperatives for optimising the development process is a two-way objective dialogue between the development organisation and business sponsors or stakeholders, in which priorities, constraints, dependencies and expectations are properly discussed and managed. Unfortunately, the danger is that you end up with a vicious circle in which development teams are asked to deliver against unrealistic objectives, have their objections overruled, and subsequently fail, which means next time around, they have more of a credibility problem than ever, so find it even more difficult to stand their ground.
The key to breaking such spirals is education, relationship management and, where necessary, effective internal negotiation. A trick that seems to work for some is putting relationship managers in place as go-betweens or facilitators. These are not necessarily your best developers, or even your most senior managers, but the silver tongued animals that are comfortable building a rapport with users and sponsors, and not afraid to stand their ground under pressure when laying out options. In any event, strong leadership and air cover is going to important for things to work well.
Lesson 2: A balance must be struck between structure and ‘creativity’
Turning to the internal workings of the development function, some interesting insights were prompted by a discussion about whether today’s programmers are more creative than their counterparts of 20 years ago (see here). The message came through loud and clear that while modern tools and environments allow developers to work up creative front ends rapidly and flexibly, the need for sound analysis and design has not gone away.
@Shortage of developers
That is not the quote :)
"There’s no shortage of developers telling us that there’s still plenty to be done"
is the quote.
Syadmins for developers some places do have them, the developer tea boys, it sort of works, but on the whole good developers can set up environments a lot better than most of the best admins. Admins don't really understand particular systems, they tend to stop at the default settings, they don't really get under the hood to make the thing fly, whilst still maintaining good stability and security.
I have lost count of the number of poorly set up systems, that have had to be re-jigged because admins have been let loose near them, and it is always amusing to see an admin beg for how to set up a system, but of course it is also duplication of effort.
Still think the secretary idea is the way to go, that way you can move some of the day to day to problems over to someone who thinks on a more interpersonal level, and they can be used to keep the 'facilitators' off the dev backs.
I use to think a good project manager was worth his weight in gold, but the older more cynical, but fun loving self now realises that a secretary is worth a lot more.
You don't need no stinking management
developers should be asking for secretaries and managing their own affairs.
It is just bad business not to have money at number one, if it is your hobby then do it on hobby time, otherwise IT is about business.
I think the main problem is this - developers lack a central identification of who they are which is why parallels are always drawn. We get the engineer analogy, which is wrong you are not engineering in the physical realm.
Then there is the author analogy which is stronger that is what you are doing, you are writing novels for computers to read and allow interaction via the user depending upon how the system feels about your novel. But of course no traditional author thinks of their work that way (n.b. the author setup for business is better for a developer though).
The mathematician one is another, there functional is more appropriate, but still most of the time it is not about maths, it is about predicting how the system will operate; more akin to clairvoyance and but instinct than maths.
There are far more lucrative fields and endeavours than development for the mediocre developer, and the profession does need to get harder and more street smart overall, the urge is there but of course the worlds worst managers are all in IT management. They are the ones confusing things with all the other departments and giving IT a bad name.
Easier to can a secretary then someone who thinks of themselves as your boss, but frankly a lot of IT management should be culled, and culled hard.
No shortage of developers, shortage of sysadmins
The conclusions correctly point that there is no shortage of developers. However there is a clear shortage of development sysadmins. Many of the reg readers have looked at a the next portion of drivel spat out by the development floor and wondered in dismay "How the f*** am I going to package and ship this". Some of us have investigated why does the development floor produce such horrid tripe. And at the bottom has always been a case of developers setting their own development, debugging and testing environments.
Frankly, I cannot blame them for that. If you ask the average corporate IT department to set up a development shop they will set in a way that no development can happen. As far as they are concerned development is messy, smelly and spoils their way of the perfect world.
So developers do it themselves. As a result an immense amount of resources is wasted across the industry due to projects not being set up in a manner in which they can be packaged and rolled out later. A lot of this can be saved if you get onboard a sysadmin team that understands how to set-up and maintain a development shop. In fact, it is a significant cost saving as the same people can also package the shipped product and they will do it considerably better than the developers themselves.
Unfortunately, it is impossible to find such teams out there. The few people that can, usually do other things and are payed salaries at the top end of the techie bracket. At present it is nearly impossible to convince management (and the jealous and vengeful IT department) about the necessity of such people until it is too late. So end of the day we continue to waste resources like mad and complain and grumble about this and that (as specified by this poll).