Archive for the 'articles' Category

Jul 21 2010

Guardian pulling the plug?

Published by gojko under articles

The Unite union (of the let’s screw BA travellers for several weeks every few months fame) created a
Facebook group to stop jobs in the technology department being outsourced and offshored at Guardian News Media Ltd, publisher of the Guardian, the Observer and guardian.co.uk. According to the group web site, the board of Guardian News Media is meeting tomorrow to make a decision on outsourcing a large part of their IT department.

Without taking a position on who’s right or wrong in this case, I’m very interested in how this whole thing is going to play out. A recent major rewrite of their flagship web site is one of the most publicised apparently successful IT projects in the UK. Continue Reading »

2 responses so far

Jul 19 2010

Stop automating manual test scripts!

Published by gojko under articles

Creating an Executable Specification from existing manual test scripts might seem as a logical thing to do when starting out with Specification by Example and Agile Acceptance Testing. Such scripts already describe what the system does, and the testers are running them anyway, so automation will surely help. Not really — this is in fact one of the most common failure patterns. Continue Reading »

One response so far

Jul 15 2010

Effective Specifications for Agile Teams: Slides and Links

Published by gojko under articles,presentations

It was a pleasure to do the Agilista PM Webinar on Effective Specifications for Agile Teams today. This is the first time I did a webinar, so I’m sorry if it was a bit rough, but I hope you enjoyed it. Here are the links and slides.

4 responses so far

Jul 05 2010

How to do agile when we only have 50 crap developers?

Published by gojko under articles

Why do people complaining that they can’t do agile development with 50 crap developers not see that the problem is in the second part of that statement, not the first? I got an e-mail last week that shows the point perfectly:

We discussed whether an agile approach is right, and I concluded that not everyone can work that way.

Quite true. I find it self-evident that not everyone can do software development, agile or any other way. That requires brains, knowledge, experience is a plus, and hopefully some talent as well. And of course, there is no generic approach that works in every context.

We think that an agile approach asks programmers to be much more engaged than when they’re just being served what to do

It’s hard for me to make a comparison to answer this. I’ve always tried to be very engaged in my own work and I expected the same from everyone else working with me, even before I ever did anything resembling agile. I’ve never seen a project where people were asked not to be engaged into what they need to do, but out of general principle I would refuse to participate in one.

If your programmers aren’t engaged and they get everything served to them, your problem is right there. It is not in a process, agile or non agile.

Which means the choice of people is very important

I completely agree. Once again, this isn’t particularly specific to agile software development approaches – or even software development at all. This is important for any craft. My former colleague Relja Jovic, who was the executive editor at PC World Yugoslavia when I worked there, used to say “From shit, you can only make a shit pie” whenever we were asked to get someone unqualified to write an article (“how hard can it be?”). That holds true for programming, testing, analysis, project management and anything else to do with delivering software. With crap people, you get crap output. Tough luck. Maybe hire people who know how to deliver software instead?

19 responses so far

Jun 28 2010

Agile acceptance testing – executive summary

Published by gojko under articles

I’m thinking about organising a one day or half-day seminar on the current state of agile acceptance testing for managers, team leaders and senior technical people some time in September. If you are interested or know someone who might be (maybe your boss needs to know about these things?) drop me an e-mail or leave a comment below. The seminar would be based on the research I did for my upcoming book, and would cover the following topics:

  • key benefits that teams from my research are getting from agile acceptance testing, specification by example and behaviour driven development
  • key principles to implement this properly
  • key practices to support the principles, and how teams from my research use them in different contexts
  • key pitfalls/problems experienced commonly by the teams covered by the research
  • some generous time for Q&A

Here are the things I’d like to know from you:

  • would half-day or full day be better? (full day would allow us to go more in-depth, but that means that people would have to take a day off work)
  • do you have any specific questions you could like to have answered?
  • does the schedule make sense? how can I give you more value with this?

3 responses so far

« Prev - Next »