Tasks are more helpful than Roles


It is becoming harder to represent IT projects jobs as roles. To narrow your professional  image as one role (or more confusingly, several roles), is simply trying to squeeze modern software demands into an old business suit. There are no roles really, only tasks. For years I was complaining that testing had been demoted into a task rather than role. But in hindsight, that wasn’t the problem; the problem was the testing task was dumbed-down to point where it was perceived anyone could test. And even worse, that development was so good, outside testing wasn’t needed. Where the majority of developers suddenly believed the hype, without actually adopting any modern practices such as TDD or CI, they were given a dictatorial platform.

In the first half of the first decade of 21st century, bad development and incompetent testers flourished quickly, masked by banners of funky new terms and new fashionable perceptions of the IT world. While Agile opened up the visibility of development, and a new appreciation of the skills, it also release the nathan barley of programming, the brogrammer. And anyone with half a grasp of Scrum, became Agile experts. And testers – well, if you had enthusiasm, and didn’t’ expect much money, you were in! Wave an ISEB foundation certificate and you could up the rate.

So a project is essentially a bunch of tasks: continuous integration, test automation, user experience, security …. there are many tasks and sub-tasks. But they don’t all need to be assigned to same role. Why fly in the face of the important Agile premise of cross-functional teams. When I join a new company/project, my role is as QA Manager, Test Manager or Tester – and that is the initial limited view others have on me – it says nothing really, apart from the project activity area I “dwell” within. It is then up to me to sell my skills to the compnay and team in order to grown outside of a strict role-remit. But not everyone is going to do that.

The modern tester is part of the team, and more than likely will extend usual remits expected of a tester. This is one of the many points in my career I see opportunities to fumble the ball and be forced into hasty exit from the industry. The IT world is ultimately harsh to those who don’t keep up – at least with the new lingo. I’m not worried – I know the majority of developers, project managers, testers, test managers, etc. are not very good, some even atrocious. The evolution of task over role will go a long way to address this, if only business would embrace it.

While Agile opened up the visibility of development process, and a new appreciation of the skills, it also released the nathan barley of programming, the brogrammer. And anyone with half a grasp of Scrum, became Agile experts. And testers – well, if you had enthusiasm, and didnt’ expect much money, you were in! Wave an ISEB foundation certificate and you could up your rate. The current archaic process of CV review/Interviewing is a topic of another post, but undoubtedly adds the the ineffeciencies of hiring new project team members.

The only things that should be fixed in nature are processes (i.e. the way to do things), though even they are subject to review and change. As should people be, in fact. The old job-for-life ways had to end, though it is a principle still clung to by many, including people much younger than me. No-one should be expected to fund a bad project team member – management or “grunts”. And attitude has as much a part to play as skills. If someone isn’t up to the job, and unwilling to train, or explore other avenues for their career, then they need to be somewhere else. I see very little dynamism in this area – and the larger the company, the less anyone cares.


You can’t count on the customer to know what they want, so there needs to be a regulation mechanism that Matt Cottingham calls “Sales Driven Development” …
Sales Driven Development

With Agile, came wholesale criticsm of traditonal “milestones” – but what should be in it’s place? After all, a client expects to know some kind of time window for delivery.  Working in Sprints is all very well, but whether you like it or not, each Sprint is a milestone, as far the business is concerned.  They are not concerned with the inner working of Agile, simply output.  If the reporting and progress is poor, the first thing they will blame is this “new-fangled” way of working.  We all need milestones of some kind – forget all the flowery speak out there – there’s a client with money, who wants a product and some indication of delivery time.

Caution should be applied though – unrealistic milestones can put pressure on the project team too early.   Allowing sales to drive project schedules is fatal, given modern short-sighted sales approach. The business has to make a deadline of some kind, otherwise how will the client know when the product is ready?  How can project management effectively plan? Many methodologies assume a continuum – after all, it is not something you can specify across the board with a methodology.   There is onus of competency of management to apply these processes in sensible way, rather than simply using them to leverage their own individual positions.

We are still in an old place, where sales can drive projects simply by agreeing unrealistic terms and dates with clients, without consultation with project team.  Sales are part of the project team, but are rarely embraced in such a way.  Ultimately it is not the fault of sales, but the business for not factoring them in to the project.  They are part of the project team, and should be treated as such.  Armed with all the right information, maybe the ridiculous timescales and deadlines can be avoided.