Software Development Is About People
May 24, 2010
We as an industry forgot this for a long time, and I am proud to be part of the movement to bring it back.
I hear all the time from people about projects being late, features missing, broken or “I can’t believe that ever worked” code. Often this is the voice of the customer feeling like they’ve been “had”. That their developer just didn’t listen to them. And now they’re stuck with something that they didn’t want.
This is definitely the symptom of a relationship that didn’t exist or just went bad.
I have seen projects do this, even been intimately involved. Projects where the technology that was delivered was even great but the customer relationship falls apart because it missed the mark, or they became so frustrated with the process that they just gave up.
And make no mistake, it was the software developer that failed here.
I’ve said and heard this so often that it sounds cliché - but the vast majority of time spent on a software development project is figuring out what needs to be coded.
Align what’s in your developers’ heads with what’s in your customer’s head. This is easier said than done, but regular face to face collaboration is key here. Two way participative engaged collaboration. Watch for when meetings become one way. You know what I mean, one side talking and the other side nodding giving the illusion that the idea is getting across. Fix this immediately, questions are your best tool here.
If something is said at any time that doesn’t fit, don’t let it slide! It could be a contradictory requirement, an unspoken assumption, a change in motivation. Stop and talk about it, figure out where it came from. It might just be a bit of ad-lib that is easily discarded or you may need to abort your sprint and have another planning session.
Also, recognize early when it’s time to pull the plug. Sometimes a customer is so unfocused that every status meeting they’re looking in a different direction. Agile tenets tell us this is ok, they can change their mind at any point and queue those changes for the next sprint, but if they aren’t pulling in roughly the same direction every sprint you may be going from Toronto to Montreal via Boston. Maybe you should have focused on getting to Kingston first.
So, take time during a project to connect everyone. Get them talking, honestly and openly. Don’t be afraid to look like a fool because you’re not. Show your courage from the start and you can avoid the illusion of incompetence later.