What do I mean by Hero culture? I'll tell you. You have too many people who get off on saving the day and staying up for three days straight fixing problems rather than getting off on putting in place a rigorous process of software testing and release to ensure that go-live problems don't happen.
Too many organisations I have worked in have this problem - and what's worse is they don't recognise it.
I have been involved in two major projects recently where in both cases the bottles of bubbly were opened for the guys that stayed up all night, while the guys (like me, so no bitterness or anything) who were bleating on about the importance of repeatable unit testing, CI and so on were largely ignored, and at the end were fairly held up as cranks. That's not to say I'm not respected by my colleagues - I am - but when it comes to delivery they have a way that works for them, and what's worse is they can't see how dangerous the hero culture is.
Now, sometimes you need a few clever guys to get you through the gate, but just about every time I see extended periods of hacking in production by these very talented and expensive guys I can see how it could have been avoided. So why the hell does it keep happening?
In most cases this requirement comes about because the project has gone of the rails through poor project management, poor stakeholder management, or poor quality of deliverable. In all cases these can be trapped early and so there's no reason to be busting a gut doing 80 hour weeks when the application goes live.
To prevent that happening you absolutely must - I say again - MUST have a lean development environment, with a high degree of testing at each level, a high degree of automation in deployment, and a mechanism to track changes and issues with the application. This stuff isn't new so why are we (and many others) so bad at it?
It could be that because Sprint 0 slips we don't bother doing something that is essential so we can stay on track, but this is a falacy of the worst order. If you don't get the foundations right you need to crop later stories, not elements of the process essential for successful delivery. That may mean revisiting the business case. If you ignore the essentials you blow the business case to hell when the flakey thing goes live anyway. And probably more, because you have to release many more times with the ineffecient release process you have, because you didn't get the basics right (or something - could be VCS issues, release management, poor automated testing, or a mix - you get the idea).
The development burndown should be flat, not peaky. A release should be a BAU operation and the team goes home for the weekend afterwards without worrying about it. This is an ideal, I know, but you can get damned close. On the last agile project I ran in about one in three sprints we missed our pub lunch on a Friday. THAT'S IT!! No overnighters, no 80-hour weeks, and the quality of what we were pushing out was far in excess of anything I've seen on the projects in the two years since (working for a non Agile organisation with a serious Hero culture ethos).
I'm not having a go at the men and women that get the application out - the Heros - I'm really not. They're some of the brightest minds I've worked for. The company itself is rewarding the wrong people for the wrong things. If the board / senior management create a culture where Heroism is what's needed to get applications out then they should get called out on it, and something should fail. This may result in the city asking what the bloody hell is going on, and things will change, but too many companies don't see this as the problem and will just carry on regardless.
It's frustrating, not leastly because it's preventable, but also because it leaves people like me - people who can see a better way - looking for somewhere else to exercise these ideas. Somewhere they may actually get it!
No comments:
Post a Comment